Completing my mini-series on the Scrum Framework, I wanted to talk about the dangers of misunderstanding Scrum. Scrum is deceptively simple to understand - but difficult to implement. It can be too easy to misunderstand or mis-implement Scrum; only to be left wondering why it is so recommended.
Or listen at:
Published: Thu, 08 Apr 2021 08:38:10 GMT
Links
Transcript
Hello, and welcome back to The Better ROI from Software Development podcast.
In this episode, I'm going to complete my mini-series on Scrum.
In Episode 73, I provided a primer to Scrum. In episode 74, I talked about the theories and values behind Scrum. In 75, I talked about some common problems. Episode 76, The Definition of dumb. Episode 77, I talked about conflict - and how it can be good for the team in that how Scrum makes it safe. Episode 78, I talked about warning flags when the team, or more importantly, an individual will come asking for more work. In 79, I talked about how Scrum will highlight problems - and that's a good thing, and the organisation as a whole needs to be ready to respond. And in the last episode, Episode 80, I talked about stopping the sprint - why it's sometimes necessary and some of the warning flags that sometimes we just need to keep an eye out from.
In this episode, I want to talk about the dangers of misunderstanding Scrum and the process around it.
If you read the Scrum guide, it can seem an exceptionally simple framework - and indeed it is very easy to understand and read.
Implementing it, however, and successfully using it can be quite complex. And this, unfortunately, does lead to people misunderstanding how to use it.
And by misunderstanding it, misunderstanding of the terms of the processes or even just the aims of scrum, we find that it loses a lot of the value. We find that it is not as effective, as efficient, as capable as it should be.
And because of this, individuals, teams, organisations become disenfranchised with Scrum.
They might initially like the idea of it, but they find that it's failing them. They find that it's not working for them.
And in all honesty, this isn't necessarily the fault of Scrum - this is where we've misunderstood how to implement it and how to use it.
This isn't just a problem with Scrum, it happens in Agile, it happens in Lean, it's happened in Prince, it's happened in ITIL - people take part of a process, a wider philosophy, and they pick and choose which bits they want to do and sometimes plainly, incorrectly.
By doing this, they dilute the original meaning, the original intent of the framework.
It's very common to see partial adoption of Scrum.
Certainly, I've talked to organisations that are doing a daily stand up, or a daily Scrum, where the team gather for 15 minutes at the beginning of the day to talk about what's happening through the rest of the day.
That isn't Scrum.
That's one event from Scrum.
Just doing that does not make you Agile, does not make you Scrum based.
Again, refusing to have a process around how you do software development, that is not Agile. And yet I've seen so many companies say we're Agile purely because they're not using a recognised waterfall method.
People are using the terms incorrectly. Now unfortunately that's from a lack of education and unfortunately believing, possibly quite innocently, that they're exhibiting the characteristics that that framework exemplifies.
And unfortunately, because there is that misunderstanding of what these terms, activities, how they interact together - you get the danger of individuals, teams, organisations believing they're doing Scrum or Agile or Lean when in fact, they're really not.
And this has some really bad outcomes.
There's general uneasiness about whatever process in place, it doesn't gel, it doesn't work, and it struggles to bring everyone along with it.
Developers don't like it because they're not seeing why they're doing it, they're doing a bit of a process, but it doesn't fit together. It doesn't help them.
The business doesn't get the benefit that people tell them they should be getting from using Agile or Scrum or Lean. As such, Agile, Scrum, Lean, they get a bad name, they get a bad reputation, there's a level of distrust that grows around them, not because they themselves are wrong, but because of people's understanding is wrong and implementation of them have been wrong.
And one of the biggest outcomes I worry about is the recruitment and the retention of good quality staff.
You might recruit a really good set of developers in, based on you being a Agile shop,that you're using Scrum.
This might be what's in the advert. This might be what's in the interview. But when they walk in the door and realise, actually, no your not - you're not applying the true principles of Scrum - or indeed, you're not even really applying agile.
You've suddenly got a team that you've spent a lot of money and effort to bring in the door that are quite concerned that they've been sold one vision, but in reality, it's something else.
And the same is true of retention.
If the team are getting the blame because Scrum, Agile or Lean, are not producing the results that the organisation has been promised, they're getting the blame because it hasn't been implemented correctly or they're getting the blame because it hasn't been understood correctly.
Oddly enough, they're not going to feel very fond of staying in that environment where they're being blamed for something that isn't strictly their fault.
Let's be a little bit realistic about Scrum and indeed Agile and Lean - none of them are perfect.
None of them guarantee great outcomes.
It is, however widely accepted, they are much more likely to produce better outcomes than the traditional Waterfall style project.
If you look at Scrum and how it is built, it's got a lot of transparency, a lot of feedback cycles so that we identify quickly whether there's a problem.
That is inherently one of the biggest problems you have with a traditional waterfall style project. You could be 6, 12, 24 months down the line to find that this project you've invested millions in - actually doesn't really achieve what you're after.
Whereas Scrum or Agile, get that feedback quicker. Allows you to course correct quicker. Allows you to be agile.
But they're still not 100 percent perfect. They're still not going to guarantee great outcomes, they're only going to make it more likely.
And of course, you've got to think about making sure that you're using all of those Scrum artefacts, all those events, all those activities to make sure that you are getting the best from it.
So are you doing your Daily Scrum?
Are you doing the Review?
Are you doing the Retrospective?
Are the job roles understood correctly?
All the artefacts understood correctly.
In that retrospective, are you reviewing whether or not everybody understands it correctly and it's being used correctly?
Going back to episode 75 - are you using the Shu Ha Ri technique - with Shu you should be following from a single master by rote - you should be following from the scrum guide by rote until you've started to internalise it and understand it. Are you doing that? Is your organisation following the Scrum Guide to the letter?
Scrum is easy to understand, but it can be challenging to implement. It can take a considerable amount of effort. It can take years.
Don't assume that just simply by emailing around the Scrum Guide that it's going to be set up within a week. To get it properly instigated and working well can take a lot of effort and time.
Not only are you following that process, but because of the impediments and the problems that the process might highlight, you may need to make changes to your culture. You may need to make changes to your hierarchy, your reporting lines, your reporting structures.
Now, that should be for the better if it's been highlighted as an impediment or an issue or a problem. Ultimately, your organisation will be the stronger for it, but it will take time.
And to assist you in this, I really recommend considering bringing in a Scrum Coach.
A coach dedicated to helping the team and the organisation - we mustn't forget the organisation and the executive leadership in understanding scrum, understanding the basics and getting embedded and rolling.
Once it's in, I think it takes on a life of its own. And once it is understood and accepted, it builds its own momentum through that regular repetitive review cycle that you're getting as part of the baked in Scrum Retrospective.
But having that help, definitely at the start, may be a regular review point, of having somebody that's worked with Scrum or worked with Agile over the years and has that experience level that they can bring to bear and answer some of those questions, help to highlight problems, help to highlight things that otherwise you just may not see.
I'd certainly recommend thinking about it.
In this episode, I've talked about where misunderstandings can come in understanding Scrum and the dangers that come from that.
As discussed in Episode 75, in the Common Problems episode, it's very tempting to skip bits to adjust to local preferences.
But this is not scrum.
From the scrum guide itself:
"While implementing only parts of Scrum is possible, the result is not Scrum"
The dangers of doing it is you don't get the benefit. You don't get the results you're expecting.
You get a disenchanted workforce, recruitment and retention becomes a problem.
The general negativity about how your software is being done and very quickly, a return to the old ways.
We should remember that scrum does take time. It's an investment of time and effort. It's not simple. Adoption will take time.
Maybe invest in a coach, but definitely make sure you're making periodic reviews to see how close you are to the intention of the Scrum Guide - as well as understanding, does it fit with the Agile approach in general?
Thank you for taking the time to listen to this episode. I look forward to speaking to you again next week.