For me, Agile/Scrum is about collaboration, not planning or prioritisation
Last April, Eric Elliott wrote about the importance of choosing the right metrics and KPI’s for business planning and prioritization.
As a part of his argument, he also included an elaborate rant against using Agile/Scrum. According to the author, the lauded development methodology isn’t agile at all (even though it was originally conceived by Jeff Sutherland, one of the co-authors of the Agile Manifesto).
The rant gets stuck in a reiteration of all sort of common annoyances with the perceived micro-level management tools that come with the methodology: the daily stand-ups, the sprint planning sessions, backlog refinement, retrospectives and the pressure of getting the perfect stable velocity based on arbitrary “story points”.
Agile/Scrum is not about prioritisation
The article argues that all these meetings are not part of being agile. To Eric Elliott, being agile means setting the right priorities based on the right metrics. I wholehartedly agree with that view, however, I refute his conclusion that the Agile/Scrum methodology is at the root cause of erroneous prioritisation / planning.
To me, stating that stakeholders and development teams make bad prioritisation decisions because of the inflexibility of Agile/Scrum indicates that the team took a wrong turn during the implementation phase. It is my experience that this usually happens if the methodology is implemented by (product) managers, who think that they can use it as a tool for fixing the unstable quality and quantity of the software engineering department output.
If you start using velocity, team commitment and burn down charts as resource planning tools and stakeholder expectation management, I can fully understand the hatred that software engineers develop against Agile/Scrum and the desire to start ranting about them online. But they might be focussing their anger at the wrong, albeit easy, target.
Prioritisation of tasks should be based on the company goals, on business values and customer needs. If possible, meaningful metrics and KPI’s are used by Product Owners and stakeholders to quantify and monitor those goals, values and needs.
Agile/Scrum is about collaboration
The first item on the Agile Manifesto reads:
Individuals and interactions over processes and tools
To some extent, one can argue that Agile/Scrum is not agile because it introduces a set of processes and tools. However, it is also important to note the following addition at the bottom:
That is, while there is value in the items on the right, we value the items on the left more.
Yes, it is true that Agile/Scrum introduces new processes and tools. But the goal of those processes and tools is to accommodate the focus on individuals and interactions.
All of those dreaded meetings are a means for increasing meaningful interactions and to help individuals (and consequently teams) grow:
- Daily stand-ups give team member the opportunity to share what they are working on, if they experience impediments and to tap into the collective knowledge base to see if they can fix / improve their work.
- Backlog refinement meetings are about aligning on the shared understanding of the requirements of a user story and to have discussions on how to solve a (complex) problem. The goal of the rather arbitrairy estimation system of story points that denote complexity (which is just as arbitrairy as time) is not for planning purposes. It is meant to get individuals and teams out of their comfort zone and trigger meaningful discussions.
- Sprint planning sessions allow teams to re-align on the priorities and understand what they will be working on. It is the perfect moment for interaction between the Product Owner (and other stakeholders) to share the sprint goals with the team and to allow them to transcend from feeling like code monkeys to being part of a bigger scheme.
- Retrospectives are meant for teams to take some time to look back at their work, at their processes and interactions and discuss what they did right and how they can improve. It is again a way of having a meaningful conversation on what happened during the week and to learn and grow, both as individuals as well as a team.
- Demo sessions give a team the opportunity to reconnect with the company and to get valuable feedback on the output. Comparable to the sprint planning sessions, it allows teams, Product Owners, stakeholders and other interested parties to interact with each other and discuss the product.
As you can see, there is a pattern in these meetings. They are all about the interactions that allow individuals and teams to learn and grow. Many of the above interactions might seem logical, but will not come naturally for most individuals and teams in software development. This is where a methodology like Agile/Scrum can help out.
Agile/Scrum is also about metrics
There is one more part of the methodology that we haven’t discussed and that might sound rigid: the 1–3 week sprint iterations.
If Agile/Scrum isn’t about planning, then why would you have sprints with (semi-)fixed scopes? The most basic answer is because it allows you to collect metrics, which are required to make informed decisions on improvements and track their progress.
Well known metrics like team velocity and burn down charts need a specific time frame to become comparable. And with any other situation, the metric itself isn’t the end goal, it is a trigger for reflection. It allows for questions like “Why did we not achieve what we set out to deliver 2 weeks ago?”, which in turn are meant to create a deeper understanding of possible problems and frustration. These can only be fixed if they are expressed in human interaction.
I would love to meet the Product Owner that will block that one issue from being resolved that results in a $1MM/Month increase of revenue
I personally believe that any period longer than 3 weeks will result in a skewed perspective on the individual and team performance. And although it is true that fixating on a 2–3 week iteration may feel like you lost control over your planning/prioritisation, it doesn’t have to be this way. I would love to meet the Product Owner that will block that one issue from being resolved which results in a $1MM/Month increase of revenue.
Having a semi-fixed sprint scope is only a method for creating a stable learning environment. It is not a dogmatic rule. It doesn’t mean that it will start raining acid if suddenly it is deemed wise to spent time on this awesome user story, bug or technical improvement. You can be as agile as you want to be with Agile/Scrum (what’s in a name).
You should simply be aware of the tradeoff between agility in priorities/planning and creating an environment that facilitates interactions and a positive learning environment for individuals.
So why doesn’t Agile/Scrum work for me?
If you felt that Eric Elliott’s article reflects your situation, Agile/Scrum will probably not work for you.
In order for Agile/Scrum to facilitate meaningful discussions there must be an emotionally safe working environment
As the Agile/Scrum methodology is only a framework to facilitate interactions it means that, by definition, this system will not work for all teams. It requires a specific set of underlying core values to be available.
For me, those core values include a wholehearted believe in the value of day-to-day collaboration and the requirement of an emotionally safe work environment to facilitate meaningful discussions.
If you feel that all these meetings distract you from doing your actual work, and you do not see value in day-to-day collaboration, don’t use Agile/Scrum. However, don’t be surprised when this means that you will run into situations where, because of the lack of alignment, your team members, Product Owner or company does something you don’t agree with.
By cherrypicking from the Agile Manifesto and thinking that the only agility that matters is about prioritisation / planning, you are not doing right to the majority of the core values that are encapsulated by the authors.
