Over the past two years, I've written numerous articles as part of The Agile Developer column. Most of these articles have been focused, specialized pieces explaining an agile practice or team dynamic that helps increase agility. Throughout, I've always shared a small piece of my agile development experience, occasionally cross-referencing the material. Until now, however, I haven't shared insight to how everything fits together.
Since I'm a "little a" type of guy, I don't care much for the branding and commercialization of Agile methods. Most of my experience hasn't come from in-depth use of Scrum or XP, and aside from some industry de facto standard practices like continuous integration, test-driven development, or refactoring, I don't care much for process-specific lingo. Instead, I find that gluing together proven practices and techniques offers the greatest chance to deliver superb quality software. This month, I'm going to traverse back through many of the previous articles I've written for the Agile Journal, and illustrate how they might play together on an agile software development project.
Getting Started
Imagine that you have a project that has received funding, and that your stakeholders are anxious to get started. There are some important items deserving immediate attention. Some call this period iteration 0 or Cycle 0. This period is the first few weeks of the project before development commences. While development hasn't started yet, there are a few critical items that must be done the first few weeks:
The team - It's cliché, but great teams start with great people. Great teams don't just happen. A bunch of developers don't show up one day and develop great software. Even for the largest projects, I'd advise starting small. I was once part of a project consisting of more than 125 developers with total project personnel greater than 200 people. When we started, the core team was just five people - a project manager, two developers, a business analyst (who happened to be one amazing QA tester), and our key business client. The key ingredient was not that we had complete representation. The key ingredient was that everyone on this core team was dedicated to the project and understood software development. That's not to say we didn't pull in others as needed, because we did. We recognized our weaknesses, and sought help to overcome them. (More on this team later.)
Technology stack and infrastructure - Developers need to begin determining the development tools, configuration management tools, application frameworks, developer testing tools, continuous integration strategy and more that will be used on the project. In some cases, organizational standards will dictate your decision, but there are always gaps. Fill in these gaps with the best tool for the job. Be sure to search for tools that enable agility. In some cases, you may need to perform some tool evaluations. If the evaluations are going to take a long time, factor them into the release and iteration planning process. And don't forget about the quality open source tools that are available.
Release and iteration planning - Develop a roadmap for the project and prioritize items based on risk. Risk is evaluated based on many factors, so be sure to factor resource risk, technology risk, business risk, operational risk, and more into the risk assessment. You need your core personnel involved in each of these meetings, and you need to focus on planning your roadmap. Planning involves a lot of discussion surrounding dependencies, phased roll-outs, business priorities, and more. The value of release and iteration planning so early in the project is not the release or iteration plan, but that you now have a core team with a consistent vision on project execution. Planning should continue throughout the duration of the project, but early iteration and release planning establishes a vision the team can carry throughout the remainder of the project lifecycle.
Requirements envisioning - When you're planning your project roadmap, be sure to keep a list of coarse-grained requirements. I call these Use Cases, while others call them Epics. They are important, because the highest priority requirements are what your team needs to emphasize first. Soon, you'll break these higher priority requirements down into tasks (some call them stories) and start active development.
Architecture envisioning - It's important that the technical team establishes a high level architectural vision, including user interface flow, the organization and behavior of high level components and services, and a core domain model. You don't need, nor do you want, a complete and detailed architectural roadmap. But you need a consistent technology vision shared across them team. As the application grows, develop a system of checks and balances that activates the lifecycle to maintain your architectural resiliency.
Advertisement
Just Build Something
You've laid the foundation, now it's time to create something. Many teams work within the context of time-boxed iterations. They'll use story points to measure the relative effort required to develop a single user story. A user story is a high level definition of a requirement providing only enough detail to make a reasonably educated estimate of development time. While a starting point for many teams interested in agility, tying stories to velocity and iterations can be limiting. The most common mistake I see with agile development is when a team uses iterations to manage the development effort, but neglects to complete all phases of the traditional lifecycle as part of each iteration. I prefer something of the following ilk:
Develop a prototype - A smoke and mirrors prototype early in the project is a great way to garner feedback on the usability and navigation of the application. Prototyes also complement requirements elicitation nicely, and I've always found the two to be effective when used together. Prototypes offer team members an opportunity to step back from detailed requirements and look at a system from a higher level, integrated standpoint. Since most of my work has been web application development within the enterprise, HTML prototypes are a great first step followed by the evolution of that prototype to a functional web application.
Host demonstrations - Increased customer collaboration is a key element of increased agility. Developing a strong working relationship with your customer is key to ensuring you are fulfilling their business needs. A great addition to your regular customer meetings is a weekly demonstration. With a robust continuous integration strategy, you should strive to activate the software lifecycle. Initially, the demonstration will center around the prototypes developed. Eventually, the prototypes will evolve to a complete system implementation. Your customers will appreciate experiencing the growth of the software.
Develop a skinny system - Many business processes are large, complex workflows that require deep understanding of requirements. In fact, I'm no longer surprised to find that some complex processes can easily take up to six months to develop completely. But throughout that six month period, frequent deliverables are critical. Treating code as a corporate asset helps maintain the cleanliness of your codebase, leading to eased maintenance and the ability to quickly respond to change. I've found that developing a skinny system works well, where the team ignores many of the more complex issues first, and tries to get something working quickly. For instance, if you have an HTML prototype, start by developing the back-end processing functionality to accommodate simple data entry with few business rules. As time progresses, and more demonstrations are conducted with business stakeholders, these business rules can be incorporated in the system.
Test continuously - Arguably the most important aspect of the agile software development lifecycle is continuous testing. Agile teams perform all sorts of tests, and they do so throughout every iteration. A common mistake I see with many agile implementations is that an iteration represents a development cycle but not a test cycle. Development progresses iteratively throughout the software lifecycle, but if a full suite of tests isn't run at the end of the iteration, you have not delivered running tested features.
Deliver continuously - Without a doubt, continuous integration is the single greatest agile success factor. It enables so many other important lifecycle activities, including the ability to run those all-important suites of load tests, user acceptance tests, performance tests, failover tests, and more on a continuous basis. But continuous integration does not guarantee agility. Teams that fail to leverage continuous integration to increase feedback aren't realizing its greatest potential.
Expand Your Ability
A core tenet of agile development is frequent delivery of value-added software. Small teams can be powerful, but most enterprise development initiatives require more than just a few people. Eventually, you'll need grow your team. On the project I cited above, how did we move from five people up to a team of more than 125 developers? Very carefully.
Multiply the team - As your team grows, create mini-teams organized around process instead of technology. Each team should consist of at least two developers, a business analyst, a tester, and a usability expert, but recognize that some developers are talented and experienced enough to wear more than one hat. For instance, an experienced business analyst may also be able to play the role of tester. Depending on workload, some individuals may be on more than one team, but be careful. The worst we can do is spread people to thin across a project. Focus on building the matrix of process and technology experts, supported by strong collaboration tools.
Establish Team Cadence - Initially, the smaller teams might operate on the same iteration schedule. Over time, however, inefficiencies develop with that model. Since not all teams produce at the same pace, you may need to allow the iteration schedule to diverge across teams. Since every feature implemented represents a small incremental growth of the system, what's most important is that when a team delivers a feature, that feature is tested thoroughly. Remember continuous delivery and continuous testing. Testing shouldn't occur at the end of each iteration. Instead, testing should occur as each feature is delivered. Use iterations loosely, primarily as a planning window to manage the work across teams.
Expand your environment - Always look for better ways to get constructive feedback. Treat executable artifacts as your most trusted reference on the current state of the application. Leverage the experience of your team through an effective review process. Adapt practices so that they work well for your team and leverage your infrastructure using important code and design quality metrics.
Conclusion
Many times, agile transformations start with adopting an agile process, such as Scrum or XP. These are great places to start, but you must always be looking for ways to continuously improve by adapting those agile practices to your environment. I've seen many teams get so caught up in process improvement that they forget the importance of developing software. Never lose sight that your purpose is not to be great at developing software, but to develop great software. As you start realizing a bit more success, you might even find that you start having more fun, too.
About the Author
Kirk Knoernschild is Senior Technology Strategist at TeamSoft, where he leads based on his firm belief in the pragmatic use of technology. In addition to his work on large development projects, Kirk shares his experiences through courseware development, teaching, writing, and speaking at seminars and conferences. Kirk has provided training to thousands of software professionals, teaching courses on UML, Java J2EE technology, object-oriented development, component based development, software architecture, and software process.
Comments (1)
John Voris: ...
What? Nobody has left a comment here?
This article is one of the best I've read on how to pull all the theory together, and actually begin to start to commence to initiate an Agile project!
Agile Journal 
Over the past two years, I've written numerous articles as part of 
