Iteration + Increment ≠ Improvement
I sometimes see Scrum-(flavored)-teams that iteratively produce incremental work and expect that improvement is the result. But I think improvement is not automatically a given from this way of working.
First of all, let’s talk about what I mean when I’m talking about increment, iteration, and improvement. And even more important is how the Scrum guide talks about these terms.
Increment
The Increment is in the core of Scrum as one of the Scrum Artifacts. The Scrum guide mentions the increment in several contexts. In short: The increment is the output of the team. But also part of the definition is:
Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together.
From what I read there, work has to be connected to previous work. It is an addition, by definition, not necessarily an improvement.
Iteration
In contrast, the iteration (as iterative) is mentioned just one time in the guide:
Scrum employs an iterative, incremental approach to optimize predictability and to control risk.
The iteration is mentioned together with the increment. I understand it as in the meaning of repetition, not in the sense of refining and tweaking what is already there. The Scrum guide speaks about having a rhythm of events, resulting in creating a product in smaller steps.
The meaning of the word iteration can imply improvement. Sometimes people expect by working iteratively, the quality of the product is automatically improved. But working with an iterative process (which brings many benefits like predictability and risk control) doesn’t say much about the produced result. To my understanding, the Scrum guide doesn’t emphasize here on quality but describes how to work in short cycles with repeating events.
Improvement
Improvement is also mentioned several times in the Scrum guide, but mostly in regards to team practices. One time, regarding the product:
The Product Backlog is an emergent, ordered list of what is needed to improve the product.
Maybe here is part of the culprit. Without any inspection and measurements after releasing an increment, the Product Backlog Item is a bet on improvement. Every increment has the potential to improve the product. But in most cases, nobody can guarantee that the planned work is successfully improving the product. So just working iteratively in increments doesn’t automatically lead to a higher quality of the product.
Iterations don’t automatically lead to improvement
One of the expectations when working with agile frameworks like Scrum is to make teams more efficient. For example, Jeff Sutherland states: “The process efficiency of executing a story on a Scrum team is the most important metric for team performance […].” Concentrating on metrics like velocity (interpreted as quantitative throughput) enforces that belief.
This concentration on story execution can be interpreted as creating a better product. But delivering more doesn’t automatically lead to a better product. A lot has been written about that, so that I won’t repeat this discussion here. In conclusion, the argument is that without finding out why a specific thing should get created and measure the actual change in user behavior after creation, just creating something doesn’t lead to value creation.
Related to this, Scrum explicitly talks about quality within the Sprint regarding an increment. It also ensures an agreed level of quality through the Definition of Done. The Scrum guide emphasizes quality and value delivery but doesn’t incorporate strategies to inspect the quality and measurement of created value after the increment has been delivered. And I think focusing just on the delivery of the current increment can be a problem. Because by concentrating just on the Definition of Done, teams are not encouraged to inspect the actual value creation for their product.
I see many teams creating features in a looped framework without revisiting the former features and inspecting them for quality and value. Commonly known as a feature factory, teams create one increment after another, building on top of each other and creating new features. As a result, products get mostly bigger and more complex. Most released product aspects are only revisited, analyzed, and improved after long time intervals.
For example, if teams receive concrete feature requests from outside stakeholders instead of business and user problems, the Product Backlog will consist of numerous unconnected features. Feature after feature is stacked on top of each other — Sprint by Sprint. The Product Owner writes the tickets with new features requested by stakeholders. Things are defined and delivered. Teams are more or less working on an endless To-Do list. After delivering work to the end-user, it is often not validated. The features stay there for a long time, without inspection. And Business value or user success is not measured along the way.
By working this way, increments and iterations are reduced to linear work. Complex problems are tackled with the mindset of a production line. With that, half of the power of agile frameworks is disregarded.
Teams need to be able, and often more important — to be enabled to tackle business and user problems. They should come up with potential solutions, validate and create them with the consciousness that this increment is a bet, not a final solution.
The core concepts inspect and adapt, and empiricism should not just be practiced for the team process itself but should also be practiced concerning the product. Some teams tend to concentrate only on quality or value within the Sprint regarding the Definition of Done. By that, reducing to a specification of internal and technical quality. Rarely do I see a benchmark and measurement of quality and value for the end-user after increments got delivered beyond the Sprint.
Scrum is not the problem
Ok, now you might think I don’t like Scrum, and I claim the problem lies within the framework. And as mentioned before, to some extent, there is some truth to it. For example, Scrum uses the term value ambiguously with different aspects. Scrum is historically pushed from a software development side, not from a product design or product management perspective. So it is no wonder that teams focus on technical quality, and many teams don’t even have a routine conversation about business and user outcomes.
But Scrum is in a lot of aspects vague. And I respect that. Scrum should fit in a lot of situations and contexts, and that’s great about Scrum. So don’t blame Scrum. It is your job as a team to create the best possible product, and Scrum is just one tool of many to help you achieve this.
The Scrum guide itself says that the team is responsible for defining what value means for every Sprint. I suggest including the discussion about value and quality for the product regularly. Use the Sprint goal and Product goal to keep the conversation going on value for the user and the business.
Additionally, the Scrum guide states:
“Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together.”
So Scrum actually encourages to keep the whole product always in mind and connect every increment to its context.
If you have the feeling, that you as part of a Scrum team, are working on an endless To-Do list, you and your team have to build additional strategies around Scrum. Everything the framework is not explicit about is up to the team. Scrum does not describe how to program or design, and it also doesn’t explain how to create a great product.
Understand your business motivations
Maybe you see patterns like in a feature factory in your team. So what to do now? The first step is to start a discussion about business and user needs regarding your backlog items. If your stakeholders approach you with a solution like “We need a user login,” figure out together with your stakeholders why they need it. What is the business need behind this feature request, and what can users achieve through it?
Maybe your stakeholders want to have more recurring users or wish to have a better way to offer different services for different user groups. There could be a lot of motivations for such a request. Try to get to the bottom of it before investing a lot of time and effort into building the requested feature without really knowing the underlying goal.
The Product Owner should facilitate the process involving the whole team. That doesn’t mean that every team member has to be included in every discussion. Still, the entire team must understand the goal and reflect it from different functional and personal perspectives.
Start with an idea
After you figured out together with your stakeholder what the real business goal and connected user need is, start to ideate possible solutions with your team. Usually, there are a lot of approaches to reach the same purpose. Don’t plan them out. Just collect the ideas so everybody knows what the given solution would roughly look like.
To collect and connect different approaches, an opportunity solution tree can be helpful.
After collecting your first approaches, come up with the simplest possible first iteration. What would be the minimal solution, and what are the most significant risks connect to that? The risks could be in usability (people don’t understand how to use it), in feasibility (you don’t know if you can build it), and viability (your business can’t sustain it).
Weighting your ideas against each other shows which candidate you should approach first. Maybe there are two or three good alternatives next to each other. You can start to investigate in parallel, but don’t invest too much time and money into parallel work. Better start with the most promising and pivot to the next if it doesn’t perform to expectation.
The idea finding and selection process can be done in a short workshop, don’t spend days or even longer on this. One or two refinement sessions should already be enough to find a first candidate.
If you already have a clearer picture of how the final feature should look like. It helps break it down, get to its core, and take this as your starting point. Some ideas will come in handy later on, but actual user feedback will probably steer you into more valuable directions.
Breaking the linear cycle
After having this first idea, it is time to start building. Depending on how sure you are about your solution, different increments can be defined. It could be that you need to create simple prototypes first to learn more about your user behavior. Or it could be that you first need a technical spike to mitigate technical risks. It makes sense to incorporate this work into your Sprint to be visible and not regarded as second-class work. Try to deliver your first version as soon as possible and release it publicly, in beta/private groups, or as A/B tests. Whatever you have at hand and what fits your risk profile.
From this point on, you can truly start iterating on this feature. The first iterations probably will show that this is not the best solution, necessary functionality is missing, expectations from you and your team were not correct, etc.
But don’t try to come up with the perfect solution before start building, don’t write everything in Product Backlog items, and then start to treat it just as a long To-Do list shoved into Sprints. Come up with the simplest solution, which you can build in days.
Build upon your solution increment by increment until it is good enough or until you see that this is probably not the best solution, and you should change direction.
Scrum is perfect for this kind of work. You have the Daily Scrum to talk about the next step and impediments. You have the Sprint Review to control if you are on the right track with real-world insights and feedback from users and stakeholders. And you have the Sprint Planning to discuss what the following improvements will be.
But what when you know what to build?
Sometimes there is work that is not unknown, not complex, or risky. If you are sure that this is the right solution, if you have evidence, then, of course, don’t overcomplicate things, just build it. If it takes longer than your Sprint, cut it down. Concentrate on the essential use case first. Deliver the feature in a minimal way because this gives you, on the one hand, the chance to already learn from actual users, and it protects you from not delivering at all because the world changed around you.
If you start to spend many Sprints building straightforward and easy things, maybe Scrum isn’t the proper framework for you because you can just implement it piece by piece with a project plan. But I would get suspicious. I haven’t seen an exciting or innovative product where everything was clear, the outside world didn’t influence it, and risk was absent.
In short:
- Don’t convert your Scrum practice into a To-Do list.
- Always keep the end-user in mind.
- Build small & simple solutions.
- Inspect your solutions with data from the real world.
- Iterate, as in tweak and refine, on these solutions with small increments.
- Improve.
