This is content that goes a bit beyond Taiga as an Agile platform and tries to convey a self-conscious approach to Scrum. We hope it leads you to a better Taiga experience. For a straightforward approach to Scrum using Taiga please read Scrum quick intro first.
Why would we want to do Scrum? What is Scrum’s promise?
It’s always important to remind ourselves the reasons we chose certain behavioural patterns. We’re supposed to be testing an hypothesis. Without self-consciousness we’re just following some recipes and tools and hoping to improve magically.
Scrum’s promise is simple “if you can achieve team commitment, I can deliver minimum waste and high predictability”. Now, what is team commitment? First, what’s not. Team commitment is not “best effort” approach or wishful thinking. Also, team commitment is not a collection of individual commitments. For the Taiga founders, team commitment is the ability to fulfill a promise under tolerable uncertainty conditions and minimum external context switching while doing it as a unity.
What is Scrum and what purpose it serves
Scrum provides a number of artifacts to achieve this. Those artifacts can be relatively abstract (retrospective) or more tangible (user story) and can be adapted to the project and team’s needs.
Most people misunderstand Scrum with those artifacts and they believe that by following those recipes, they are doing Scrum and being Agile. The vast majority of the Scrum users fall into this sad category, where Scrum is equivalent to short iteration cycles plus dailies, demos and retros.
The simplest Scrum action, to move a user story up in the backlog’s priority
It’s true, though, that through form you may achieve soul but there’s no reason why you couldn’t start with soul and then achieve appropriate form. In fact, many teams start just with Scrum artifacts and through practice they begin to work towards a higher level of “enlightenment”. They do so as long as they realise they are still far from Scrum’s promise. “If you can achieve team commitment, I can deliver minimum waste and high predictability”.
“If you can achieve team commitment […]”
Earlier we said Team commitment is the ability to fulfill a promise under tolerable uncertainty conditions and minimum external context switching while doing it as a unity. Let’s break that down.
- Promise: the selected user stories from a prioritized backlog that go into a sprint.
- tolerable uncertainty conditions: user stories are well defined and estimated within reasonable error margins.
- minimum external context switching: the sprint content is respected by all stakeholders.
- while doing it as a unity: the team finds solutions for the team, no one is left behind. Either the team “wins or loses” as a whole. Shared responsibility is not diluted responsibility.
Team members should be entitled to close their own tasks
“[…] I can deliver minimum waste […]”
- deliver: working software, closed user stories, tangible value.
- minimum: structurally low quantity. By design. Acceptable. Sustainable.
- waste: the main enemy to defeat with Scrum (and Agile). Waste is not exactly the opposite of efficiency. Waste is a much more complex concept. Waste can be operational tactical and strategic. Efficiency tends to be mostly operational. A set of efficient behaviours can still lead to waste.
There are tolerable levels of waste, but what is not tolerable is not monitoring it.
Waste in Scrum (and Agile)
It represents the undesired sub-product of a development process that reduces future delivered value, increments technical debt and introduces friction in team dynamics. It leads to frustration, disorientation and lack of predictability.
It’s tricky to identify what behaviours or actions lead to waste because, sometimes, a meeting can apparently be a waste generator but turn out to be a waste destructor.
Example: “Aki: I don’t want to go to yet another meeting about frontend for this feature, it’s a waste of my time” but later… “Ryu: it was great that Aki was in the meeting, it helped us change our approach, it saved us lots of time!”
“[…] and high predictability […]”
- high: extraordinary. Not seen elsewhere. Desirable. Statistically meaningful.
- predictability: chance of enjoying a satisfactory sprint. Deriving team’s average velocity after a number of sprints. Being able to roughly predict when a user story in the backlog, based on its priority (position), will be finished.
Predictability is such a desirable state… it gives sense of control since we can answer all typical and uncomfortable questions like “when will this be…”, “how we will be able to…” “who should do this…".
Every single software development methodology swears it will deliver predictability. Old methodologies did this by fixing the future. “This is the future, by decree”, they would say. Agile doesn’t dear to do this, instead it says “I promise that, at any point, you will have the biggest value and the smallest waste but I am humble enough not to say WHAT exactly your project will contain as finished user stories”.
The more waste, the less predictability. The more waste, the more “We can’t know”.
Actually, Scrum might actually be able to predict WHAT exactly your project will contain as finished user stories, but for that you need to have gone through some sprints already and learned about your metrics. Which leads us to the last section of this article.
Predictable rhythm based on team commitment
Rhythm speaks of an activity that enjoys and can sustain a particular velocity or rate. Rhythm speaks of order and not of chaos. Rhythm speaks also of necessary unison and collective coalescence. There is hardly any rhythm if every member of a team acts on their own and for their own sake.
Even a sprint burndown can tell us how likely are we to close all user stories by the end of it
When we say predictable rhythm we mean we can identify the core elements of that rhythm and project them into the future. And we can do this because it is sustainable. A rhythm cannot derive from rush work, or if it can, like a super high rhythm, it won’t be sustainable and could lead to sudden bursts of waste.
We can achieve predictable rhythm when there is a sense of purpose because purpose allows teams to anticipate challenges and be ready to sort them out with little effort.
While purpose is always a key ingredient of team commitment, we need to start with team commitment first.
We already talked about team commitment in terms of its essence but Scrum has a clear process to achieve it.
“The backlog is the Product Owner’s property, the sprint is the team’s property”. This means that while the Product Owner is expected to have a good quality backlog, the sprint content is a decision made by the team. When a team says “this can go into the sprint” it must mean “there is a very high chance that we will have this done at Product Owner’s satisfaction by the time of the sprint’s demo”.
A team can commit to what they have *freely and responsibly aligned themselves to. If they have no say in what goes into a sprint, team commitment doesn’t exist and we will simply speak of “best-effort”.
Although this is very tempting for Product Owners as “best-effort” could work and requires fewer meetings and explanations, in the absence of team commitment, there is a high risk for a team of alienation and distancing from their results.
Further reading
We would encourage you to read the Taiga Blog’s article “Four Agile Antipatterns and a big fat lie” where you will see particular antipatterns that lead to a disastrous experience with Scrum. Your ability to avoid them will surely contribute to not only feel but know you and your team are in control.
