Following on from last week's primer of the Scrum, I take a look at some of the theories and values behind the Agile Framework.
Or listen at:
Published: Thu, 18 Feb 2021 08:25:44 GMT
Links
Transcript
[00:00:35] Hello and welcome back to The Better ROI from Software Development podcast.
[00:00:41] In this episode, I want to continue talking about the Agile Framework Scrum.
[00:00:47] In the last episode, I provided you a primer on Scrum. This was taken from ScrumGuides.org - I 'll include a link. And I certainly recommend you take 10 15 minute to read the Scrum guide in its entirety.
[00:01:03] In the primer, I talked about the Scrum Team, Scrum Event, and Scrum Artifact.
[00:01:10] Within the Scrum Team; I talked about the Developer role, I talked about the Product Owner role, and I talked about the Scrum Master role.
[00:01:19] For the Sprint Events; I talked about the Sprint, the Sprint planning, the daily planning the Sprint Review, and the Sprint retrospective.
[00:01:30] And for the Scrum Artifacts that I talked about; the Product Backlog, the Sprint Backlog and the Increment.
[00:01:42] In this episode, I want to talk about some of the theories and values behind Scrum and why it's the way it is and why it works.
[00:01:52] Let's start with the team made up of Developers, plus one Product Owner, plus one Scrum Master.
[00:02:01] They should be capable as possible at defining the upcoming work and getting it done. Any time, any work or approval needs to go outside that group of people, that Scrum Team, then there needs to be work to change that.
[00:02:19] This is a role for the scrum master to help the team address that impediment.
[00:02:24] I should probably make it clear at this point, it is not the Scrum Master's job to fix the impediment - it's the Scrum Master's job to help the team to fix the impediment.
[00:02:34] Ultimately, any time that the team has to rely on someone outside of their team - as I say, for work or for approval - that should be seen as an impediment to slowing them down and making them less efficient and effective.
[00:02:53] To repeat, any time any activity goes outside of that team, that is a cause of waste. And waste makes the team less effective. You see this also in Lean as well.
[00:03:07] Let's talk about the Product Owner.
[00:03:09] The Product Owner is one voice, and this makes a really important difference to many development teams. Many development teams are having to juggle work between multiple bosses, multiple masters, asking them to do various competing often activities.
[00:03:30] This makes it very difficult for a team to be effective and efficient - they're constantly having to contact switch between different tasks for different people, normally with different problems, different contacts and potentially entirely conflicting outcomes.
[00:03:51] The Product Owner is there to make sure that the team is focussed rather than fragmented by avoiding that ineffective multitasking. The Product Owner is keeping the team on a central goal.
[00:04:07] Within the sprint, the product owner and the team may agree to do a number of tasks - but generally, it's around a common goal.
[00:04:16] So rather than it being multiple different systems they might be working on, it's normally got a lot of crossover. There's a lot of efficiency gained because it's similar work. The team isn't having to lose time and effort, having to mentally understand one problem then only to shift moving to an entirely different domain, entirely different context.
[00:04:42] By trying to work with the Product Owner to build a cohesive set of tasks to be done within the Sprint, around a common goal, that makes it so much more efficient, much more effective, and bringing it back to that point where the Product Owners jobs is to make sure the team is delivering the best value they can for the organisation.
[00:05:05] Working in small Sprints allows for adaptability.
[00:05:10] If you're used to long running project, you're probably used to the idea that you may have many, many months just to get the project started, you may spend many months doing requirements and getting sign of approvals. And then once work's underway, if you need to change something, you have to go for a formal change request process where the team need to review what you want to change and effectively accept into the project. That's because there's been so much work done to get to that point, so much investment and time and effort.
[00:05:44] Scrum works in small Sprint - say, for example two weeks.
[00:05:49] By being that short you can replan easily, you can adapt easily. If the organisation needs to make a course correction, needs to change its direction rapidly - the worst you've got is in two weeks time it goes into the next Sprint Planning.
[00:06:08] You look at it and you say; "yes, OK, we were going to head that direction, but we're now going to adjust the thing we're going to take into our next Sprint".
[00:06:15] It's got that natural ability to adapt by effectively just becoming that next planning cycle.
[00:06:23] And again, how important it is to your business on how adaptable you need to be, you can adjust the Sprint to reflect - I've known businesses to run as short as a single day Sprint before to allow them that high level of flexibility to change tack.
[00:06:41] I would, however, say that while this does provide the ability to be that agile and adaptive; it is, however, up to the Product Owner whether they want to use it.
[00:06:56] Course correction is good, being able to adjust to what the organisation needs is good.
[00:07:04] Flip flopping between entirely different directions on a regular basis, effectively doing doughnuts in the car park is bad.
[00:07:13] The Product Owner needs to try and keep a level of coherent thinking in the direction of the work they're doing. And obviously, that involves engaging the rest of the organisation to make sure that it's running.
[00:07:24] OK, you might need to take a detour. That's fine. That's what Scrum allows. That's what Agile Frameworks allow allows for - that adaptability. But what you shouldn't be doing is going round and round in circles. You should still have a view to where you want to get as an organisation. Just because you have their power and the ability to course correct regularly doesn't mean you should make massive great u-turns all the time.
[00:07:53] Inspection. Scrum provides a number of points within the Scrum Events for Inspection.
[00:08:02] Again, if you've worked on traditional projects, you may be used to sending a team away with a pile of requirement documents and maybe not seeing that software for months, maybe half a year, maybe even a year. I've seen projects be taken away and brought back to the original stakeholders two years later. If they've gone the wrong direction. You've wasted two years worth of work.
[00:08:30] Within the Scrum Framework, you have inspection points built in.
[00:08:35] So as a team, you have the Daily Planning. The team can see where they've got to, they can see if they're adrift. They can see if there's a problem brewing.
[00:08:45] Say, for example, they realise they need some input from maybe compliance or legal team that needs to go to a third party; By having that planning on a daily basis, they can flag that immediately and, as a team, they can work to resolve that normally and in concert with the scrum master to remove that impediment, and get the work done.
[00:09:10] And as a stakeholder, you have the Sprint Review. This is a demo where the team should be shown working software. They shouldn't be showing you plans for working software, they shouldn't be showing you documents. They shouldn't be talking about timelines for when this will be ready.
[00:09:27] They should show you what they have done.
[00:09:30] This is inherently much more valuable than future plan - being able to show concretely what has been created, allows for course corrections, allows for review, allows people to raise concerns or actually approve that the work is heading in the right direction.
[00:09:49] If it's going in the right direction, great, Let's double down on it. Let's do more of it.
[00:09:53] If it's going in the wrong direction, let's course correct.
[00:09:58] By having these inspection points, it encourages the courage to raise issues. The team workers as peers, they should be in a position where they feel that something's going wrong - even during the Daily Planning or even at the Sprint Review - they've got the encouraged to raise their hand, to raise any problems.
[00:10:22] The same is true using the Sprint Retrospective; they've got the ability to bring issues to the fore, things that they believe which would make them as a team better at what they do.
[00:10:35] The inspection also encourages the respect to accept those changes and the focus to then address them.
[00:10:45] Transparency.
[00:10:46] And I've touched on this a bit in the inspection; because we're seeing what is done rather than what we are doing, we have proven work. This is actual working software. That Sprint review should be about proven work, not about documents. That way, we can see exactly what the team has produced and we can be confident that the team are being honest.
[00:11:15] It's very difficult to pretend a system is doing something when you demo it. Whereas you can put on documents; "OK, yep, we finished this bit, we've done this bit ..."
[00:11:26] I've been in plenty of meetings where a team is reporting on a monthly basis on a long running project. Every month they're reporting; they're green, they're green, they're green - right up until the eleventh hour - at which point they have to confess something's wrong.
[00:11:41] They're so far behind.
[00:11:42] And this has happened time and time and time again, because what you're looking at in most cases, you're looking at the output of documents. You're not looking at the output as a working software.
[00:11:55] By having that transparency of being able to look at actual software and validating it, it keeps a team honest. It keeps the process honest, it makes sure that everybody is open and honest with each other every step along the way.
[00:12:15] And it's about team first.
[00:12:18] Scrum is about teamwork, it's about the team, and I've repeated this over and over again in these episodes. And I keep focussing back on team.
[00:12:29] It's not about individuals.
[00:12:32] If you're going to use Scrum and then assign each individual their own work, then to be honest, you're not really doing scrum. You're missing the point.
[00:12:42] It's about team accountability and team commitment. They work together to produce, through the Sprint Plan, the work that they are committed to deliver - the work they are going to try their best as a team to deliver.
[00:12:58] You shouldn't get to a situation when towards the end of the Sprint, most of the team are sitting around with a feet up where one person is working their socks off because their piece of work wasn't ready.
[00:13:09] No, this should be the team working together to make sure that that job gets done. They should be diving in and helping each other and working together to get the work done. It isn't about individual accountability.
[00:13:22] It's about the team taking ownership on working together. And that encourages a sense of shared responsibility as well as a sense of shared accountability.
[00:13:35] You get a level of peer pressure between the team to make sure that they are looking after each other, making sure they're supporting each other.
[00:13:42] And again, this comes up through things like the Daily Planning, where if someone is falling behind, it makes it a much more appropriate environment where they can raise a hand up: "I've got a problem".
[00:13:53] If they're working as a team, they all have a shared responsibility to solve that problem rather than if we're working as individuals leaving that individual to sort their own mess out - I've got my own work and I'm going to concentrate on that.
[00:14:06] And then through the Sprint Retrospective, we're actively encouraged to review how the team works - the team are asked themselves to effectively mark their own homework to review how they believe they performed.
[00:14:19] And this is with a view to them being honest to each other. They're sharing it with each other. This is about then getting better and then helping themselves improve.
[00:14:31] This isn't about top level management saying you need to work faster. This isn't about top level management saying "you were slacking", "you went home early", "you didn't do this".
[00:14:40] No, this is about the team working together to improve how they do things.
[00:14:46] Now, maybe they find that there's a personal differences between the team that need to be and then maybe they find they haven't got the best tools, maybe they find they're having to constantly reach outside the team to actually get work done.
[00:15:00] These are impediments. These are things that can be improved. And improved over time.
[00:15:06] And more importantly, you should expect that continual improvement.
[00:15:10] Some people put the Sprint Retrospective to one side saying "we're professionals, why do we need to sit together and think about what we're doing?"
[00:15:17] That's not the point. You should always be constantly looking to improve to improve the mastery of the team.
[00:15:25] Think about this, similar to a martial artist learning their martial art. They will continue to improve even though they may have reached blackbelt. That's the point where they then start learning afresh, they start pushing harder and they start learning more.
[00:15:42] And the same should be true of the team. They may reach a very good capability, but they should still be reviewing and looking at what they're doing. They should experiment with different ways of thinking, different ways of working.
[00:15:53] They may find that it helps them - brilliant - do more of that.
[00:15:57] They may find that it doesn't help them. They may find further impediment. Great. Let's stop doing that. Let's avoid those. Let's fix those.
[00:16:07] It comes back to that hypothesis based experimental thinking I've talked about before time and time again. The team come up with various ways they believe they could improve and they experiment with it in the next Sprint.
[00:16:21] They can then assess it in the Sprint retrospective. Did it work? Did it help? Did it hinder? And of course, they can take that learning forwards into the future Sprint.
[00:16:31] But again, it's about team first, it's about teamwork.
[00:16:37] In this episode, I've talked about some of the theories and values behind Scrum.
[00:16:42] I've talked about the work being inside the team and making sure that we don't need to reach outside it and to avoid impediments by having to use people for skills or approval outside of the team.
[00:16:57] I've talked about the Product Owner providing that single voice, making sure the team is consolidated and coherent in the work they are working towards.
[00:17:07] I've talked about the adaptability, respectability and transparency that the Scrum Framework provides, allowing you to adapt quickly, allowing you to see what's happening and to make sure the work is honest.
[00:17:21] And of course, I've talked about it being about the team and getting value from the team.
[00:17:26] And the team constantly improving, constantly getting better at its work as well as working together to get the job done.
[00:17:37] In the next episode, I want to touch on some common problems I see.
[00:17:43] Thank you for listening. And I look forward to speaking to you again next week.