Over the past couple of weeks, several potential clients have discussed problems they want to fix:
- What are the teams doing, at a detailed level? (The managers want to know when the teams will finish certain features in the short term.)
- How can they plan for six months at a time? (They want to understand and use a team's capacity to plan.)
- When will certain features be done? (The managers promised certain customers/the market/investors certain deliverables.)
Many of these people want to use a tool to plan from the “bottom” (what the teams do) to the top (roadmaps and portfolio). And, they want metrics.
Worse, they want to start with a tool. (That's never worked. See Schedule Game #11: The Schedule Tool is Always Right as an example.)
They think the tool will do “everything” for them.
I have nothing against tools. I use boards and other tools to keep my business running. However, starting with a tool? I've never seen that work. (I wrote a series about that, starting with Agile Approaches Offer Strategic Advantage; Agile Tools are Tactics, Part 1.)
Tools don't help you work better—they reflect how you work now.
Tools Offer Data, Not Problem-Solving
One of the reasons tools don't help you work better is that they can't identify what's wrong. They might help you see that something is wrong, but not what. And the only data the tool offers is based on the data you give it.
And especially for delivery and planning problems? Tools can't tell you where those problems are.
These people are sharp. They know where their delivery problems are:
- Not all the teams get to Done. Why not?
- Because they have dependencies with other teams. Why?
- Several reasons: the managers lead functional silos; they have a combination of cross-functional and component teams; they have legacy code with insufficient unit tests, and more.
The managers have a difficult time planning, because the teams are not as predictable as they need to be for managers to plan.
This turned into a series: