Continuing my mini-series on the Scrum Framework, I look at some of the common problems I see with its adoption. I discuss problems with transitioning the traditional Project Manager and Business Analysis role into Scrum, and dangers of using pick 'n' mix Scrum.
Or listen at:
Published: Wed, 24 Feb 2021 16:51:06 GMT
Links
Transcript
[00:00:35] Hello and welcome back to the Better ROI from Software Development podcast.
[00:00:40] In this episode, I want to continue talking about Scrum. In this episode I want to talk about common problems.
[00:00:48] In the last two episodes, I provide you a brief primer on Scrum - and the last episode I talked about the values and theories behind Scrums. Again, I'd certainly advise going to ScrumGuides.org to read the Scrum Guide in its entirety. It's about a 10 minute rate and certainly very well worth your time. I'll provide a link in the show notes.
[00:01:12] In this episode, I want to talk about some common problems.
[00:01:15] Scrum on the face of it can seem exceptionally simple. However, it can be very, very difficult to master. And you see time and time again, similar mistakes.
[00:01:29] I'm only going to touch on a few in this episode. I might come back to this in future episodes. But in this episode, I'm going to talk about transition roles where people in existing roles move into Scrum based roles and some of the problems I see with them, as well as how well your team decide to implement Scrum in their day to day activities.
[00:01:52] OK, I want to start with the Project Manager moving into a Scrum Master - this is quite common.
[00:01:59] You find that Project Managers, that have traditionally worked in a very traditional way, find that they get moved into Scrum Master roles when an organisation moves into Scrum.
[00:02:14] Now, this can be quite difficult for the Project Manager without training. A project manager, if they're not careful, can continue to retain the command and control style of management.
[00:02:26] They can continue to see themselves as being at the center.
[00:02:31] Many Project Managers I know feel that their role is to sit in the center of many, many moving parts and to coordinate them - almost using the individual people as resources, giving them just the bit they need to do, and then the project manager will consolidate that and coordinate those activities.
[00:02:52] In Scrum, that definitely isn't how it should work.
[00:02:57] It's almost a complete role reversal.
[00:03:00] In Scrum, the team should understand the problem - the team should understand all the moving parts - the team should understand how it all works.
[00:03:10] The focus should be very much on the team - and the team should have ownership of the work they're doing - and thus they need to understand all the moving parts of it.
[00:03:22] The Scrum Master is actually responsible for different things - they're not responsible for understanding all the moving parts. That's the team's job, if anything, that's complete different from what they were doing as a project manager.
[00:03:36] Their role is to help the Team with Scrum adoption. Their role is to help the team get better with their agile capabilities. Their role is improvements to the team in terms of how they work and how they get better.
[00:03:52] But as a coach, not as a player.
[00:03:55] They should be providing advice or leading the team into how to improve things along the way.
[00:04:06] And again, so much more of this is about coaching the team, helping them towards self realisation rather than telling them.
[00:04:16] If you contrast that with the traditional command and control style; you can see why Project Managers have recently moved into Scrum Master roles struggle because they're so used to telling the team what to do.
[00:04:30] And that isn't what the Scrum Master should be doing.
[00:04:33] The Scrum Master should be making the room available for the team to learn, providing them the framework and the help to get better at Scrum and to learn themselves.
[00:04:46] And this is for the benefit of the team. Not the Scrum Master.
[00:04:51] The Scrum Master, their role is actually, if done well, is to actually make themselves redundant.
[00:04:57] Their role is to make the team coherent enough and capable enough, they can continue on the journey without the need of the Scrum Master. That's almost the ultimate goal of the scrum master, as is any coach.
[00:05:11] If the students have got to a point where they are beyond the coach in terms of their ability to learn or are able to self-learn, then that's a job well done.
[00:05:23] So certainly we should always remember that the team are the ones that should have the domain knowledge, the team should know what is being worked on, the team should answer all the questions.
[00:05:35] At any point anyone wants to know what's going on, they should be asking the team.
[00:05:40] The scrum master is rightly in the correct place to turn around and say "I don't know, ask the team."
[00:05:49] Let's talk about the transition from Business Analyst to Product Owner. Again, this is quite a common transition.
[00:06:00] People think because they may have been a Business Analyst and maybe been a conduit to stakeholders, that it makes a natural progression into being a Product Owner.
[00:06:12] And in some ways, I've actually seen that work quite well. In terms of, if they understand the business domain well enough and they understand what's being asked in terms of the work going forward, they can work quite well.
[00:06:26] However, what they need to do is avoid remaining a conduit and just being a mouthpiece for external stakeholders.
[00:06:36] This is where the Product Owner needs to take responsibility and assume full responsibility. They need to have that full responsibility for the work of the Scrum Team.
[00:06:47] They should not be just delivering orders that are being passed down. Yes, they should be working with stakeholders. Yes, they should be working with customers. Yes, they should be working with users to define what valuable things could be considered next.
[00:07:02] But ultimately, that Product Owner needs to have the responsibility and authority to be able to make decisions as to what the team work on.
[00:07:14] And this is a fundamental. This has to be a level of authority - you can't have the rest of the organisation second guessing or undermining the Product Owner.
[00:07:28] Because how can the Product Owner ever be confident when they're sitting with the team and trying to establish the most valuable things for the organisation, if someone is going to go behind them and change those orders or be negative about them.
[00:07:46] Ok, let's talk a bit about where people start to pick and choose.
[00:07:52] The first one I want to talk about is a term called Scrum-Fall.
[00:07:58] If you're used to normal or traditional waterfall style project management, you generally work in defined silos, defined stages.
[00:08:07] You maybe start with a requirement stage where you get the requirements written up, they get a signed off, they get approved. That then goes to the developers. They may do additional documentation, but ultimately they develop the product that will then go to the testing team. Then once a testing team have completed their work, it would then go on to the release team.
[00:08:27] You have discrete events occurring.
[00:08:32] Scrum-Fall is where you use many of the artifacts, many of the events, many of the terminology with within scrum, but you're still effectively doing waterfall just in a much smaller scale.
[00:08:49] Say, for example, you've decided you're going to have your Sprint as a month long exercise; in the first week of that you may be doing requirement, in the second week you may be doing development, in the third week you might be doing testing, in the fourth week you might be then released - that's not Scrum.
[00:09:07] All that is doing is using terms and event from the Scrum Framework, but still operating in a very siloed mentality.
[00:09:15] And in doing so, what you will generally find is because the developers are only working on that second week, they end up in multiple scrum teams - so that you're effectively using that resource in different Sprints for different teams - you're using them as a basic resource.
[00:09:35] And this quickly moves away from the idea of gaining the efficiencies of the entire team being able to work on and produce the work. And I've seen people believe this gives them quicker iterations than working in the standard waterfall model, but it really doesn't give the value.
[00:09:55] And the same is true any time you pick and choose from Scrum as to which bits you want to do. You're generally diluting the value of Scrum if you decide to drop parts for them.
[00:10:11] Here, I want to talk about a martial arts term, Shu-Ha-Ri.
[00:10:16] It talks about when you're learning from a master - how you should implement it and how you should work going forwards.
[00:10:26] This is described by Martin Fowler a well-known agile expert as:
Shu – In this beginning stage the student follows the teachings of one master precisely. He concentrates on how to do the task, without worrying too much about the underlying theory. If there are multiple variations on how to do the task, he concentrates on just the one way his master teaches him.
Ha – At this point the student begins to branch out. With the basic practices working he now starts to learn the underlying principles and theory behind the technique. He also starts learning from other masters and integrates that learning into his practice.
Ri – Now the student isn’t learning from other people, but from his own practice. He creates his own approaches and adapts what he’s learned to his own particular circumstances.
[00:11:33] So we're talking about Shu, Ha and Ri.
[00:11:37] Shu, in this case, we should be following the Scrum Guide to the letter.
[00:11:41] Ha where you've learnt it well enough that you can adapt it and start making slight changes.
[00:11:46] And Ri where we really have embodied the understanding of what you're trying to do and you can branch out and make different decisions.
[00:11:56] Most teams should really be starting at Shu.
[00:12:00] However, I've seen so many teams starting to cut and slice and change and remove parts of the scrum framework moving into Ha, or even Ri, stage at day one.
[00:12:14] Maybe they decide something won't work here.
[00:12:18] Maybe one of the events seems extraneous.
[00:12:20] Maybe they don't feel they need to do the Sprint Retrospective because "they're professionals and they know what they're doing".
[00:12:29] But more often than not, by skipping that Shu stage, of really ingraining that ability, in effect becoming a black belt in Scrum before even thinking about changing it, they're missing the value in its ability to deal with impediment, its ability to investigate and resolve issues, its inability to improve the team and its ability to deliver value.
[00:12:58] I'm not going to tell you that Scrum is perfect.
[00:13:01] I have to admit, I personally favour a different approach. But I've been working and studying Scrum and Agile for over 10 years. I believe that I've reached that point where I've got Shu, and I've moved very much into Ha, maybe touching on Ri, in terms of that ability - based on my experiences of looking at how it works and the theory and the practise behind it, that I can safely adapt it.
[00:13:32] But that all being said, if I move into a brand new team tomorrow, almost certainly I will start them at the Shu stage.
[00:13:41] I will almost certainly start them at the Scrum Guide - by the letter of the guide starting point.
[00:13:49] Why? Because it allows the team to learn.
[00:13:52] Just because I may have a deeper understanding, just because I may have worked with Scrum and Agile for many, many years, it doesn't mean the team have.
[00:14:03] The team need to be able to understand and learn those values - so if they're new to agile, and possibly even new to real Scrum (as opposed to what they've been told is Scrum) - then I find real value in making sure that we go back to basics and we follow the process as defined.
[00:14:23] And I'd also comment, there are many, many teams out there following the letter of the law as far as a Scrum Guide goes and gaining great success. If it works for them, great, they may not feel the need to go beyond that.
[00:14:37] And many organisations probably don't need to.
[00:14:39] But certainly you should not be trying to adapt it before you've understood it, before you've got it down, before you've reached that blackbelt status.
[00:14:50] In this episode. I've talked about some of the common problems I've seen in the adoption of Scrum.
[00:14:56] I've talked about how Project Managers can struggle to transition into Scrum Masters.
[00:15:03] I've talked about how Business Analysts can struggle to transition into Product Owners.
[00:15:08] I've talked about Scrum-Fall where the terminology and the events and the artifacts from Scrum are being used, but basically in the same traditional waterfall way.
[00:15:20] And I've talked about avoiding picking and choosing from the Scrum Guide - I've talked about using, as it stands, until you've learnt that ability to get to that blackbelt status where you can then start looking to adapt it.
[00:15:34] In the next episode, I want to touch on the Definition of Done.
[00:15:38] The Definition of Done is part of the iteration, and I think it's a really good thing to focus on as part of understanding how teams work and what a team produces. So I'll speak to you about that in the next episode.
[00:15:55] Thank you for listening. I look forward to speaking to you again next week.