Agile Development, Project Management and Five [Easy] Questions

In some quarters there is a misperception about the planning and coordination required for agile development. Often people new to agility have the impression that agility means it’s just “runnin’ and gunnin’” and you don’t need to plan and manage the project. Actually what makes agility possible is more planning, more coordination and more visibility into what’s happening than you would normally use on a traditional waterfall style development project.

The reason you need more planning and coordination is because there isn’t much slack built into agile projects and things happen much more quickly than on a traditional project. The project team needs a continuously updated project plan showing daily progress at the detailed task level in order to stay on top of things. That means the project plan is updated every day not just once a week.

No project plan survives contact with reality. Things will not happen the way you think they will. As the project progresses, new tasks get added to the plan, other tasks get removed or updated, and task dependencies change constantly. Without an accurate and current plan, people on the project loose track of what’s really going on and soon the cumulative impact of changing tasks and dependencies gets out of hand. Unexpected news starts arriving with increasing frequency and there is little time to act effectively. The team gets pushed into a mode of reacting to one unpleasant surprise after another. That’s not agile; that’s a death spiral.

[ I do lively presentations on this and related topics [1] - mhugos@yahoo.com [2] ]

To counteract this and keep the project plan current and clear use these five questions every day in the morning standup meetings. These questions are simple and they are yes/no questions. There is no room for answers like, “Yes but…” or that famous answer I hear from people who don’t want to commit, “Yes and no…” Here are the five questions:
1. Has the scope of any project task changed? (Yes/No)
2. Will any major activity or milestone date be missed? (Yes/No)
3. Does the project team need any outside skills/expertise? (Yes/No)
4. Are there any unsolved technical problems? (Yes/No)
5. Are there any unresolved user review/approval problems? (Yes/No)
(For all questions marked Yes, explain the problem and recommend possible solutions.)

The first question gets to the issue that things change as you find out more about them. Sometimes a task winds up requiring more work than you thought (and sometimes it turns out to be easier than you thought). When it takes more work add those additional tasks to the plan and add the durations for those tasks and their dependencies on other tasks in the plan. When doing this the team needs to see what it does to the final completion date of the project iteration or sprint (or blitz). This often requires the team to find simpler ways to do things or to make decisions about what tasks and system features can be deferred to a later iteration in order to deliver a working and viable system in the time available on the current iteration.

Regarding the second question, tasks on the plan are broken down to a level of detail where tasks are typically between a half day to two days long, and tasks are recorded as either started, finished, or delayed. There is none of that percent complete stuff (can anyone say what 70% complete actually means?). A task is deemed finished only when the task deliverable can be seen by the whole project team. If a task is delayed, the extra time needed to finish it is added to the task duration so everyone can see the effect that has on the project plan.

The third question makes sure that new tasks or other project developments are also seen in light of the new skill sets that might be needed because of those changes. The last thing an agile project needs is for people to try to learn a new skill or figure out a new piece of technology while also trying to get things done quickly.

The fourth question makes sure that people don’t struggle all on their own with some problem. It works much better when people pool their collective wisdom to solve problems that come up. And the fifth question addresses a similar situation where a system user may disagree with a change the agile development team makes or may change their mind about what they want. Again there is no point in one team member struggling with that all on their own.

Here’s an example of how a project plan evolves from week to week on an agile project. You can see it gets longer as more things are discovered and more detail tasks are added to the plan.

The project plan and related story boards and status boards are living things. Project plans are the big picture view of the overall project and its progress and they gain more and more detail as the project progresses. Because the plan is always up to date and accurately reflecting progress and expectations on the project, it gives everybody a clear picture of what is happening so they can work together to solve problems that arise.

It also gives senior managers who are not on the project (but who are still ultimately responsible for what happens) the information they need to feel comfortable. And that saves project team members from being distracted by endless management questions and misplaced advice (and nothing kills agility faster than endless management questions and misplaced advice…).

[Michael Hugos, principal at Center for Systems Innovaton [c4si], [1] mentors teams in agile development and delivers seminars and briefings on business and IT agility. See his book Business Agility: Sustainable Prosperity in a Relentlessly Competitive World [3].]