Several of my clients have internal struggles about how to internally see the future of the product. The teams want to use an agile approach so they can incorporate learning. The managers want rigid roadmaps. Why? Because the managers want to “know” the teams will deliver it all.
However, the managers create a roadmap similar to the image above. That roadmap has large features and long “deadlines.” (Notice how all the features end on a quarter boundary?)
The managers created a Gantt Chart as a picture, not a roadmap. The managers might even think this is roadmap reflects an agile approach. There’s nothing about this roadmap that’s agile. The managers think they need it “all” instead of using how little thinking to create a product the customers will love.
What can you do?
Several things—and none of them include telling your managers they are wrong. Some possibilities:
- Assess the product/project risks to choose a lifecycle. You can decide if you need an agile approach.
- Implement by feature.
- Demo on a regular cadence.
Let’s start with product risks.
Assess Your Product Risks
What kinds of problems does this product solve? How innovative does this product need to be?
On the left side of this image, we have totally deterministic problems. We don’t have to experiment.
On the right side, we don’t know enough—we need to experiment to discover what to deliver. Not only will the product change, but we might change even more about the product. That includes the customers, the purpose, everything. I recommend an iterative and incremental approach there. (An agile approach will work better, but an agile approach is a cultural change, which you might not need.)
Most of my clients work in the middle part of the continuum. They often start closer to the right for new products. As they release, they move to the left or the middle. Every so often, someone has a breakthrough idea and they move to the right again.
What if you port a product from one platform to another? Or you implement a library with an already-published API?
Those products might be totally deterministic—if you want to recreate all the old problems, too. That’s why I recommend you consider the lifecycle that will manage the risks for your work.
Lifecycles Help You Organize According to Risks
Lifecycles offer the people doing the work two big ways to manage risk:
- Visualize when you iterate to reduce risks. (You might iterate over several feature sets to then select an architecture. You can then create milestones that help you see when it might be safer to select the “final” architecture.
- Create milestones for when you will deliver what kind of value. (If you use iterations, as in Scrum, you deliver at least as often as the end of each iteration.
Lifecycles help you organize project deliverables, whether those deliverables are predetermined or not.
If you think you don’t have too many issues to discover, you can safely use an incremental approach. (See What Lifecycle or Agile Approach Fits Your Context? Part 3, Incremental Lifecycles.) You don’t have to use an agile approach, especially if your managers want a roadmap that’s really a Gantt Chart in disguise.
An incremental approach will help you release small chunks of value all the time. If you also learn how to create small vertical slices so you can implement by feature, you can deliver something useful internally every day. Then, releasing becomes a business decision.
You don’t have to worry about deadlines because you release enough every week. (Assuming you make your stories small.)
What if you do have to learn as you proceed? You might need an iterative and incremental but not agile approach.
Each of these lifecycle options offers you plenty of opportunities to create small vertical slices and release the finished work internally. That’s called deliverable-based planning. You get to deliverable-based planning with small vertical slices of features.
Create Small Vertical Slices by Feature
This image is what I mean by “Implement by Feature.”
Notice that the features (in red, green, and blue) are small and go through the entire architecture. (I wrote much more about this in Agile and Lean Program Management and Create Your Successful Agile Project.)
What if you have component teams? See Product Roles, Part 5: Component Teams to Create Slices for some ideas.
If you want to “meet” deadlines, the teams need to finish small items through the architecture every day or several times a week.
What if you don’t have small deliverables? If you really need to meet deadlines, learn how to move to “how little” thinking.
Every large feature has several deliverables. Learn to finish one of those deliverables each day or two. (Yes, agile approaches use this idea, too, but you can use this idea in an incremental lifecycle. That’s what I did starting in the 70s. An old idea. Why don’t people use it anymore? Because inch pebbles create way too many details in a Gantt chart.)
You can implement by feature in any lifecycle. Even in a waterfall. Which means you can demo at will.
Demo Early and Often
If you want to move your managers from “we need it all” thinking to “how little” thinking, demo every single time you release a slice.
In addition, create a cadence for demos, such as Wednesday morning at noon or just before. Record the demo.
When managers ask you where you are, ask, “Did you see the demo yet? Did you see what we made for you?” (HT to Chris Li, who first said that.)
You can do each of these, assuming you use an incremental or agile approach.
If the managers say, “No, I’m too busy to watch the demo,” you can say:
- “I’d really like you to watch it before you ask any more questions. The demo is part of your data. I can offer other data, but the demo counts more than anything else.”
- “Since we deliver something every couple of days, and definitely every week, we’re on target. We’re working as fast and well as we can. Want to see a forecast?”
- “Okay, if you’re really busy, do you want the 30-second, 60-second, or 5-minute status report?” The 30-second report is the product backlog burnup chart, as above. The 60-second report is the chart plus the most recent demo. The 5-minute report is the previous two plus the forecast for the next month or so of work. (You might offer other data.)
Say all of this in a respectful way. In my experience, the reason your managers want it all is because they’re under pressure. You might ask about the pressure they feel and what you can do to ease that pressure.
You might like some of the ideas in What Decision Will You Make Based on This Data?
Given what occurs at my clients, I suspect the managers don’t realize how much freedom they might have if they move from certainty to more openness.
Less Predictiveness, More Options
One big problem I see is that managers get rewarded for certainty and “their” deliverables. Those ideas are anti-agile.
I gave a talk at Agile 2018 called, “Agile and Lean Roadmapping: Incorporating Change at Every Level of Planning.” I based it on the Agile and Lean Roadmapping Series.
However, I still see a lot of large features and long deadlines in too many supposedly agile organizations. If you have that problem, consider what you want to ask your managers. And consider the lifecycle will offer you the best options.
Remember: Roadmaps offer options. A predetermined roadmap is a Gantt chart. Maybe if you say those words to your managers, they might consider alternatives.
(This post is related to With Agile Approaches, No Need to “Meet” or “Enforce” Deadlines.)
Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Large Features and Long Deadlines Mean You Have a Gantt Chart, Not a Roadmap Opinions expressed by Java Code Geeks contributors are their own. |
