Street Cred
I’ve been in the software development industry for 21 years, using agile software development practices and principles for 14 years to actually deliver software. I’ve been working with Scrum for nigh on 11 years now and over the last 7 years I’ve coached over 120 teams and worked with over 1200 people.
With all this experience one thing has become clear – Scrum is broken.
How I assess the quality of any agile process
In theory, it seems all neat and tidy, but in practice it is abused, misused and generally ineffective. And I wonder why? I have seen many more poor implementations of the Scrum framework than successful ones. Actually – let me be explicit about how I assess the quality of implemented Scrum.
For me the success of *any* organisation’s way of working – formal or otherwise – can be checked by simple questions that explore 5 fundamental concepts:
- Value: Do we know the value we seek to deliver and are we consistently delivering the maximum value?
- Flow: Do we understand how we reach that value and are we consistently reducing the time and/or increasing the ease by which we reach it?
- Quality: Do we understand how good our product and workmanship needs to be and are we consistently and demonstrably achieving it?
- Joy: Do we know what we collectively and individually need to be joyful and are we consistently meeting those needs?
- Continuous Improvement: Do we know what we need to improve across VFQJ and are we demonstrably pursuing those improvements?
This simple list of questions invites great questions and other avenues of inquiry. It can function as both binary (yes/no) and range (how well are we doing). Works for me – mostly.
The non-recipe recipe
The fundamental reason why Scrum – as it currently exists – is broken is that it is a set of instructions, roles, rituals and artifacts that purports to *not* be a recipe. But almost every one takes it as a recipe and they follow it. But there is not enough there to be a an all encompassing recipe – there can never be.
The trouble is that, as a product , Scrum needs these illusions of completeness in order that it is taken seriously . By and large this has worked. In a world that is seeking silver bullets, Scrum has succeeded beyond it’s practicality commands. It is by far the leading agile process framework in use today. It is in this illusion of completeness that lies the myriad of problems.
I remember in 2008 or 2009, there was a statement about there never being ‘Scrum 2.0’ – that Scrum was complete as it is. A perfectly chiseled gem that needed nothing removed nor added. This was clearly bollocks and persisted until politics and greed spilled over in the Scrum Alliance causing a bitter split between one of the co-creators of Scrum and the rest of the Alliance. All of a sudden a Scrum 2.0 in emerged in all but name.
When people have applied Scrum as a recipe the commentary from the unsympathetic dogmatics has been of the nature of:
“ScrumBut”
“Scrum shines a light on where you need to fix in your organisation”
“Scrum works, you just did it badly”
“You didn’t have buy in”
Overwhelmingly any reasonable objection to some of the design flaws – and design flaws can emerge after the fact , exposed because of a change of operating environment etc – is often met with “those people are resistant, they are against change”.
When Things Work, Its the Process – When They Don’t, It’s The People
I was first attracted to Scrum because I believed it would revolutionise the ‘world of work’.
10 years on and I’m deeply disappointed. It did not revolutionise the world of work. Instead it got gobbled up by the Death Star of Work. If it had any early promise – for me it was that it would promote unprecedented collaboration between the people focused on delivering value and the people consuming it.
It may have had some success in some organisations – but this is far from ‘changing the world of work’. A tiny street maybe, but never a world!
Of course a process doesn’t do anything – people do. But how a process is designed has a huge impact on how readily the people take to it and how easily they can use it for the intended purpose.
More often than not I see a growing perception of infallibility of a process and an overwhelming blaming of the teams and individuals who play the Scrum roles. I feel deeply sad and angry at this.
Multiple single points of failure
Scrum Master, Product Owner and Team all collaborating beautifully – each with its clear role and responsibility – what’s not to love?
Except that in *most* companies roles are so entrenched and siloed that this is the worst thing you could do – add more roles that become siloed. I hear you scream – “yes but the problem is the organisation and not Scrum” – and you are both right and wrong.
You are right because it is the organisation that is siloed and you are wrong because adding more roles when you *know* that most organisations are siloed is a dumb idea. That is like asking the morbidly obese to incorporate 3 more meals – however small – into their already dangerous diet.
Defined roles and a culture of collaboration are difficult bedfellows in any context. Especially in the context of trying to explore value through . Defined roles present an extra hurdle to overcome as we truly try and work together.
I have seen product development be disastrous for many reasons and the most common one is the single point of failure problem. Examples abound:
- Overworked, overextended and ineffective Product Owners;
- Scrum Masters left to single-handedly be responsible for improvement and impediments and latterly ‘coaching’ the team.
- Teams that aren’t to effectively own their tools, their craft or their collaboration.
Rituals become checklists vs achieved outcomes.
If I have to walk into another planning meeting that is schedul for 4 hours because Scrum said so – with the hope that somehow the information we don’t have about the work we are expected to commit to will magically appear – I may have to shoot some unicorns.
Sprint after sprint, people do the meetings, the stand ups, the reviews etc. Scrum Masters – bless ’em – scour the communities for how to make their standups more interesting. Velocity is going up, teams are 7±2 people – things in the product backlog read like ‘As a …, I want…”. The process seems to be working perfectly.
Yet software is still sitting on the shelf. Customers are not getting anything to feedback on. Developers still don’t talk to customers.
Velocity becomes a stick to beat teams up
So velocity is not a defined part of Scrum – but it is a defacto part of Scrum implementations and it is both a arbitrary and crude measure of something.
Velocity doesn’t mean what you think it means. It is about capacity,not speed It is *always* historic and never comparable to any other team and barely comparable to the same team over time. Sure it is a number and numbers can be compared – and that in itself is a problem because the human factors that help that number pop out are deeply flawed in most organisations.
Thankfully, the #NoEstimates movement is bringing some well deserved improvement in thinking in this whole area.
Of course you need a measure to know how you’re doing. But velocity is a poor one. The emergent product and how well it is meeting the needs it was intended to meet is the ultimate measure – sadly many organisations are unable to get this – so they overdose on the measure that came with the process.
So narrow as to be quickly redundant
I was in the market for car seat a few years ago and was faced with buying something that was super specific for my son at his then age – he was 3 years old – or buying something that would support him till he was 8 years old.
Guess which I bought.
Scrum purports to be for ‘new product’ development – and I wholeheartedly agree. Except I don’t know *any* teams that only do ‘new product development’.
Even if a team that started out with only new product development – after their product reached its first users – their work mix would need to change. The fixes, bugs and so on that are different classes of work and different service responses change the mix. You could use Scrum to do these classes of work – but that would be akin to picking your teeth with a vacuum cleaner.
And this is just product related work – but what about the work everyone needs to do to continue to improve? The Human Development work? How about using Scrum for that?
If Scrum was the only thing you did – and many organisations adopt it as such – then it would get misused pretty quickly because getting shit done always trumps following a process. The question is how much of a hatchet job do we have to do to the process to get the shit done.
Scrum Shows You What Needs Fixing, It Doesn’t Fix Them For You
If I had a penny for every time I’ve heard this, I would be rather rich.
Of course Scrum should fix something – everyone I have ever met in a company *know* what is wrong. They don’t need a fancy methodology to tell them what is broken. They need something to help to try and address the problems and Scrum does not not address any of those.
If the problem that Scrum fixes is exposure of problems then it needs to be pitched as ‘a framework for exposing what is preventing you from doing joyful, fulfilling new product development work’.
It ain’t all bad.
I don’t hate Scrum – I’ve just use it long and deep enough to understand which bits I would throw away and which I would keep, what contexts I would use it in and which I would bury it so deep – no one would ever find it.
If you are using Scrum – I beg you to question it all. Ask yourself, your team, organisation and customers whether this is really helping you and what you are really trying to achieve. Don’t even mention Scrum during that conversation – simply talk about ‘how are we delivering what we seek to deliver” .
As with most things, all this can boil down to simple choices.
Do you choose to blindly follow a process or do you choose to adapt your own way of working that is focused on value and joy?
Good luck whichever you choose.
Photo by mikecogh 
