Tuesday, January 6, 2009

Agile Planning For Software Projects

(Removing Risk with Scope-based Planning)

Much has been written over the past few years about Agile methodologies for software development. To set the record straight, I am in favour of a more agile approach to software development. Unfortunately, many people erroneously assume that the various agile methodologies that have become so popular remove the need for planning. It is the intent of this article to show that increasing agility in one's approach to software development does not need to be at the expense of planning.

In this post I will propose an approach for planning software projects that will not only allow for agility in the project life cycle, but even encourage it. This approach to planning will reduce cost over-runs, feature creep, resource mis-allocation, and deadline slippage. All of these conditions are often seen as indicators of poor project management. Unfortunately, this often gets reflected on the project managers. The truth of the matter is that the whole team is responsible for correcting and avoiding these issues.

Scope-based Planning

The mantra of Scope-based planning is "Plan Early, and Plan Often". This is accomplished by setting aside ten percent of the scope of each stage to planning for that stage. It is important that this be done at each stage. It is equally important that the full allotment of planning time be used. The level of detail to which one will plan will be proportional to the length of time in the stage. A long stage will get macro (high) level planning, while a short stage will get micro (low) level planning. So if you are just starting the project, this would be ten percent of the expected total project time. If you are at a one week stage (an iteration) it would be ten percent of that week. It is also important to note that this is ten percent for each resource, not just the developers, but the testers, the interaction designers and the project managers.

Ten percent doesn't sound like a lot, and in fact it isn't. I've had some people suggest that this should be twenty percent, but I feel that is too much, especially when you consider that we are talking about ALL RESOURCES. What we are asking of the team isn't the creation of a full design document at each stage, just that we stop for a moment and think about the tasks that this stage will require. If the stage is only one week long, those tasks will by definition be fairly fine grained.

The planning needs to be repeated at each stage of the project. Initial planning will begin as soon as the project scope analysis has been completed. This planning phase may also include a more detailed planning phase for the first release. Then each subsequent release would see a planning phase for that release. In each iteration of the release, each resource would spend 10% of his or her time planning for that iteration.

For example...
The following image shows a dummy project. (Click on it to enlarge)
Let us assume that the initial scope analysis shows that the project is expected to take 2 months. The team will be made up of three Developers, one Interaction Designer (ID) and one Project Manager (PM). The developers will have 7 weeks or 35 days of work each (105 days total). The ID is expected to have 3 weeks (15 days). The PM is expected to have 2 weeks (10 Days). That's a total scope of 130 days. Therefore, the project warrants 13 days of planning up front. (This would be added to the scope.) Assuming that the PM spent 1 day meeting with the client and coming up with this initial scope, The ID, the PM, and the lead developer should spend 4 days each planning the project. During those 4 days, they will gather requirements, formalize the release and iteration plan, and validate the expected scope. The last step in the planning is a review of the scope. It is possible, even likely, that the scope will change already at this point. This is the agile part. The PM will need to make a "Go / No Go" decision. If he or she is not empowered to do so, this may require a meeting with the client. The point is that if the initial estimate was wrong, you want to know about it as soon as possible.

Now, assuming that the scope hasn't changed, lets say that we have planned for two releases of one month each. That means that the first iteration would be primarily executed by the ID. Before she starts working, she should spend half a day planning her work. During this week, she would likely involve the lead developer to discuss options, but it would mostly be just her. This would be the time for the lead developer to set up the database and server environments, and perhaps start some high level designs.

By the end of week one, if the ID has discovered any unexpected elements of the project, the team can re-assemble and determine the impact to the scope before continuing.

If no further changes are required, the developers will start working on the project on the second week. Once again, ten percent of the week would be spent (up front) planning. In our example, each developer would spend Monday morning planning the week. At some point in the week, the PM will want to meet with everyone to find out how things are going. Now your agile methodology might call for daily "stand-up" or "scrum" meetings, that is not what I'm referring to. I'm talking here about reviewing progress against the plan. Also, in many shops, the ID will also be tasked weekly with reviewing the tickets that are completed, so our example shows that as well. At about the mid way point, the ID and Lead Developer will have to take some time to plan the second release. Then, the second release continues much like the first.

Scope-based Planning has the following benefits:
  • No surprises. When surprises arise, they can be dealt with at once. Sharing bad news with the client early gives them the ability to deal with it before it becomes a crisis. Cost over-runs are not seen as negative as they might otherwise be, because the client had knowledge of them early and has the option to remove something else that wasn't yet started, or cancel the project all together, cutting losses early.
  • Feature Creep is eliminated, because the planning will show the impact of new features to the budget and the time lines.
  • Resource mis-allocation is also eliminated because the scope of the project is validated prior to a large team being assembled.
  • Deadline slippage is also controlled because early and often planning will expose any risks to the project early. The PM then has the opportunity to address those risks before the project gets too far.

The final Word...
Now many of you might say "All that planning is actually going to slow the project down". To that I say "Yes, it will"... and this is a good thing. We are talking here about doing what is best for the client, not the consultant. Your mother wouldn't let you go running through the house with scissors in your hands either. Sometimes the best thing you can do is slow down, and watch your step.

Others are no doubt saying "Planning doesn't prevent surprises". Again I say "Correct". But planning early and often, reduces the hit that those surprises will have on the overall project.

I am not advocating wasting time on filling binders with useless information that will never be looked at again. A colleague of mine puts it this way: "Plans are useless, Planning is priceless". If you are taking your plans and writing them up in some template, and printing three copies for the management team etc... you are a fool. Planning can be accomplished on a whiteboard, or a napkin, and the documenting of those plans can be captured with the camera in your cellphone. If it's a macro level plan, throw it up on a wiki or a quick email to the team.

I hope that this inspires you when you start your next project to take the time it warrants to think it through. I am positive you will reap the rewards of a more stress-free project life-cycle.

No comments:

Post a Comment