Does your team have to keep two sets of “books”? You have an agile roadmap to see where you’re headed. You have a smallish backlog of the near/upcoming work. You’re delivering on a frequent basis.
And, someone on your team keeps a Gantt chart because a manager wants to see the team’s progress in a form they feel comfortable with.
Your team hates having to translate the agile planning into more traditional planning. It takes time away from finishing the work. And, too often, the more traditional planning sometimes encourages estimating “all” of it, at too low a level. (That’s a symptom of “how much” thinking.
If you’re in this pickle, your manager might think your agile team doesn’t replan very often. That manager might assume your team uses an agile approach only as a way to deliver. Those managers miss the idea that the team can plan more continually if the team uses the empiricism in an agile approach. That’s what I tried to show in that image.
You have several ways of dealing with this problem. You can keep two sets of “books” as I described above with the best estimates you have now and continue to update both sets of plans. You can placate the manager with more information than the manager can manage. Or, you might ask a different question.
Placate the Manager
Team A gamed the request in this way: the team took each feature set. They brainstormed the smallest possible stories they could imagine. They then estimated as in Cost, Value & Investment: How Much Will This Project Cost? Part 2. They then created interim milestones with the feature sets or the part of the feature sets.
They plugged those stories into the Gantt. Made the managers crazy to look at the detail. What did the managers do instead? Looked at when feature sets would be done.
Team A did have a problem: every feature set grew and shrank—and not by a predictable amount. So, some of the feature sets were “early.” Some were “late.” (See Alternatives for Agile and Lean Roadmapping: Part 1, Think in Feature Sets for the issues of unpredictable feature arrival.)
They’d bought themselves project breathing room for creating a Gantt chart. And, they couldn’t possibly “keep” to the Gantt. They used agile approaches and worked with the customer. That meant features and feature sets changed. The team was fine with that. However, the Gantt chart needed to change often.
While Team A offered a Gantt chart, the chart was useless. And, the agile project manager, Sue, had to maintain it.
Sue decided to start asking questions.
Ask About Decisions Based on the Data
Sue asked this question:
What decision will you make, based on the data?
When you ask this question, you might learn what some of my clients learned:
- Sometimes, managers wanted to know when it was safe to announce the product.
- Some managers want to manage the project portfolio based on dates and estimation.
- Some managers wanted to “know” that “everything was on track.”
I thought it was reasonable to use data to be able to announce the product. I’m not big on using estimation to manage the project portfolio but I could see why they wanted it.
As for “knowing” about the progress: a Gantt chart can’t tell you that. That’s the schedule game called The Schedule Tool is Always Right.
Schedule tools might help people recall past data on past work. And, I have at least two problems with that past data:
- We rarely do the same thing twice. Something will be different this time: the problems to solve, the team, the codebase. Previous project data does not often predict this project’s data.
- Too many teams don’t capture the overtime the team members actually accrued in the project.
You do have access to real data in any project. That real data is cycle time, the time it takes the team to finish a feature once they move it off the ready column. See Help Managers Visualize Their Problems for a value stream map and cycle time calculation.
What Data Matters?
I like demos to know when if we’re on track. Demos can also tell us if we’re getting close to done.
In my experience, too many projects continue because we need it “all.” We often don’t need it all. We need a lot less. And, if we’re able to test our assumptions with frequent releases, we might not need to do much at all. Demos can tell us if we’ve done enough.
If you want charts, consider the product backlog burnup chart.
You can see the progress for each of the feature sets over time.
Sometimes, the product backlog burnup doesn’t explain to management the effect of their decisions. In that case, I like the feature chart.
The feature chart shows the burnup of features complete, the burnup of the number of total features, and the burndown of the features remaining.
One of the problems with wanting to know about all these dates and progress is that too often, managers muck around with the features. They want to cram more into a too-short time. Or, they want to add more for some reason. These charts help managers see the data they need.
Remember, I’m talking about agile teams here, teams that deliver value on a regular basis.
No Data-Based Decisions
Sometimes, when teams ask the manager, the manager says, “I’m not using the data for any decisions. The Gantt is how I know about the project.”
That’s an agile transformation problem. The teams are moving to an agile culture. That particular manager is not. It’s possible the manager doesn’t know what he or she should do. It’s more likely the manager has not yet changed his/her beliefs and values to those of an agile culture.
If your managers want you to keep data that doesn’t help the team, understand why. Managers aren’t stupid. They might not realize which data they can use to make which decisions. Help them learn.
Asking the question, “What decision will you make based on this data?” helps people see their culture and system. And, avoid the “two sets of books” problem.
Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: What Decision Will You Make Based on This Data? Opinions expressed by Java Code Geeks contributors are their own. |
