When does your agile team need to deliver value?
A lot of teams call themselves “agile teams” these days. When asked what makes them agile, the response is often that they “do Scrum” or perform a bunch of agile practices like having a retrospective, working in iterations or using a backlog.
Which is of course fine, until…we start talking about value delivery.
I come across quite some teams (not yours, of course) that seem to be unable to explain what value they bring at the end of each iteration. They are often confused when I ask questions like:
- What value does each of your backlog items bring? And to whom?
- What types of value do you distinguish?
- Which stakeholders do you usually invite to your iteration reviews?
- Are your stakeholders happy with what you delivered last sprint?
The answers I get are usually along the line that “creating value each sprint is impossible due to the nature of our work”. Which explains that work often isn’t finished by the end of an iteration and why some teams don’t have meaningful discussions with their stakeholders on a regular basis. Why would you anyway, if value delivery can be postponed?
Now I am not the kind of person that will tell you that you are not agile if you won’t deliver value each iteration. But I am unforgiving when you have no clue as to WHEN value has to be delivered and WHY that matters.
For me, being agile means (among other things) that you are able to deliver value when it matters. That doesn’t necessarily have to be every other week. BUT it has to be delivered when it matters and not a moment later.
If there isn’t any need to deliver value every iteration, then perhaps you shouldn’t feel too upset when you don’t. However, it would be rather nice if you COULD deliver value whenever you want to. That’s why frameworks like Scrum exist, why practices like continuous delivery and test drived development came into existence, and why people build tools like Jenkins, SonarQube and Cucumber.
So yes, you can get away with using your product backlog as a task list. You will receive no complaints when half of your work isn’t done at the end of the sprint. Stakeholders may even feel relieved when you decide to excuse them from attending the sprint review or skip the event altogether.
However, in the long run there will be trouble. Foremost when you have been delaying value delivery and still can’t deliver the value when it matters.
When value is delivered only after it matters, you fail. You may defend that it is a learning instead, but actually it isn’t. You could have anticipated. All the principles, methods and tools are available to do so.
Learn everything you can about the value you need to deliver. Before you start and during the course of your work. Whenever it becomes apparent that you cannot deliver value every iteration (and thus are also unable to validate the actual value of your work every iteration) at least ask yourself when it must be delivered to matter.
Then work to make it so.