I have often witnessed teams getting themselves into trouble by focusing more on activity than value. Many people, especially those lost in the middle of a formal hierarchy, are appeased by people doing stuff, it almost doesn’t matter what the team are doing as long as they are busy. It is back to that old attendance over performance metric.
Teams being busy and working hard is only a problem if the alignment of what they are working on cannot be directly drawn to the problem. It is normally the case that their activity can be traced to a request to do something, but tracing to a level deeper – to the underlying problem, is where issues arise. To make things harder, the consequence of the discrepancy between problem and activity isn’t seen until late, when users expect something to change and the new stuff brings the usual change management but fails to solve the original problem.
There is still too much focus on WHAT over WHY. I support the concept that when writing user stories we should start with the “So that…” to force the point but that assumes that the stories even have that line at the end though.
I suggest starting each sprint planning or backlog refinement or coaching engagement or frankly anything, with this simple mantra:
What is the problem we are trying to solve, how are we measuring it, and by that measure what is our definition of success?
The first answer to the “WHY” question often solicits a rephrasing of the deliverable. “I want a widget so that I have a widget”, yes ok, but WHY do you want the widget? What does the widget enable? What does it give you that you don’t currently have? Who actually benefits from this widget? Why is the budget holder going to pay the team for the widget? You really have to get to the heart of the problem and this can be a difficult conversation – because – and this is the scary part – the people responsible for delivering the project haven’t fully understood the problem, and highlighting this after the problem has started can be uncomfortable for some as it could be seen to reflect poorly on the project leaders. It can be the case that projects continue blindly just to save face.
The way in which backlogs are usually described is a cascade of big deliverables to solve problems called “Epics” that are broken down into associated stories. Many teams have lots of stories but have lost the association to the parent Epic – to the purpose. This leaves lots of activity, lots of well meaning work but a massive risk that the work lacks direction and will not deliver the value that the effort deserves.
Slow down, be problem centric, not solution centric. This will help align to principle 10 of the manifesto, “Simplicity – the art of maximising the art of work not done – is essential”. If you just focus on solving the problem rather than delivering the widget – you might find you can deliver a smaller widget!
philagiledesign 