In this episode I introduce Scrum - an Agile Framework popular within Software Development. This episode serves as a primer for future episodes - in which I will dig deeper.
Or listen at:
Published: Wed, 10 Feb 2021 16:52:46 GMT
Links
Transcript
[00:00:35] Hello and welcome back to the Better ROI from Software Development podcast.
[00:00:42] In this episode, I want to talk about Scrum.
[00:00:45] Scrum is an Agile framework originally developed to facilitate the building of software in an agile way. It has now moved out of software and being used in many other situations.
[00:01:00] In this episode, I'm going to provide a primer on what Scrum is.
[00:01:06] In future episodes I'll dig in further to.
[00:01:09] Even if you think you understand Scrum, I'd advise you to list this episode just in case you've come from a background which isn't implemented in the way described by the guides.
[00:01:20] In these episodes, we use the definition of Scrum found at ScrumGuides.org - I'll provide a link in the show notes to the guide. It's a free resource and takes about 10 minutes to read. I'll probably quote various sections during this episode and future episodes to provide you some basis of how Scrum works.
[00:01:41] The Scrum guide is very well written. I certainly will be using some of it during these podcasts as it provides probably the best description possible.
[00:01:52] That being said, The Scrum guide describes Scrum as:.
"Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems."
[00:02:12] And it does this by defining Scrum Teams, Scrum Events and Scrum Artifacts.
[00:02:19] Let's start with a Scrum Team.
[00:02:22] The guide defines a Scrum Team as:.
"Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how."
[00:02:45] The Scrum team is made up of Developers, a Product Owner and a Scrum Master.
[00:02:52] The Developer role is the name given to anybody that provides skills or labour into producing the work. They aren't necessarily software developers.
[00:03:04] So if in the development of a software product, it probably will actually include software developers, testers, potentially infrastructure staff, and anybody that is spending time, effort or skills to produce the work.
[00:03:20] This allows us to think of us as a team of people working to a common goal well - working together, using our diverse skills to produce a valuable product rather than us all coming together and being individuals with silo-ed skills and handing things off between different technical capabilities.
[00:03:42] We're not a group of individuals. We're a team working together.
[00:03:48] The Product Owner, of which there is only one, is there to ensure that the Scrum Team is maximising value for the organisation. They are the single voice in defining what the Scrum Team is going to work on. They define what is important and what the Scrum Team should be doing next.
[00:04:07] They are the only person that should be defining what the team is working on.
[00:04:14] The Scrum Master is there to establish the rules of Scrum. They're there to help the team work within the Scrum framework.
[00:04:25] Their role is one of coaching. They're there to help the team become effective in using Scrum and agile techniques in the day to day effort to become better at what they do.
[00:04:39] Let's talk about Scrum Events.
[00:04:42] Scrum Events all share one characteristic - the are time boxed. They have a specific length of time that they can run to, and that depends on how your organisation wants to work - but I'll some examples as we go through.
[00:04:56] The largest of these is the Sprint, this is the time box in which all the work is done and everything else fits within it.
[00:05:05] While the timebox can be quite short, and I've heard it being as short as one day, commonly you'll find it being about two weeks. Thus all the work, all the other events occur within a two week Sprint.
[00:05:18] And that then repeats, so the work that the Scrum Team do is done on those two week increments.
[00:05:28] Within that Sprint, you will start with Sprint Planning. This is the work, with the team as a whole, agreeing what they expect to get done within that Sprint period.
[00:05:37] So if it's two weeks, what they expect to produce within that two weeks.
[00:05:42] This is led by the Product Owner talking about what they believe will produce the most value and then working with the Team based on their capabilities, based on their experience, based on what capabilities at any given moment in time, to define what is going to be the best things to aim to do within that two week period.
[00:06:01] The Team then aim to make a commitment to produce that work within that Sprint.
[00:06:08] The next event, the Daily Scrum, is a daily activity. Sometimes called the Stand Up. Time boxed generally to about 15 minutes - where the team will come together and do daily planning based on what they've committed to during the Sprint.
[00:06:25] This generally happens at the same time, at the same place, with all the members present - so they're in a position to sync what they're doing, how far they've got, what problems they see.
[00:06:36] This allows them to look at the work they're trying to do and understand if there are any problems with being able to meet that commitment on any of the committed tasks within that two week sprint.
[00:06:51] At the end of the Sprint, there is a Sprint Review. This is an opportunity for the team to demo the work they've done.
[00:06:58] Now the are demoing it to the Product Owner, but also any other stakeholder that is pertinent to the product. Maybe you have a group of customers you're able to use as a focus group, maybe its users within the business, and they can sit and look at it and they can play it. They can see the software we're talking about here, being able to demo and try work that has been built and done.
[00:07:23] We're not talking about looking at plans. We're not looking at talking about PowerPoint presentations. We're not looking at what could be. We're actually looking at what has been built in the last two weeks.
[00:07:35] From this, we're trying to elicit feedback.
[00:07:38] So for the people that it really matters to the users, the customers, have the team got the right idea? Did they get it correct?
[00:07:47] This allows us to double down on what we're doing if we're doing the right thing or make a course correction if it was the wrong thing.
[00:07:55] And it allows for rapid adoption. Referred to as Agile.
[00:08:03] The last event is a Sprint Retrospective.
[00:08:06] This is where the team come together to review how well they've done in the Sprint. This is about them as a team and their effectiveness at doing their role.
[00:08:17] This is not about the actual work they did, but how they actually work together as a team to get better at producing work.
[00:08:25] Think about this as making sure that the machine is well oiled and capable so that it can get better and better over time and be able to churn through quality work better and better as it improves.
[00:08:41] This will be a great opportunity for the likes of the Scrum Master to coach the team on better practises, how to improve engagement and make sure that they are improving over time.
[00:08:54] The Sprint will then end. And a new sprint will begin - and we start the process again. Going into Sprint Planning, where not only will the Product Owner bring forward the next pieces of work which are believed to produce the most value - the team can also take into account any feedback they received from the Sprint Review and the Sprint Retrospective.
[00:09:18] They will then continue to do the Daily Scrum every day to plan through. Moving towards the end and do a Sprint Review, and another Sprint Retrospective - again, taking any feedback from either the Sprint Review or the Sprint Retrospective into the next Sprint.
[00:09:35] Constantly refining both their processes and making sure they're better at what they do, as well as making sure the product they're developing is heading the right direction and is what is needed by the customer, the user.
[00:09:51] And then we have the Scrum Artifacts. We have the Product Backlog, we have the Sprint Backlog and we have the Increment.
[00:10:00] The Product Backlog is an ordered list of possible improvements. This is all the things that the Product Owner feels the team could add to whatever software they're developing.
[00:10:12] It could very well be a list including the kitchen sink. The importance here is that it's an ordered list of possible improvements.
[00:10:22] This list is taken into the Spring Planning. And this is where the Product Owner will sit with the team and take the most important things off that list, work with the team as to what's practical and possible within the sprint and agree on the work that's going to be done.
[00:10:40] The work that's going to be done is then fed into the Sprint Backlog, which I'll come back to in a second.
[00:10:47] The Product Backlog is there to be added to at any time. So anyone, at any time, whoever they are in the organisation, can come to the Product Owner and make suggestions for adding into the Product Backlog.
[00:11:00] Ultimately, the Product Backlog is owned by the Product Owner, as is the ordering of that list - but anything that anyone comes up with can be added to that list for consideration.
[00:11:15] So let's move on to the Sprint Backlog.
[00:11:17] So this was created during the Sprint Planning.
[00:11:19] So it's those items have been taken from the Product Backlog and agreed by the team and the Product Owner to be the work that's being done during this Sprint.
[00:11:31] And that Sprint Backlog is used by the team during the sprint. Say, for example the two weeks if it's a two week sprint, to define the work they need to do.
[00:11:40] And it's constantly reviewed using the Daily Scrum as well as any other efforts that the team what to do to make sure they're keeping track of what's being done.
[00:11:49] The Daily Scrum is a catch up point to make sure they're on track. They know what needs to be done - they understand what's in the Sprint Backlog still to do, and they have a plan to do it.
[00:12:02] And we have the Increment.
[00:12:04] The Increment is any completed work in that Sprint. This is the work that's been produced from the list of work from that Sprint Backlog - which originally came from the Product Backlog.
[00:12:16] The Increment is what is reviewed in the Sprint Review.
[00:12:22] The Increment is working code. As I talked about in the Sprint Review, what we're looking at is being able to demo that code - to use it as a customer or as a user.
[00:12:34] We're not talking about PowerPoint presentations here.
[00:12:36] We're not talking about plans.
[00:12:37] We're not talking about what could be.
[00:12:40] We're talking about what is.
[00:12:43] This is fundamentally so much more powerful than potentially producing something - we've produced something, we can use it, we can try it. And of course, using it during the Sprint Review, during a demo, means we can get feedback quickly and can make those adaptions.
[00:13:01] In this episode, I've given you a brief overview of Scrum. I'm using it as a primer for future episodes.
[00:13:10] I've given you a brief description of what Scrum is - I'm giving you a quick description of what it is and how it provides value.
[00:13:20] I define the Scrum Team as being made up of Developers, a Product Owner and a Scrum Master.
[00:13:27] I've talked about the Scrum Events in terms of the Sprint, the Sprint Planning, Daily Scrum, Sprint Review and Sprint retrospective.
[00:13:37] And I've talked about the Scrum Artifacts - the Product Backlog, the Sprint Backlog and the Increment.
[00:13:46] In upcoming episodes, I'll be looking about talking about the theory and values behind Scrum. I'll also talk about some of the common problems. And I'll be talking about the Definition of Done.
[00:14:00] Thank you for listening and I look forward to speaking to you again next week.