Business
Hello and welcome to the bottom-up skills podcast I'm Mike Parsons the CEO of Qualitance. And today we are going to talk about agile. And scrum that's right. This is the sixth part, the sixth instalment of my favorite tools for making better products. And today. The specific tool we're going to get into is this sprint plan.And this is at the cornerstone of doing agile, scrum work, working in an agile way. And the sprint plan is like the go-to place. If you want to work in an agile way, it really starts with a sprint plan. And I'm going to explain what this is. It's a fundamental tool for you to work in a really. New way it's pretty simple and straightforward and what I would propose to you, it's how [00:01:00] we can you know, get our agile projects being closer to deadline.It's how we can be on time. But more importantly, my experience has been that I made a lot of executives who understand agile at a very kind of top level. Maybe just some of the principles and so forth. However, what is fascinating to me is how once you get into all right, well, let's do agile. There's a number of things that I see.Real confusion around or people just haven't had the chance to really dig in. I can tell you I've been digging in to working in an agile way for, for quite a quite a while. And the spring plan is something that I'm really delighted to share with you today. So we're going to get right into it. Now I'm going to do a little bit of laying down some foundation here.I'll do it super quick. And then we're gonna get [00:02:00] to this sprint plan. First of all, we need to get this underlying idea of agile re super-clear agile itself. Agile software development itself is a set of principles. All guided to helping a product team be incredibly productive and work fast. I often say it's the nimble and much more iterative alternative to working in the traditional waterfall way, which was how we worked in software maybe 20 years ago.Now the problem with that. Is that it's new? The problem with agile is there's lots of different flavors. So that's why I want to kind of cut to the core of it. Get to the sprint plan, get to defining some of the flavors of agile. Now this is an, a really important build. So agile is a set of principles.There is then a lot of different methodologies [00:03:00] and practices that come out of those principles. So the power. Of agile is that I think why it will be around for so long. Is there, there are these fundamental, almost like first principal kind of notions that support this idea of agile and. Then you get, you know, it's commonly considered there's about 40 different versions of agile.And probably now that I've said this 40 there's probably 41 or 42. So there's a set of values and principles that underline agile. It's all about Focusing on bringing people together and the quality of the individuals interacting. It really prioritizes work our working product overall, the comprehensive documentation.Whereas, you know, waterfall was all about a very strict process well-documented but often the product [00:04:00] sucked, the software didn't work well. So that's why agile came about. So those are some of the values of the principles. You know, There's a lot of them. I would say it's, there's a lot of thinking around sustainability empowerment of small teams taking big challenges, putting them into a small component parts that there's a lot there, a lot of good stuff that kind of sets you up for the different flavors.That I was talking about. So you've got many different flavors you could argue. Lean startup is a flavor of agile then. There's a lot of the Japanese inspired flavors continuous just in time delivery, that kind of thing, Macado method, or you could string right across to like decentralized management and governance.You've got like Holacracy. You might've heard of that beyond budgeting begin with the end in mind, some of those [00:05:00] practices, but the one I'm going to focus on is scrum. Scrum is by far the biggest and most popular version method of agile software development. You've seen companies like Atlassian who produced JIRA and confluence, you know?Right. They're like it's a big nod towards the world of agile. Okay. So we've established number one, agile methodology is, you know, agile at its highest form it's principles and values. There's many different flavors that bring it to life. That's the stuff we do. And in terms of doing stuff, we're going to talk about a flavor of agile called scrum.Scrum is very different to canvas. In one essential way. So Kanban's also a very, very popular way of doing agile. The difference with scrum is it's time-bound so it really respects timelines. [00:06:00] This in some respects creates a tension, but I think it deals with that tension quite well. So I'm going to explain what your sprint plan should look like.Some of the key parts of it. We're gonna describe some of the pieces. Some of the, the key tools and practices and hope fully, what I can do for those of you who are a bit newer to agile, I can introduce you into the practical, real, tangible things that you'll actually do do with agile and scrum. And for those of you who are trained, tried and true, hopefully I'm giving you a little reminder, a little update just to get you back into some of those foundational lines.Okay. Sprint plan for agile scrum way of working. Now, the first construct is the sprint itself. Traditionally, I'm a big fan of two weeks sprints. So [00:07:00] in cross those two weeks, you will plan do and review the work. And then you'll start a new sprint after that I've traditionally found that most good first-generation products are a good six to 10 sprints.And the big part of that to recognize is that it takes a team some time to. Storm and norm and come together and get productive. So I, you know, big Baton I see at work is that the second half of of a project. So if it was five sprints to start and five additional ones to getting us to 10, the second five are way more productive than the first five. So if you understand that that's natural, then you can be a bit more patient at the beginning. As people kind of come together and take ownership for, for their, for their work. Okay. So the sprint it's traditionally, it's two weeks. Some people do for I [00:08:00] love a good two weeks sprint. You're going to expect five to 10 of these particularly for a first-generation project or product.And there's nothing to say that you couldn't stay keep working in sprints after your product goes live. In fact, I'd highly recommended. We do it at quality once all the time. And I find this idea of, to experience is just a really good way. Not only to organize your product, but it's a pretty damn good way to organize.An organization. So more and more, I find myself trying to design more parts of our organization to get like our 250 people working on a, on a structured sprint basis, whether they're building product or whether they're in. Strategy where they're in the finance support, HR. It doesn't really matter if we can kind of create that rhythm.I think it's kind of a nice integrated way of working and it feels very responsive to the changing demands of business. [00:09:00] Okay. So what's inside of your, your two week sprint plan. Well, the first thing is you need to nominate a product owner, a team, and a scrum master. These are three key roles, scrum master.All about you know, helping people deliver their work in the sprint. I mean, it's, it's the ultimate constantly area support a helper, unblock her, if you will, for the team, there's the team itself, designers, developers, strategists, BAS all that kind of good stuff, building products. And then you have that key role of product owner.Product owner number one, most important thing, because if you don't have someone totally dedicated to owning the product, the quality of the works, aren't going to be good. So where do we see the work? Well the work is. In a sprint backlog that is a set of tasks and activities that you've all agreed to do over the course of the two weeks.You will. Then now we're starting to get into some of the things [00:10:00] some of the events that you have, you have a sprint planning meeting you will have at the end, a sprint review meeting, or what is often called a retrospective. And every single day you'll have a stand-up or a scrum. All of this takes context.This sprint is everyone is working towards ticking off things in the back. That's for the spring bat log, but there is another meta version of this backlog, which is the full product backlog. And that starts to become a bit more like a roadmap as to what might come in the future. But the good news is at the end of every sprint, you decide what's next as a team and as a group and every think is captured. Single source of truth. And you generally like to have at least one, if not two of those one manages the backlog that's JIRA. Secondly, the other one conference that is actually managing the documentation, the knowledge, all of that collaboration to decide what's in a user story, [00:11:00] what's in an epic, a theme.What is actually. The knowledge that informs the definition of the user story is all in confluence. Now, if you have these two really centralized JIRA, what are we doing? Confluence, how are we doing it? What's the background? What's the content. What's the feature list? What is the content list? What are the assumptions as the user logged in, logged out, et cetera, et cetera, all those sorts of things, all of that becomes embodied together.The tasks and the knowledge or the tasks and the data jobs to be done. And the data, all of that is centralized. So in the sprint and the daily scrum you'll be talking about, are you on track and know, are there any blockers for your backlog, for your tasks and you might discuss the search for more information in a tool like confluence, of course, at the [00:12:00] end you deliver your finished work.And everybody comes together to review and decide what's next. And this is the rhythm that you get into. This is the sprint plan. So two weeks. Some key roles, such as product owner, you make sure you have a black cloud. You make sure that at the beginning of the entire sprint, you meet and at the end to review and throughout the day, the thing that keeps you on track is your daily scrum.And all of this is captured and managed through tools like JIRA and confluence, plenty of other options as well. That's just a best practice advice from my side. So there you have it. This is the very heart of agile scrum. It's the split. Plan. And if you, if you adopt these sprint plans, if you define these key roles, you will have to unlock the para of agile, agile.Is a great way to work [00:13:00] together when you're building software, but only works. If everybody gets on board, if only works, if everybody lets go of waterfall, you can't be half in the game. You're either in or you're out and you have to trust the process. And that's why the sprint plan is so essential. If you're gonna trust the process, you need to know what is building up. Where are the lines where the goalposts, what game you playing? It's all in that sprint plan. I hope that's helped you if you want to go deep, but we have a whole masterclass on that job. You can get that@up.io. In fact, you can get over 20 different courses, all free at bottom-up dot PIO. I hope you've enjoyed it.This is the bottom of skills podcast. That's a wrap.