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 - mhugos@yahoo.com ]

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

Continue Reading