Taking an Agile approach to software development for the first time is no small task: there are a number of different practices to onboard and process change is disruptive, frustrating and potentially demoralizing. How do you onboard Agile practices and still meet delivery requirements? To what extent can these be introduced, especially the first time around, so that they stick?
There are two things to balance when introducing new practices: adopt at a pace that doesn't push too far too fast and simultaneously establish a "critical mass" of core practices to reap symbiotic benefits. While there are no hard-and-fast rules on how or where to begin, the right sequence can increase probability of success and set the stage for greater process adoption.
Defining The Business Problem
Begin by taking an agile approach to modeling the business problem. This requires identifying the project's flexibility, and capturing business requirements as Stories.
One reason Agile teams are responsive to change is because each member is empowered to take decisions. For these to be consistent, the flexibility of the project - time, quality, people, or features - must be clearly communicated. For example, a team working on a financial prototyping application may not have flexibility in scope but will in quality. Similarly, a team evolving a portfolio analysis tool might have flexibility in scope but not quality. Knowing the project's flexibility has far reaching effects on how each member of the team invests their time. It is the first thing to call out in an Agile project.
Next, take an Agile
Advertisement
approach to capturing business requirements by expressing them as Stories: simple, independent expressions of work that are testable, have business value, and can be estimated and prioritized. Work with the business domain experts to express high-level requirements from a business perspective, then take a deep-dive on the top priority high-level stories, decomposing them into more finely grained expressions of functionality. These more detailed Stories will still be expressed in business terms, not system terms, and can also be more accurately estimated and prioritized. Because requirements are expected to change and knowledge of the requirements becomes stale, the objective in the early stages isn't to complete a "complete" analysis but to take a thorough assessment of the overall project.
These initial steps create a strong project foundation:
Decision guidance is communicated.
All requirements have a business, and not just a system, context.
A medium for Business-IT collaboration is established.
By unwinding a business domain through a collection of independent requirements, this approach overcomes rigidity and dependencies typical in traditional requirements capture. It is also lightweight: the absence of ceremony gives it focus and increases the likelihood that it becomes a durable practice.
Structuring the Project
With the problem domain framed, the project can be structured. Agile requires code to be delivered in a completed state in fixed periods. Features are either complete or incomplete at the end of a time box, and the software deliverable has technical integrity of all features asserted to be "complete." This deliverable can then be released to QA or a development environment.
There are three factors that affect team rhythm: the project length, release length, and iteration length. The project length is often pre-determined (particularly when the deadline is not malleable). The release length allows the team to define when it will have code to release to production or certification; this will be considered in the next section, below. The most important is the iteration length: the amount of time between checkpoints for development activity. This is not trivial. Set the iteration length too long and there are fewer opportunities to assess progress and there is reduced responsiveness to change. Set it too short, and progress will appear inconsistent, creating the temptation to "game" the story list, sacrificing business value to show "progress."
Determining the iteration length is a balancing act between the team's capability and the business problem it faces. A short project with a highly dynamic domain will benefit from shorter iterations; a longer time horizon with a more stable domain will benefit from longer iterations. For an initial Agile project, consider this guidance:
Estimate Stories in "ideal days" - the number days needed to complete a story in a distraction-free environment.
Decompose Stories with estimates in excess of three ideal days into smaller stories and technical tasks - work requiring less than three ideal days can more comfortably be completed in an iteration, even with a lot of distractions.
If the domain is expected to be very dynamic choose an iteration length of one week; otherwise start with two-week iterations.
This is a critical part of project definition: a team is more likely to become consistent in delivery if it can complete what it starts each iteration. The guidance provided here is meant only for an initial Agile project. It is not meant to be prescriptive or universal. Experienced practitioners will take different definitions as suits the domain and team.
Planning
With the domain defined and the project structured, map out the release plan. The release plan is not a fixed project plan, but a forward-looking assessment of the project. This involves:
Determining each team member's availability for the project, netting days-out-of-office for holidays or other commitments. The total days in-office is the team's capacity.
Assuming further reduction in capacity due to unpredictable distractions.
Slotting the story backlog into iterations, filling each iterations with the number and size of stories as there are ideal days of capacity.
If appropriate, the release length can be adjusted to accommodate collections of iterations in which logical groupings of functionality can be made available.
The point of this exercise isn't to establish a hard-and-fast project plan but to assess the characteristics of the project with the best available information. Estimates will be wrong. Priorities will change. Distractions will happen. Requirements will come and go. The release plan is adapted constantly throughout development to reflect the most current information, giving a clear indication as to whether the project goals are reasonable or not. This initial plan allows a forward-looking assessment based on best available information and provides a consistent manner to communicate project status to all stakeholders.
What About Development?
There are two development practices which have tremendous impact on Agile project management: continuous build and unit testing. If no other development practice is undertaken, automate the build. The benefits of continuous build are well documented elsewhere; specifically to Agile project management it provides greater certainty that the code is in a deployable state at all times and reinforces time-boxed delivery.
In addition, introduce unit testing. As with continuous integration, the benefits of unit testing are well established. For a team with no experience or background in unit testing, however, the practice is initially seen as an inhibitor and often frustrating. To make unit testing part of day-to-day activity, take a gradual approach that yields benefits incrementally. Begin by introducing unit tests for the most complex or the greatest used components. In any project, especially where requirements change, it doesn't take long - usually about three or four iterations - for unit testing to prove its worth by ensuring successful refactoring. Once the team has experienced the benefits the practice spreads, leading to automation and implementation as a gatekeeper event in the build.
These two practices set the stage for further development adoption. They also reinforce Agile project management: the team will look at the deliverable, and not just its code, as being the extent of its responsibility. In addition, the "buffer" periods built into most projects for build and integration are eliminated and code identified as "complete" is less of an opinion and more of a fact when it passes all unit tests and builds.
Execution
With the project and technical environment defined, the team is ready to begin Agile delivery. For the first Agile project, the team should at a minimum track its day-to-day work to Stories, participate daily in a stand-up meeting to define what it has done, is doing and things blocking progress, and meet at the beginning of each iteration to retrospect and adaptively plan the next and subsequent iterations. These are low-ceremony events that create consistent execution and a cycle of continuous improvement within a team.
Collectively, these practices quickly yield synergistic benefits. Working on requirements which have clear business value and delivering each to a state of technical completion injects a high degree of transparency into exactly what a team is doing and how it benefits the business.
Keeping the Wheels On The Adoption Bus
Taking on several new practices is challenging, and it's likely that the team will struggle through adoption. Lessons learned from this approach include the following.
Be patient with story formation. Initially, story-based requirements gathering will be a challenge: teams will struggle to define acceptance criteria, will express them in a system (not business) context, and promote an excessive number of technical tasks as "stories."
Be sure the development team has a strong understanding of the practices before engaging the business. As everybody on the development team is likely to have slightly different interpretations of what the practices are, so, too, will the business representatives.
Identify the testing pattern early. Quality Assurance staffs often have limited domain knowledge, whereas acceptance testers often have limited time. Both need to be integrated to the development process itself.
Don't game the progress meter. What gets measured is what gets managed, and the team will be tempted to "manufacture" stories. Capture technical work performed, but make clear it's contribution to business value.
Finally, measure the impact of onboarding Agile. Have a clear objective in mind for doing this, be it quality, business-IT alignment, or consistency. Collect data at the beginning, mid-flight, and at end of the project (e.g., a customer satisfaction survey or defect reports of like-sized projects). And, be sure to retrospect the results.
Is This Agile?
Being "Agile" is not a Boolean state; individuals, teams and entire IT departments evolve toward greater states of Agile execution through experience. Rapidly adopting project management with a modest amount of technical adoption provides immediate, visible, and synergistic Agile benefits of consistency, transparency, traceability, and delivery integrity. It also establishes an ecosystem that is conducive to practice durability and additional adoption without disrupting delivery obligations.
About the Author
Ross Pettit has 15 years' experience as a developer, project manager, and program manager working on enterprise applications. A former COO, Managing Director and CTO, he also brings extensive experience managing distributed development operations and global consulting companies. His industry background includes investment and retail banking, insurance, manufacturing, distribution, media, utilities, market research and government. He is currently consulting to global financial services and media companies on Agile transformation programs, with an emphasis on metrics and measurement, as a consultant with ThoughtWorks.
Error, missing joomlaboard config file!
Comments (2)
Chris Oace: ...
I'm about to introduce Agile into a new environment and found the article very helpful. I especially liked the practical advice and warnings (what will be resisted and why, etc...) I did not find the use of "business-speak" to be a detriment. Given the strong emphasis on mapping to business drivers, why not use the language of business types? I'm looking forward to reading more on the site.
1
June 05, 2007
Steve Anderson: ...
This article has some very important concepts obscured behind a lot of cleverspeak.
to onboard: I think this means to adopt knowing the project's flexibility: I think this means knowing the project's requirements identify the test pattern: I think this means to make a plan for the testing process
Articles 
