Embedded Files
Last time, we looked at how Scrum has become the de facto definition of Agile, and how it is uniquely lacking in technical practices compared to the other methodologies that were involved in creating the Agile manifesto.
This lack of technical good practices and craft causes some obvious deficiencies, but first I want to look at some of the second-order effects. Starting where we left off last time, one of the problems with Scrum is that product has an owner, the Scrum process itself has a master, but no-one is empowered to advocate for development priorities. (This is part two of my "How Scrum destroyed Agile" series; part one is here.)`
The Product Owner in a scrum is typically someone from the business or product side of the business. They are not there to advocate for technical priorities; and indeed, this is fair enough, because someone needs to advocate for business and customer value. Scrum intends them to be “responsible” and “accountable” for the product backlog, and therefore to work with others to create backlog items, but in practice, they are typically the sole person creating the backlog. So, they are setting the direction of development, but without any thought as to practicalities of the development process.
Then we have the Scrum master. The ideal Scrum master would be someone with technical and product experience, respected in the company as a leader, willing to work as a servant, and outside of the technical or product hierarchy. Unfortunately, the Scrum master is typically someone with limited experience, two days training, who is not respected as a leader but only considered to be a servant, and often in the product part of the organisation (as that is where project management has sat previously.) Often they are even managed by the product owner, or share a boss with the product owner.
Finally we have this self-organised, cross-functional, non-hierarchical, essentially amorphous development team. They are meant to be self organising, with no one telling them how to build the product backlog. However, they have limited or no say over what is top of the product backlog, pressure to deliver something sprint-after-sprint, and no-one with the authority to balance the product owner and advocate for developing with higher quality.
In fact, the whole way Scrum views the development team is completely flawed given how real organisations operate. Quoting from the Scrum guide again:
A note on hierarchy
Disgruntled chorus from the peanut gallery : But Scrum (and agile) is meant to be all non-hierarchical, man.
Sure, it is. But we're looking at real companies, as they exist and are widely understood and managed, and not fantasy constructs.
Disgruntled chorus: But what about the companies where it works?
Well, github was one example, until they realised that they weren't actually shipping things users wanted and their employees weren't actually that happy; holocracy is now out, in are managers.
Valve is the other famous poster-child of radical freedom. And just as soon as they release Half Life Episode 3, I'll be happy to take lessons from them on getting software delivered.
- They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
- Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment;
- Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person;
- Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis; and,
- Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.
The problem with this structure is how it actually interacts with the real organisation structures of a company. Firstly, a self-organising development team should include the product owner in order to find the most expedient solutions to the customers problems; but instead the product owner often works alone and the development team simply receives a stream of backlog items that need to somehow be brought into a cohesive whole. The items promoted in the backlog, combined with the schedule pressure set by the product owner and the business mean that the Development Team often are told how to create releases: quickly and exactly how we said. The lack of technical craft or development control means each sprint is launched as soon as possible rather than as soon as prudent, refactoring isn't done, and technical debt builds up, eventually choking the product.
This has been exacerbated since the agile manifesto because how software is delivered has changed. Instead of yearly or quarterly releases on CD or maybe a download via dialup, we now have webapps being deployed potentially daily or hourly. These endless changes mean there is no natural cadence, so Scrum’s sprint-sprint-sprint means problems pile up-up-up.
As mentioned above, the lack of titles or specific responsibilities in the development team means no-one is empowered to advocate for development priorities, and also contradicts the typical implementation where there certainly are titles and hierarchies within teams. Similarly, not recognising sub-teams doesn’t mean they don’t exist.
Finally, accountability belongs to the development team as a whole, but how is this responsibility actually delivered? Shared responsibilities typical lead to a lack of responsibility. Pressure is put on the higher performing members of the team to deliver more in order to compensate for weaker members and deliver for the team, but this inhibits training and cross-functional work which is at the heart of an effective team.
Now, some of these problems can be and are ameliorated in good implementations of Scrum through good Scrum masters and product owners working with technical leaders. But this is due to people breaking Scrum to work effectively, rather than Scrum working well on its own. And in order to break the rules you have to be confident in them, why they are there, and how they can be varied to suit the needs of a particular team. This can only happen if Scrum masters are highly qualified leaders, and yet many "Scrum masters™" have two days of training in agile leadership.
The invention of the two day Scrum master training course is probably one of the worst things Scrum has done to agile. If you look at responsibilities, a good scrum master needs to be a strong technical manager with a huge grasp of organisational change, but the role is often fulfilled by a non-technical person with limited management experience from the product side of the organisation who cannot fulfil all of those responsibilities. And the idea that two days of training is sufficient to perfect and advocate major organisational change is laughable. (Indeed, most decent training companies would agree with this, and have plenty more training to sell you.)
This Dilbert strip on the management fads from 1994 could be applied to Scrum any time. A “good manager can manage anything” has become a “good scrum master can scrum anything”.
In conclusion, instead of building up the management experience and product understanding of the development team, Scrum hives these functions off, giving the developers much of the responsibility but little of the power. The Scrum master who should be a technical and people leader is sadly often a project manager with a very limited amount of training.
And what little independence the development team are meant to have, is taken away by the process that is imposed. No one is meant to tell the development team how to turn Product Backlog into Increments, but apparently it has to involve something called “Jira”. Next time we’ll look at how Scrum’s inflexible systems and immutable rules stand opposed to valuing "Individuals and interactions over processes and tools".
Agree? Disagree? Comment on Hacker News or Twitter.
Report abuse