Agile Planning Tips

My goal with this article is to share good planning practices which I find to work well in practice. A fundamental difference between agile planning and traditional planning is that agile planning is very collaborative in nature: the team is responsible for planning, not just the project manager. In this article I discuss:

1. Scheduling Tips
   • Iterations
2. Estimating Tips
3. People Management Tips
4. Agile Metrics Tips

1. Scheduling Tips

1. You can accurately plan in detail only for nearby tasks. Notice how in Figure 1 I only planned for iterations 1 & 2 in detail, I can schedule in detail several weeks ahead but not several months, and only did a high-level scheduling for future iterations. Figure 2 shows how my schedule has evolved by the fifth iteration, I'm doing just in time (JIT) planning. At the end of the initiative I have an accurate, detailed plan, as shown in Figure 3.
2. Question the use of Gantt charts. Although I show Gantt charts in Figures 1 to 3 there seems to be growing evidence that Gantt charts have little value on agile teams (although my experience is that a high-level Gantt chart such as Figure 1 does provide value to help you think through major dependencies, just don't go any further than that). My 2007 Agile Adoption Survey showed that Gantt charts are the least valuable work product on agile teams whereas iteration task lists were one of the most valuable.
3. The people doing the work must be actively involved in scheduling. They're motivated to get it right, they have skills to understand the dependencies, and they need to accept the schedule.
4. People should choose their work, they shouldn't be assigned it. It is quite common on agile teams for the team members to do the planning, not just the manager/coach. Planning is so important that we want to get it right.
5. Organize the effort into short sprints/iterations. The only true measure of progress on a software development initiative is the delivery of working software. By working in sort iterations, 1 to 4 weeks is common, and by delivering working software each iteration you provide concrete evidence that your team is progressing. This provides greater visibility into the true status of a team than does documentation-based earned value measures and improves your ability to effectively govern IT teams as well.
6. Take a requirement-based approach. Agilists typically schedule the development of requirements (user stories, features, use cases, ...) into iterations as the line items, not tasks such as design, test, .... For example, the line items of iteration 5 might be "Implement Search for Books", "Implement Search for DVDs", "Implement Process Mastercard Payment", and "Implement Capture Different Billing and Shipping Addresses" for an online e-commerce system. These line items would stretch the length of the iteration, I would trust the team to schedule the actual work appropriately and wouldn't go into any more detail in the team's schedule.
7. Schedule tasks involving external groups. When a task involves an external group, perhaps you want to demo your system to some stakeholders or deploy a testable version into your QA/test environment then you should consider including the task on your schedule as a reminder to coordinate with those groups.
8. Remember to include training. Training usually occurs at the beginning of an initiative so that team members can learn the fundamentals of any new skills that they'll need on the team. Training will also occur throughout the initiative, particularly for new staff, but the majority typically happens at the start. Remember to plan for it.
9. Choose an approach which reflects your environment. The article Comparing Approaches to Scheduling and Estimating Software Development Initiatives provides insight into your options.

Figure 1. The schedule at iteration one.

Figure 2. The schedule at iteration five.

Figure 3. The schedule at project end.

1.1 Iterations

Many organizations struggle with the concept of iterations. This advice should help:

Shorter is better. An iteration shouldn't be any more than 4 weeks in length, otherwise you're likely to slip into a mini-waterfall style of development. I prefer either one or two weeks in length. This keeps the delivery pace of the team nice and steady because you deliver some new functionality on a regular basis. Start with an uncomfortable length. When you're transitioning a traditional organization to an evolutionary (iterative and incremental) approach to development, try to identify the length at which they think they're comfortable (e.g. 8 weeks) then remove a week or two (e.g. start with iterations of 6 weeks) to force them to become less bureaucratic. Do a couple of iterations like this, then start reducing the iteration length until you're down to something reasonable (e.g. less than 4 weeks). Ignore the calendar. If your iteration is one week in length, run it from Wednesday to Tuesday. Iterations which run Monday to Friday typically suffer from "Weekend-itis" where your focus and energy is reduced dramatically on Friday because it's the end of the iteration and the end of the week. This is effectively a double whammy to your productivity. Produce something useful. Fundamentally, an iteration should be just long enough so that you can get something useful done. Some teams have iterations that are one day in length. Have as many iterations as you need. Requirements change, which means the length of time you need to implement the system should change to reflect this. You can still have a firm delivery date. If you need to have a firm delivery date, then simply set one and deliver at that time. Keep doing development iterations until you get to the point where you need to deliver the system. If you continually implement the highest-priority requirements, see Agile Requirements Change Management, then what you deliver will be the highest value possible.

2. Estimating Tips

The best estimates are:

1. Done for smaller, rather than larger, items. It's easier to estimate work that will take one day than it is to estimate something that will take one month.
2. Done by the people doing the work. They're more motivated to get it right, after all. Initially developers may not be very good at estimating, but they very quickly pick up the skills if you give them a chance. The best estimates are "bottom up", not top down.
3. Done by someone who has done the work before. They know what they're talking about.
4. Presented as a range. The longer away something is the greater the range your estimate will need to be. For example, if I'm estimating the cost of a six month initiative at the beginning, I may have a range of +/- 20%. If I'm one month away from delivery, my range may be +/- 3%.
5. Updated throughout the initiative. As your actuals come in, you have a better idea as to what the cost will actually be.
6. Choose an approach which reflects your environment. The article Comparing Approaches to Scheduling and Estimating Software Development Initiatives provides insight into your options.
7. Beware professional estimators. Professional estimators, perhaps people with COCOMO II or Function/Feature Point counting skills, sound like they have a good approach. In practice professional estimators only seem to produce estimates whose only "benefit" is that they're backed up by a lot of elaborate work. Management seems to think that these estimates are very good, and with enough effort they often are, but these techniques prove to be a very expensive way of producing estimates. My advice is to keep things simple and instead follow the tips listed above.

Questionable software development practices are motivated by the decision to develop an accurate up-front estimate. To develop such an estimate you need to understand the requirements which you are supposed to implement and the architecture which you are going to build to. The desire for greater accuracy increases the need for more detailed information, which in turn motivates you to adopt:

1. A big requirements up front (BRUF) approach where you create a detailed requirements specification early in the lifecycle. This doesn't work well because people aren't good at defining what they want up front, implying that you're estimating the wrong thing.
2. A change management process which strives to avoid "scope creep" throughout the initiative. In effect you prevent change from occurring, thereby ensuring that you build something that misses many of your stakeholders true requirements.
3. A big design up front (BDUF) approach where you attempt to specify your architecture in detail before coding begins. With BDUF you often make significant decisions without the knowledge gained from proving your ideas with working code, thereby ensuring that you'll build the system the wrong way.
4. A software development lifecycle that is mostly serial in nature. This reduces the control points for stakeholders, thereby hampering governance efforts and increasing overall risk.

Ironically up-front estimates are often motivated by the desire of organizations to reduce their financial risk on IT teams yet in practice this decision not only has the opposite effect it also motivates you to increase your technical risk too. My experience is that when business people are educated on the impact of this strategy, and when they're given other viable strategies for planning and governing IT teams, they soon choose to abandon up-front estimating. I highly suggest getting senior IT management and senior business management to sit down and talk with each other about this critical issue.

See also:

• The XP Game
• Comparing Approaches to Budgeting and Estimating Software Development Initiatives
• Estimating on Agile Projects

3. People Management Tips

1. People, and they way that they interact, are the most important determinants of success on a software development team.
2. Stakeholders should be active participants on your team, not just people you interface to. See Active Stakeholder Participation.
3. People who work together closely in co-located teams will often manage themselves.

See also:

• The EUP People Management Discipline

4. Agile Metrics Tips

The types of metrics I collect:

1. Burn rate. How much money/time/resources are we investing in this effort? Like it or not, someone always wants to know this number.
2. Delivered functionality. The delivery of working software is the only true measure of progress on a software development team. Simple ways to measure this are simply tracking
3. Velocity. This is a measure of how much functionality can the team deliver per iteration. This measure is often captured in the form of "use case points" or "story points" which are specific to the team.
4. Defects. Knowing how many defects, and the severity of those defects, is an important determinant of whether you're in a position to deploy your system.

Here's a few good ideas which you should consider:

1. Keep it simple. Start small and keep it that way. You only need a few metrics, and even my list shown above may be too long.
2. Metrics must add value. The value provided by having the metric must exceed the cost of collecting it. Remember to Maximize Stakeholder ROI.
3. Look at trends, not absolute numbers. There are 20 defects on one product and 50 defects on another. I can't really tell which team is in the most trouble with just this information. The first team has had 20 defects for the last 6 months, but the second one had 200 defects two iterations ago, 110 defects last iteration, and now has it down to 50 this iteration. Now which team is in the most trouble?
4. Combine metrics. Consider the earlier teams. The team with 20 defects is a $1,000,000 effort. The team with 50 defects is a $100,000 initaative. Now which one is in the most trouble?
5. Don't manage by the numbers. If you want to know what is really going on, talk with the people directly involved. In the example described above, the numbers really don't tell you what is actually going on, do they?
6. Expect people to fake the numbers. How do you know if the metrics I provided above are accurate? If someone is rewarded, or punished, based on the metrics that they're collecting they are highly motivated to fudge those numbers.
7. Expect to change whatever it is that you measure. The Hawthorne effect says that whatever is measured will improve. There's also the side effect that it may change in ways which you didn't expect and perhaps didn't even want. In other words, the numbers may improve but are the things they are measuring improving in a way that you desire?
8. Metrics are difficult to compare. Your definition of a defect may be different than mine, do does it even make sense to compare the defect rates between teams? Technology changes over time. Does it really make sense to compare COBOL and Java soltuions with one another? Processes change over time. Does it really make sense to compare the metrics of a team following a serial lifecycle with that following an agile lifecycle?

Suggested Reading

This book, Choose Your WoW! A Disciplined Agile Approach to Optimizing Your Way of Working (WoW) – Second Edition, is an indispensable guide for agile coaches and practitioners. It overviews key aspects of the Disciplined Agile® (DA™) tool kit. Hundreds of organizations around the world have already benefited from DA, which is the only comprehensive tool kit available for guidance on building high-performance agile teams and optimizing your WoW. As a hybrid of the leading agile, lean, and traditional approaches, DA provides hundreds of strategies to help you make better decisions within your agile teams, balancing self-organization with the realities and constraints of your unique enterprise context.