Agile methodologies are based on incremental and iterative product development. Just breaking the product into parts is not what you want. Each of these parts must have value: if they don’t, you are not iterating - you’re just in a disguised waterfall.
Agility
Taking a look at the Scrum Guide:
Scrum employs an iterative, incremental approach to optimize predictability and to control risk.
Extreme Programming (BECK) has practices like Incremental Design and Incremental Deployment which are clearly related to delivering incrementally. Other practices like Weekly Cycle and Quarterly Cycle relate to planning product development in iterations.
Incremental and Iterative
You may be asking yourself what iterative and incremental mean:
-
Incremental: you deliver parts of the product while developing it, instead of delivering the whole product at the end. Each part you deliver is aggregated to the previous deliveries.
-
Iterative: you repeat the development steps in small cycles (like in PDCA). You deliver value at the end of each iteration. Then you incorporate the knowledge you gained by working in the product and feedback you received from the delivery to plan the next iteration.
Why doing incrementally and iteratively is better than to plan all upfront, then delivering at the end of a project?
It is a waste trying to have all the information you need to develop a product at the beginning:
-
You start gaining technical knowledge about the product you’re developing the moment you start developing it. Everything before is just a guess. It may be a well-grounded guess, but still a guess. Also, creating a whole design upfront may lead you to create a flexible design. All this flexibility may (not to say will) result in unneeded complexity.
-
You start receiving feedback the moment you put the product in the hands of users. You may have already business knowledge, but you can’t guess what the customer needs/wants. You can’t validate if you solved customers' needs if they can’t, at least, test your product.
Every increment is an invaluable opportunity for feedback. You should use it to adapt your plans often (at each iteration), so you can maximize value.
Evaluating the Increment
You don’t deliver code to your customers. You don’t deliver effort. You don’t even deliver functionality. Why? Answering with a question: Will your customer be happy if your product does nothing he/she needs, even if you have 100k+ lines of code, 150+ man-months worth of effort, and a huge list of functionality? I don’t think he/she will.
At the end of each iteration, if a customer can’t already use your product, he/she should be able to test it. If your customers can’t test it, stakeholders should be able to evaluate the product. If even stakeholders can’t put the hands in your product to evaluate it, you may be creating technical increments that, by themselves, have no value at the moment. And I mean that: it doesn’t matter how much effort you put on something. If it is only technical stuff that will make no difference to the user by the time you consider it done, you’re losing time. You’re also losing a great opportunity to receive feedback about your product.
The feedback you receive is what will keep you on track for maximizing the value you create via your product. If you delivered something that wasn’t what the customer needed, you will know it and can adapt your product in the next iteration. If you deliver technical things in one iteration, do it again in the next, and again, and again until you finally deliver functionality the customer didn’t like, you are now 4 iterations late: you thought you were delivering value when, in fact, you were delivering:
- code or effort, which makes no difference to the customer
- functionality, which was wrong and it took your 5 iterations to realize it
Doing it correctly is hard. And excuses for putting value aside may arise.
My –Something– is Too Complex to Deliver Value Incrementally
Substitute the word something with: product, business scenarios, integration with other systems, the organization I work etc. Those things may be complex, I agree. Sometimes more complex than they should. This fact does not prevent you from delivering value incrementally.
The increment you deliver does not need to be an end-to-end business scenario. It doesn’t need to be the complete functionality. It should be something that you can use to gather feedback. It should be something that you can explain the value of delivering it now. If value comes only in groups of deliveries, taking more than one iteration to create, this is not incremental in an agile context.
How Can I Express Value Incrementally?
I’ll provide two hypothetical examples of a team developing a media player. The product has to show the information of the song that is playing. Doing everything in one iteration is impossible, because it is above the capacity of the team. The value of showing song’s information is understood by the team and stakeholders.
A Good Example
Consider the following sequence of iterations:
-
First iteration the product shows the song name. It may seem a little, but the team had all the effort to read song’s metadata and to create a crude, very crude, user interface.
-
The second iteration the product shows the artist and album information. Here the team refined the user interface based on the feedback received in the first iteration. When showing this nice refined user interface, people asked about the artwork. The team realized this is important, even if in the initial plan this feature had low priority.
-
In the third iteration the artwork is shown. The team needed time to find out ways to retrieve artwork from the internet, and the user interface got some improvements based on more feedback. Other labels received content, like release year, genre etc.
You see the team was focused on showing the value they created at the end of each iteration, even when working with technical stuff like reading song’s metadata. They create an increment with low effort (the crude user interface) to get concrete feedback before putting too much effort on something they had little knowledge/experience.
A Bad Example
Now let’s see when the team focuses on delivering technical things:
-
The team works in creating the toolkit to read metadata, and some basic components to be used in the user interface. When the team mentioned the work in user interface components, people were surprised. They expected to see the user interface, but the team had to explain they were working with components to put in the user interface, not the user interface itself.
-
The team continued to work in the user interface and treated it as priority. After all, people seemed to be upset at the previous iteration because they didn’t see anything. At the end of the iteration, everything is in place for the user interface: the label for the song’s name, artist, the artwork, release year, rating etc. It was a lot of effort to create this user interface because the team wanted it to be awesome! But nothing works: the team just created the user interface without functionality. That is shown, and the team receives lots of feedback about the positions, colorscheme, sizes and so on.
-
The team needs to address the feedbacks received about the user interface because, after all, they make complete sense. 80% percent of iteration’s effort is focused on that. It hurts deep inside to see almost every part of the user interface to be rewritten. The team put so much hard work on it during the previous iteration. The remaining effort goes into integrating the toolkit to read metadata and populating the labels for the song name and artist. You receive some more feedback about the user interface and is asked about when the artwork will be shown.
As discussed before, delivering code is not what your customer wants. It shouldn’t be what your stakeholders want. In the second example, the team created a lot of code in the first iteration, at the same time they delivered little to none value. The second iteration had much effort creating the UI, and, again, little to none value - they needed to modify it a lot after receiving feedback.
Breaking the work into technical deliveries and seeing delivery of value in a far future can (and probably will) slow you down. It may not slow you in how much effort/code you can deliver. It will slow you in how much value you can deliver. Without business value being delivered each iteration, feedback becomes meaningless.
There’s Always Exceptions
Think a team needs to plan the effort of migrating a service to another provide, because the current will be deprecated. You can’t put that into users' perspective because it will be transparent to them. The only way you can think of describing the value is making everyone happy because your product will continue to live.
In cases like this, I can agree that the team can focus on technical work as the requirement. At the same time I think the argument that a requirement cannot be broken into smaller, still valuable, requirements from a business perspective is a crutch for poor backlog management.
Who Is Responsible For The Value?
When we talk about Scrum, there is the role of Product Owner (PO). This person is responsible for managing the Product Backlog (a list of things to be included in the product as steps towards the Product Goal). The work of Developers in a Scrum Team comes from the Product Backlog.
The Product Backlog should provide transparency on how the Product Goal is to be achieved. It is the PO’s responsibility to demonstrate how each item in the Product Backlog relates to the Product Goal.
Done technical stuff is necessary for the product, no questions on that. But creating technical Product Backlog items makes PO’s life harder.
If the PO breaks the Product Backlog Items into technical parts, value will be generated only when all these technical parts are done. This is not agility, this is the waterfall model adapted to iterations.
The PO must focus on breaking the functionality in smaller parts, where the value can be inspected. To do so, technical restrictions pointed by the developers must be considered. But these technical restrictions shouldn’t be independent backlog items themselves.
Thinking on the previous examples: The PO can say to the team “We need to show the information of the song in the user interface”. The team can think about the technical restrictions and inform the PO. The whole team collaborates on refining the Product Backlog, with the PO making sure every backlog item has business value, fits the iteration size and is inside the technical constraints pointed by the team.
Focusing on value will make developers life will be better: instead of just creating and assembling parts of the system, they understand how their the importance of their work. Meaning and purpose are great for motivation.
PO’s life will be better too: when the team creates value each iteration, relevant feedback may be at PO’s disposal to better shape the future of the product.
What is your opinion on this topic? Should everything have clear business value or are you OK with technical requirements? What challenges you have dealing with this (in any role) when developing a product?
References
[SCRUM]: Schwaber, K. Sutherland, J. (2020). Scrum Guide: The Definitive Guide to Scrum: The Rules of the Game. Available at https://scrumguides.org/scrum-guide.html
[BECK]: Beck, Kent (2005). Extreme Programming Explained: Embrace Change (2nd edition). New Jersey: Person Education Inc.