May 29, 2005

...Learn TDD with Codemanship

Agile Software Process Improvement II

In the previous post, we looked at how agile values (simplicity, communication, feedback and courage) might apply to software process improvement. We also began to look at how agile practices - using examples from the most popular agile method, eXtreme Programming - could be used in SPI projects.

In this post, we'll examine another XP practice and see if it might be appropriate to SPI.

The Planning Game

Traditional project planning tends to rely on certain assumptions and a high degree of prescription about who will be doing what and when, and estimates for how long these activities will take. We tend to refer to such projects as plan-driven. For short projects with few, if any, unknowns (like the requirements), plan-driven is probably fine. But for more complex projects with lots of unknowns, such detailed and prescriptive plans have a marked tendency to come unglued very quickly as the reality unfolds.

Agile methods are primarily designed to work with uncertainty, and agile plans are detailed only in the short term. Long terms plans tend to focus on the high-level goals of the project, and progress is tracked against the extent to which the team has satisfied those goals.

In XP, long term plans are expressed as release plans. In release planning, the customer identifies the headline requirements for the system they want in the form of user stories. It's not necessary for them to identify all of the requirements from the start, just as long as they can articulate at a high level what they want from the system. They then prioritise their headline requirements while the developers provide very rough estimates of the relative effort required to satisfy those requirements. In XP, these are expressed in terms of "ideal engineering days" - the number of days it might take with no distractions or other impediments - and there are always distractions and impediments, hence the term ideal! For the purposes of planning and tracking progress, they may as well estimate in "slices of pizza" or "leagues under the sea". Their estimates are not firm commitments as to how long it will actually take, just rough measures of relative difficulty.

The customer is responsible for deciding what gets scheduled in a release. To plan a release, they need one extra piece of information - project velocity. Project velocity is the speed at which the team has historically delivered "ideal engineering days" (or slices of pizza, or leagues under the sea). This tells the customer how much they can schedule in a fixed period of time. The "game" is to schedule the most valuable features for the release. The customer does this by choosing the highest priority requirements that add up to the maximum number of ideal days allowed by the historical velocity.

A release plan is then a prioritised queue of headline requirements due for delivery by the release date, with requirements allotted to smaller releases (iterations[) within the main release cycle. A key feature of agile plans is that they are allowed to change. Whatever the team thought they could do in the time allowed, the reality is very likely to be different, and so the plan must change to accomodate reality. Plans that do not accomodate reality are what I call "fictions". Only fictional characters like Dr Who and Sherlock Holmes should ever be expected to work to fictional plans! Similarly, the customers initial priorities are very likely to change, and in order to deliver the most value possible, the plan must also accomodate that.

Planning continues throughout the release cycle, with a planning game at the start of every iteration. In iteration planning, headline requirements are broken down into more detailed requirements, probably spanning multiple user stories. Then each user story is analysed by the developers and broken down into engineering tasks - things that need to be done to satisfy the requirement. These tasks are estimated in the same rough way as the headline requirements, and those estimates are rolled up to give an overall estimate for the user story. The customer prioritises the stories and other engineering tasks to create detailed iteration plans that look no further ahead than 1-3 weeks. With every iteration, the release plan is revisited and updated to accommodate the reality of actual progress, as well as the changing needs of the customer.

Could these agile planning techniques be applied to SPI? The short answer is: yes, yes, YES!

The headline requirements in SPI projects are the improvements the organisation seeks to make to their software development processes. Some improvements will be more important than others, and so the "customer" of SPI can prioritise them according to their relative value to the organisation. If time-to-market is critical, then the customer might put productivity right at the top. If software quality is hurting the organisation, they might put a reduction in post-release defects first (these two measures are closely related, by the way).

Then the SPI consultant - working with the organisation - can estimate the relative difficulty of achieving each improvement; a simple EASY, MEDIUM or HARD will do.

The planning process is very similar - the customer creates a prioritised queue of improvement goals, and using the estimates plus a rough measure of SPI velocity - the speed at which the organisation has improved in the past - to build a high-level plan for an improvement cycle. Just as in XP, if you have no historical measure of velocity, the SPI consultant can make a rough guess for an initial velocity based on their experience (eg, how long does it take to increase productivity by 20% in the average organisation? The SEI has SPI statistics that might help.)

And just as in XP, the improvement cycle can be broken down into smaller iterations (though, in SPI things move a little more slowly, so iterations of 1-3 weeks might be impractical. I would suggest 4-6 weeks as being a more comfortable iteration length.) Iteration planning in SPI requires the SPI consultant to break the headline goals down into subgoals and/or tasks that need to be executed to achieve each goal/subgoal. Thse tasks might include workshops, training, the design and implementation of performance measures (eg, code metrics for design quality). The SPI consultant provides rough estimates for these tasks, and the customer builds the schedule at the start of each iteration. Again, the plan MUST change to accomodate the reality, so objective measures of progress are essential. With each task, you must be clear about what test will be used to gauge if it was successfully completed. A training course, for example, might be tested with a practical exercise or workshop to see if those attending gained the desired level of competency.

Measures of progress against the overall improvement cycle plan will be driven by actual measures of improvement, since it doesn't matter how successfully we deliver training or mentor developers if the end result is zero percent better!

In the Powerpoint presentation that you can download here, you can see how headline improvement goals for a large software organisation have been articulated using a Balanced Scorecard, and how those goals have been prioritised, with the beginnings of rough estaimtes, for the purposes of planning the SPI cycle. You will also see how the first two goals have been broken down into tasks that could be scheduled in SPI iterations. It's important to remember that the SPI scorecard, and the overall plan, are a work in progress, and remain so throughout the SPI project.

In the next post, we will look at how Pair Programming and Continuous Integration could be applied to an SPI project...

Part III
Back to Part I
More about Agile Planning
Posted 16 years, 3 months ago on May 29, 2005