How Simplyhealth Successfully Applied Professional Scrum with Kanban

In this episode of the Scrum.org Community Podcast, Dave West chats with Helen Swift from Simplyhealth, a health solutions provider about how they implemented using Professional Scrum with Kanban in their organization after the Professional Scrum with Kanban training course. They talk about the transition from waterfall to Agile, how Scrum and Kanban together help improve delivery, the benefits of limiting work in progress and more!

Transcript

Dave West  0:20  
Hello, and welcome to the Scrum.org community podcast. I'm your host, Dave West CEO here@scrum.org. Today's podcast, I'm really excited about it not just because of the topic, but also because we got a fellow Brit on the podcast. But we're talking to Helen Swift, from Simplyhealth, a UK based health solutions provider based in the United Kingdom, and she's going to be sharing with us her Scrum and Kanban journey. Welcome to the podcast, Helen. Hello, and welcome. Great to have you here from from sunny England. And before we start on the actual

content, let's talk a little bit about yourself. So please tell our listeners a little bit about yourself and where you're speaking to us from Helen. 

Helen Swift  1:09  
Hi, yeah, so I'm Helen Swift. And I'm speaking from the UK, as you mentioned, I'm in the lovely Andover in Hampshire.

And yeah, and it's a lovely sunny day at the moment, which is

Dave West  1:21  
fine. Though my experience since I moved to the United States in England has suddenly become a lot more sunny. And I don't know if they're linked, I hope hopefully, hopefully not, but, and over is a beautiful part of the world. Okay, all right. So let's jump straight in. So tell me a little bit about Simplyhealth's agile journey. And then we can start talking a bit more about Kanban.

Helen Swift  1:49  
Yeah, so initially, we used to work waterfall, so it was very traditional, very project led. I would say this was some time ago now probably a years ago. And that still continued to a certain extent, we slowly started to move into the world of agile and starting to appreciate the benefits of working agile. And very recently, we've become more product LED. So really focusing on the product and not just that whole typical, we're running a project, it's going to run for two years, three years, however it may be. And whether we're happy with the results at the end of that two or three years. I mean, it's hard to say, isn't it? Whereas the Agile way of working really focuses on the kind of the short bursts of work. So we get to a certain point, are we happy, be confident with what we've got what we've achieved? If we're not, then let's start again, let's tweak it maybe. And let's kind of move forward. So yeah, that's pretty much where our journey started in the how we've progressed. But I, I'm pleased to say that the Agile way of working has definitely supported us. It's helped to improve our way of working for sure.

Dave West  3:11  
And so you were predominantly using Scrum, you transition slowly from waterfall to sort of Scrum based approach. And those Scrum teams now increasingly are aligned to the products that Simplyhealth provides, right?

Helen Swift  3:28  
Yeah. So it's all about benefiting our customers and getting value from our projects. So that that's our goal.

Dave West  3:35  
Yeah. And so by aligning those teams with clear, good product goals connected to the customer, in those sorts of product areas, you can improve that improve that cycle. Okay, so you know, you're using Scrum, you're aligning your product teams, to what brought you to Kanban? What, what, what, what happened? What happened that, you know, sort of brought you to this different, complementary way that we would argue way of working? Yeah,

Helen Swift  4:07  
so, we were working both Kanban and Scrum dependent on the team. So we've got lots of teams, in our department, a lot of Scrum teams. But what we were finding is that specifically, we weren't able to complete in many cases, the tickets in our sprint. So we I'm sure this is quite common for for many different companies have experienced this weird plan all our work in we'd be running our sprints, and then we'd was find at the end of the sprint that we would had multiple tickets that would move into the next sprint. So I wanted to look for a way to put to reduce those amount of tickets that would move across. And what I found was the with the benefits of Kanban, where you've got the better visualization of the board, and the reduced work in pro grass is that the focus was more on the completion of the tickets, which was really what was missing when we were working sprint. So we would continue on with our work, the devs would bring I say, devs, it should be the development team members, because I'm including the testers with that as well. And they would bring tickets onto the board, they would come into in progress, they'd work on them, and they might be blocked. Or for some reason, they would bring in another ticket. So then you'd find that more and more tickets were piling up in progress. And that was what we found, we'd come to the end of the sprint, and we'd have so many tickets in progress, but fewer tickets actually completed. So looking at that, what what can we do, I can see the benefits of Kanban in other in other teams, as I mentioned, the visualization of the board, duction, and work in progress. But having the planning really helped us as well, having the sprint goal, so we were aligned in line into that product goal. So I was doing a bit of research come across scrum dot orcs PSK training, and I thought that sounds like it could work for us. And it progressed from there really

Dave West  6:19  
sounds awesome. It is interesting that, you know, in a sprint, it's so easy to get so focused on just doing the work pulling more stuff from the backlog etc. is, you know, even though you are effectively working towards a sprint goal, it's cool, you can become quite inefficient inside the sprint, and you know, pull up too much work, et cetera. And that sounds like something that happened to you or so you learned a little bit about Kanban started using it. What? How did it help Was it really that it reduced the work in progress, you reduce the amount of tickets or issues or whatever that were leaving the sprint as those sort of things, were they some of the benefits, Helen?

Helen Swift  7:10  
Yeah, so multiple benefits really, we started working from right to left of the board. Whereas initially, we would work from left to right, we pull tickets in. And as I mentioned, a lot of those tickets would pile up then in progress. So working from right to left means our focus was very much on the computer testing the end goal the ready to deploy state. So our focus would be there. And if there were any tickets blocked, then we would jump on those tickets. And I think that's made one of the biggest differences. If we're unable to unblock a ticket, then we're unable to bring more tickets in. So it makes it much more important that we focus on getting that ticket unblocked. We also find that with a slight tweak to the board as well. So for example, our columns, they will be set up with a ready for tests column. In some cases, previously, some time ago, we would have a blocked column. So these columns weren't really doing anything, they weren't active columns, so to speak. So it was difficult then to reduce your work in progress with those columns in place because they were like a parking lot. So by removing those columns, and focusing on just the three columns, really, which was to do in progress test, then we were able to have better visualization of the board, clearly see what was on the board clearly see any blockers and those tickets that focused on the sprint goal. So in that respect it Yeah, it really helped. The other thing as well is identifying our aging tickets. So that was another tool I introduced. And we were able to see if a ticket has been in there for seven days, for example, in a given sprint, why is it still in that particular column? What can we do to help move that piece of work on so that there's been many benefits, to be honest, other things as well, we've moved on to breaking down tickets into smaller tickets, so that we can actually get those tickets through to completion, which is, again, what we were struggling with before you bring in a huge ticket, chances are it's not going to get completed in a sprint, and then it moves on to the next one and potentially could move on again into subsequent sprints. So by really breaking that those tickets down that that's absolutely helped.

Dave West  9:32  
That's awesome. Oh my gosh, a lot of benefits there. I really like the couple of things that stand out. One is around this sort of it helped to get the whole team focused on you talked about moving from right to left as opposed to learn to write by getting the team are focused on that. You you get things done really. And getting that sort of visualization In simplifying the board, putting in more things at track, how long things have been in progress? Well, you know, that sort of the, in the class, there's this thing that we use of a banana, you know, the fact that you get this sort of aging thing and like a banana skin gets brown, the older he gets, I thought that was always I can't help but now every time I look at an issue in JIRA, I'm like, oh, where's how Brown is that banana? Which is, which is interesting. And then, you know, the power of whip work in progress? I think it is. It's funny, though, as human beings, I don't know, if you find this Elon that we liked, it makes us feel good. When we're starting lots of things, it makes us feel like we're really busy and stuff. But ultimately, the more things you have in progress, the less likely any of those things will finish. And I think there's loads of studies that show that and, and using Kanban to effectively drive that is incredibly powerful. I think they're great messages.

Helen Swift  11:09  
Yeah, I mean, we definitely find that what what tended to happen was multiple tickets, when people in the developer would sit on multiple tickets. And then when the next developer went to grab a ticket, it wasn't next, necessarily the next prioritize ticket, because the previous developer was sat on multiple tickets. So then we weren't really focusing on the things that mattered the most. So it's really helps now to when we've kicked off a sprint to not assign tickets to individuals, either, it literally will be they'll grab the top one in priority order, take that in work on it, and only take one or two tickets in it most progress that right the way through before pulling another one in. Now, initially, one of the challenges I had back from one of the dev team members was, I can't put any more tickets in otherwise will impact our whip limit. So what do I do? My response to that was just delve in see if you can support another member of the team, see what you can do if there's a blocker help them, unblock it, maybe pair programming wherever you can do to really move that ticket along. Because at the end of the day, that's that's value to our customers value to our business.

Dave West  12:27  
That that is that's a great message. I think the the there's so much sort of individualism in industrial work practices, waterfall practices that we want, okay, so give me the ticket, I'll work on it. Well, I'm done. And there's no more tickets. So I'm just gonna sit here, when you've got three or four teammates sitting there going, you know, I'm busy, I'm far too busy, I'm stuck, I need some help. But they don't want to say that and you end up by making this explicit, you can create that environment and you get some side effects, like people learn stuff that they didn't know, before. They build stronger relationships, there's increased amount of trust. And and also, sometimes it's nice to work with others. Sometimes. Yeah, so we are human beings. That's awesome. So let me use you, you did talk a little bit about metrics for a second. What sort of metrics are you starting to use the classic Kanban metrics like throughput, etc.

Helen Swift  13:37  
It's tends to be throughput. So we focus mainly on throughput to the amount of tickets that are actually completed in each given sprint. So I have a an average throughput for each of the teams. So we can understand roughly how much we're going to bring into the, into the sprint during sprint planning, I've actually find that very, very helpful. Because you can just look at your board, you can prep her head, I generally prep about two Sprint's ahead with this with the teams. And we'll look at those texts and think, Okay, well, we've roughly got about 1011 in here, and if that's dependent on your average throughput, of course, so we can pull those in, we can look to see if there's any that we may need to push out. What we don't want to do is overload our sprint. And that's something that's happened in the past we've bought way too many tickets in but having that the ability to understand on average, how many tickets we're likely to complete or your throughput is really helped us.

Dave West  14:43  
Yeah, I think there is a propensity for I know I certainly do it is to my eyes are bigger than the bat and my belly as it were, I think it's an English expression that I don't get to use very often, Helen, so I like to use that. Or the Vegas buffet model, which is you run in You fill up these plates and you run off and and then at the end, you know, halfway through, you can't eat it or you're like, ah, dear, wish I hadn't take that extra crab leg or something. So there is a sort of natural sort of desire to do that, by having that data, you can clearly encourage better practices around consumption. Yeah.

Helen Swift  15:26  
You know, it's not perfect, but it's a good gauge to be able to let us know, we complete about this amount each sprint. So let's pull that in. And that hopefully will help us to complete those tickets right the way through.

Dave West  15:40  
So tell me a little bit about the size of your stories or your tickets that come into your into your sprint? Are they all the same size? Are you using some right sizing?

Helen Swift  15:53  
Yeah. So yes, what we tend to do is keep our tickets breaking down. And so they generally tend to be around five and below. We don't bring anything in bigger than that. If it is bigger, we use the Fibonacci sequence, by the way for story pointing. So for example, it was an AE, then we would look to break that down and bring it in a five or below. So whether that be a 123 we tend to do a similar thing with our fives, we will look at a five and I will also say to the squad, could we sorry, I say squad, we use the term squad and team just to make sure I didn't confuse anyone, we will look at the five and say, Can we break it down that little bit more, because the smaller the ticket is, the easier it is to complete. So we make sure that there's a range of tickets coming in, we don't have a whole stack of fives. There's generally some ones in there some twos and maybe a couple of fives, so yeah, right sizing absolutely works. And that works with your throughput. What wouldn't work is if we brought in, say, I'll say, average throughput was 10. And we brought in 10, eights, I mean, the tickets are just too big to complete in a given sprint, it's just not going to work. So there's this I have found with the teams, it does work. So keeping those tickets smaller, keeping those numbers smaller, breaking down as much as we can. It's been a bit of a challenge at times, initially, when we implemented this way of working, the, the teams would say, well, we can't break it down any further. And I quite often got that response. And I would say, Well, why what what's preventing us from doing that? Oh, because it's just it is what it is. So okay, so what can we do? So can we pull the analysis out of it and break and break that down? Maybe we can bring that in as a spike? What could we do? So when you start talking that through, we then come up with ways of Oh, yeah, actually, let's try that. So ways of actually making it work for us. So that was generally a way of breaking a ticket down. And so it does make it more manageable.

Dave West  18:07  
And I also think that that that conversation in itself is incredibly useful as well, I will say write this down, because it's so things become bloated. There's a lot of assumptions that are made by everybody. And by making those assumptions very visible by having that conversation, you're suddenly you discover that something that was maybe an eight or bigger, you know, is not you don't have to have all that stuff. Some of it's a nice to have some of that is additional. And we can actually make it a two or three, and actually get the value that we were actually seeking. And the other stuff is something that we could put into a different ticket and have later. That's really, I think that's a really powerful, powerful message. So all right, so we've adopted Kanban in, in your Scrum teams, we've got that visualization whip limit, you're starting to break work down, you're you're driving a more effective process because of that you're delivering more stuff you're getting to done so. So what's next talent? What's next?

Helen Swift  19:13  
What is next? Well, very recently, we moved over to Why would say proper story pointing. Initially, we were working in hours, which days, I should say rather, which I'm sure other companies do the same thing. And I'm sure they have the same struggles with story pointing. So that's something we have recently changed. And I feel that's made the world of difference because it's taken the pressure off of our dev team members, because they would be looking at the ticket. They'd say, Well, we think it's two days work. We can't say for sure. And that ticket will be brought in and it may be that it's going on and going on. We're into day three we're into day four and and then they're really be struggling, do you get that pressure if then, but we said it was going to be two days, and the business thinks it's going to be two days, and we're not going to get this delivered. So I really wanted to move away from that approach and move on to proper story pointing where we're actually looking at that piece of work. And we're thinking of it in not just the amount of time ie the effort involved, but also the consideration of risk involved in that ticket, the complexity that goes with it as well. So that's something we've done recently, and we have adopted across the business, which is really helped. So we're really nicely aligned there. The other thing that I would like to work on, which is in some of our teams, there is a very much a mix of dev and test, and are quite often you will find that developers, they develop the testers they test. So it's ensuring that we maximize our time within the sprint as much as possible. We're doing everything we can again to get those tickets through. So my focus really is what can we do to get some of our our dev team members testing as well, it could be that the testers would write up the test scripts, and so they do the prep, and then the devs can actually start looking at that and supporting our testers a bit more, because we do have more devs than we do testers. So we've got a bit of an imbalance there. Again, I think that's quite common as well. So it's just finding a way other ways to progress that work on other other things is where we're focusing on is automation, which will obviously make a big difference as well, that will reduce a lot of the manual testing. So again, so that that's another key focus right now for our teams.

Dave West  21:55  
That sounds awesome. I have to say, if you ever want test automation to happen, the best way of getting it to happen is to hand over testing to developers, because the last thing they want to do his testing and the firstly instantly, and then they build a robot to do it instantly. So and by partnering them up and pairing them with tests, as you get you end up with the best of both worlds, you end up with that real high quality output in a in a very efficient and effective way. Even though at the start it feels very inefficient often because you're like, Well, I'm just much better at this if you just wait. Well hang on a minute. Are you? Yeah, so it's an interesting thing. So it sounds like lots of exciting things on the horizon for Simplyhealth and and your work there. That sounds sounds awesome. So thank you for today we've we've reached our our time box, which is obviously very important in Scrum, so we try to keep to that. So thank you for sharing your journey with us, Helen. It's been really, really interesting. Really appreciate you taking the time out of the day to get on this podcast today.

Helen Swift  23:07  
Thank you for having me. It's been lovely.

Dave West  23:11  
Okay, everybody today, on the scrum documentary podcast, we had Helen swift from simply health a UK based help solution provider. And Helen shared reverse her journey around the use of Scrum with Kanban. Look, you know, many people think that you're either this scrum camp or a kanban camp. But I think what Helen showed today was the to work perfectly together. And when you use these two approaches together, you end up having the best of both worlds. So it's definitely worth something exploring. Thanks for listening today. This is your host, Dave West, here on the scrum.org community podcast, wishing you a great day and Scrum on bye bye