Originally published April 2017, this blog post was the first time we wrote about how the backlog could disconnect the team from customers.
Most models of agile software development portray the product backlog outside of the team. This is because, with the original small team focus of agile methodologies, the world began and ended with some customer representatives. For example, in Scrum, there is a Product Owner who is responsible for ensuring the team has a “ready” supply of backlog items and accepts the increment of working software delivered. What happens beyond the Product Owner is apparently not the team’s concern, and the team does not care how the Product Owner got the concept, how the analysis was performed, or how the design was created, just as long as they are not starved for stories.
From my point of view, this traditional view encourages a coding-centric view of agility and is misleading because it implies the purpose of the entire organizational ecosystem is to supply a software team with near “ready” backlog items that the team codes and tests into “working software.”
Coding is but one step in the creation of a valuable product, and to view agile teams strictly as just “design-build-test” teams is to completely devalue the work done by everyone else in the value stream. Nearly 40 years ago, in an article entitled “No Silver Bullet: Essence and Accidents of Software Engineering” (IEEE Computer, Vol. 20, No. 4. April 1987. pp. 10-19. Accessed 7 July 2019. https://www.researchgate.net/publication/220477127_No_Silver_Bullet_Essence_and_Accidents_of_Software_Engineering), Frederick Brooks wrote:
“The hardest single part of building a software system is deciding precisely what to build.”
While there is clearly no valuable software product without “working software,” there is certainly no valuable product without the analysis and design to determine precisely what to build. It’s not enough to build the thing right because to create value we also have to build the right thing. It is wrong to offload and sweep under the carpet the hardest part of systems development to some undefined upstream process to create the illusion of coding agility. Analysis and design still matter.
What if, rather than representing the backlog as a means for just “feeding” a development team, we call out ALL the work required to create a product or service and show EVERYTHING the team is fully responsible for? They are responsible for all the work that must be done to deliver each increment of working software – not just coding and testing but also analysis, design, and whatever other upstream and downstream activities are necessary to go from concept to cash. We have seen far too many organizations where analysis and design work is “invisible” or managed using a traditional stage-gate model.
Placing the backlog at the center of the team is an attempt to create a new visual where the whole team is responsible for all the steps required to create a product, from ideation to delivery. The whole team not only builds the system but is also involved in “…deciding precisely what to build”. The whole team performs the analysis, design, implementation, and deployment steps.
This means that everything we pull into planning will not necessarily be written as a traditional user story that yields some idealized slice of feature functionality. There are going to be backlog items representing analysis, design, packaging, and other work. For example, during a Scrum-style sprint planning meeting, a Business Analyst may take on the work to model some of the backlog items, perhaps to create a use case brief for a feature.
Don’t get me wrong, I am not advocating for traditional long drawn out analysis. Agility is about fast learning cycles, and our analysis and design need to be part of the fast learning cycle. While the output may not be production-ready “working software,” – the output still needs to add verifiable knowledge that creates valuable learning. Pulling a line from the Scrum guide, any work we pull into a sprint from the backlog should still “… include test descriptions that will prove its completeness when done”. Just showing a “textbook-perfect” use case diagram at a sprint review is not useful. Rather, if we pull a backlog item to “analyze and design,” there still has to be value generated in the form of validated learning. There has to be some demonstration, some proof that the model works – perhaps a code fragment implementing a slice of the model, an executable simulation, or even just a walk-through. While we are arguing against a coding-centric view of agile teams, the intent behind the Agile Manifesto value statement “working software over comprehensive documentation”, which is getting something valuable done, still applies.
Some may legitimately raise a red flag here suggesting that I am encouraging the waterfalling of sprints – a sprint to analyze, a sprint to code, a sprint to test. This can indeed happen, but I would prefer this problem be explicit and an issue the team can work to resolve in a retrospective rather than sweeping it under the carpet and having the team believe they are truly agile and righteous. My argument is for making ALL the work visible. Placing the backlog at the center brings all those other people, who are traditionally thought of as being on the outside, and makes them visible and part of the team. It encourages us to apply agile thinking to analysis and design and whatever other processes are required to transform an idea into a valuable product or service.