Subscribe
Share
Share
Embed
Steve Wells talks about his platform for Agile games and simulations, and how they can be used to illustrate complex Agile concepts, such as inter-team dependencies, in easier to digest ways.
Solving big problems with small teams
Intro: Ladies and gentlemen, the Tiny DevOps Guy.
[music]
Jonathan Hall: Hello, everybody. Welcome to another Episode of Tiny DevOps. I'm your host, Jonathan Hall. On this show, we like to talk about Dev and Ops and related topics for small teams. Today I'm excited to have guest Steve Wells, who does agile games and simulations.
He has a website about this, and we're going to talk about the value of some of these games. Steve, welcome on the show. Thanks for coming.
Steve Wells: Thank you.
Jonathan: Before we dive into games, would you talk a little bit about your career, maybe what you've done, what led you to doing games and how that came about?
Steve: Yes, absolutely. Started off as a dev many years ago, probably started right at the back end and moved my way through the front end and fell out the front and became a scrum master and then got into agile coaching at companies like Sky, Marks & Spencer, giffgaff, ClearBank, these kind of companies.
I kind of got to the stage where I felt I was doing the same kind of thing over and over, I was enjoying it, the coaching but I thought I was in a lucky position. I was able to semi-retire at the end of 2019 and decided to look something different. Then, of course, the pandemic hit. I thought, well, what would be useful is as agile coaches, we do all these round the table games and things, they're really exciting and they're a really good way to show a complex concept in a simple way so I started to wonder if we could do this online and built a few things, a few simulations and that's where it all came from, really. I started collaborating with a few people on some interesting games and that's where we are now.
Jonathan: That's good. Well, anybody who's worked with a scrum master has certainly seen if not a true game, at least some sort of retrospective-ish game. There's all those different things there.
Of course there are tools like-- I think Miro is a popular one that provides you that level of frameworks for those things but it's not really a game, like you said, there's not a winner or loser or a full simulation. It's more of a framework around something, so you've taken this concept a little bit farther, is that right?
Steve: Exactly. Yes. I think what we're noticing, when we allude to things like Miro and particularly the game, the flagship game I suppose, our No Estimates game that I developed with Matt Phillip, what we realized when you try to do that on Miro is, it ends up as it's not quite there. It doesn't quite work, and what we discovered was actually, if you play the game on your own browser, then it's much more engaging, so rather than sharing a screen or a Miro board or something.
Obviously with a game, there's much more complexity when you can program into a Miro board. You can have stuff where you can move things around on a Miro board but obviously with a more complex game where you need dice roles, or you need things to happen automatically or you need to stop people being able to move certain things unless they've completed certain tasks, it becomes much more engaging if you you're playing on your own browser. So you're play in a breakout room on something but on your own browser and we found the engagement is pretty much like the real thing and we we're quite pleased with that.
Jonathan: What is your website? We'll talk about it at the end also but what is your website where you have these games hosted?
Steve: Yes, it's called agile simulations.co.uk and that's for historical reasons because I initially started out trying to build simulation that showed that the knowledge sharing yet from pairing would mean that ultimately you would develop things faster. I'm not sure I got the maths right on that, it didn't quite really work so
I'm still building that.
What that did give you, that gave you the platform to put the rest of the games on, so we did a simulation from there on how was the best way to deal with dependencies, and it turns out if you always do the other team's work before your own, that's the most effective way of getting work into the system, [chuckles] which is controversial.
Jonathan: I recently watched your talk about that on, so we'll talk about that in more detail in just a moment, but was that the first game then that landed on this platform?
Steve: Yes, pretty much. Then after that we did the Coin Game, which is one of our favorite games. To be honest, I think that's-- some of these games, I think are a lot better the online version than the real face-to-face version but the Coin Game I still think is much better live, it's very visceral and noisy and competitive but it works online and it's good.
It's in a situation where obviously in UK now, we've gone back to working from home again as of next week, so it allows us to play these games. I think that one particularly is probably better to play face-tof-ace but it's still my favorite little agile game.
Jonathan: How many games are on the platform as of today?
Steve: About eight or nine I suppose, or something like that and I've also recently just also extended the platform to build an assessment platform, so to do things about Spotify health check or scrum assessment or agile maturity, that kind of thing. It's now going to a generic assessment platform as well, where you can basically chock in you own questions and all the data scrum sheet is done for you.
Jonathan: Let's talk about that game you just mentioned, I don't remember the name of it, but the one that that makes the point that doing other people's work first is the best way to go. What do you call this game or the simulation?
Steve: It's actually a simulation, it's called Interdependent Teams, I think.
Jonathan: Okay. Describe it for our listeners. What does this simulation do? How is it set up?
Steve: Yes. Well, what it does, the idea is that you have a set of teams and they each have to do their own work. They've got their own backlog, but as part of their backlog they also have tasks from other teams, which they have to do, and they have to decide when to do the work. Obviously at some point they're going to get blocked because another team hasn't done the work that they need.
The idea is what happens when you get blocked? There are three rounds to this simulation. The first round is basically you carry on doing your own work regardless until everybody gets blocked. Then obviously that means there's a big powwow between the POs and the management and so on, and then decide who should do the work next.
The second round is basically you do your own work until you get blocked and then you do the other team's work. I think in reality, most companies are somewhere between those two because often, usually, but you're never out of things from the backlog to do, there's something else. So you never get the stage where you've got nothing to do and you can muck up the team. Most teams are somewhere between those two. If you run the simulation, it's basically based on a pack of cards. Each team is a suit in the pack of cards.
You run the simulation doing the second strategy, where as soon as you're blocked you to work on the other team's work is actually slightly better than not, but the third round is you always do the team-- If you've got any work from other teams, you always do that work before your own. This is up to three times faster in the simulation, which is quite amazing.
It makes sense if you realize because nobody then ever gets blocked because as soon as some work comes in from another team, you just do it so you unblock that team, and they're doing the same for you, so there's much less blocking and also it's what comes around, goes around. They do work for us, we do work for them. It's a nice way to operate. Also, there's no negotiation because I think the real problem with dependencies is that, if you you've got some work that you need me to do and I've got some work, my own work, we've got no idea how we can relatively prioritize those two pieces of work because I'm an expert in my work and you're an expert in your work so I don't know if your work's more than mine or vice versa.
If you just always the other team's work first, then it might be less important, who knows? But in the long run, it all evens out and it ends up quite nice and collaborative and you can't fob people off because the other thing I've noticed, particularly with lots of teams I've worked with in the past. "We've got to do some work for the other team," and they go, "Yes, okay. Actually, we haven't got enough information. Can you go away and find some more information? We'll look at it next week." So you fob them. But you can't do it if you've got to do their work first. Another benefit of it.
Jonathan: Basically, by stepping away from the simulation into real life again, if you're on a team and you have some other team, you're in a company with three or four or ten teams and there's some interdependencies, do the other team's work first and it will make your own work faster, not just the other team's work faster? Is that what you're saying?
Steve: Yes. Makes everybody faster. In the simulation it's three times faster. It's slightly contrived, but I think you're something near that benefit in real life.
Jonathan: I've certainly seen that benefit within a single team when you have developers who are waiting on code review for example. If you have a backlog of pull requests that haven't been reviewed yet and when I've switched the priority of the teams I'm coaching and say, "Your first priority is to, before you do anything else, always review any unreviewed code,": and that just speeds everybody up. Of course, it only works if everybody does it though, right? If you only have one person doing it and everyone else is, as you say fobbing off, then you have one person who's only reviewing code and everybody else is writing code. It does have to be a team effort.
Steve: It does. It's kind of the same for the team as well because sometimes you might have one team who have all the dependencies. So spend the whole time doing the other team's work. It really only works if there's roughly the same amount of dependencies between teams.
Jonathan: What other games or simulations, I know you have the No Estimates game, maybe we can talk about that one for a minute. What's the premise there?
Steve: Yes, this is a great game. I actually made this first for a conference, Agile Cambridge conference in, IK think, 2017 with the inventor of the game, who's called Matt Philip from St. Louis, and he works for Pfizer now I think. It's a great game. It's just a Kanban board game and basically, you play as a team and you get perfect information about your backlog, which you wouldn't get in real life but this is quite interesting.
You basically know exactly how many work items there are, exactly how much effort is required for each work item and you know exactly how much effort you have per day in the team to do it. You simply have to estimate how long it takes you to get these 25 cards across the board to be done and everybody gets it wrong. [laughs] Always. We've played it. Well, I know we're pretty good, couple of project managers, agile coaches, we know our stuff, we're miles ahead. [chuckles]
It's really just demonstrating these two things. The first thing it demonstrated the [inaudible 00:11:38] test, it was going to be wrong because cars are dependent on each other, development teams get blocked all kinds of reasons [inaudible 00:11:45] but then what we do in the game is we take the results that we've got, we run Monte Carlo simulations, on it to show that you can do something a bit more scientific and instead of estimating, you can do forecasting based on the previous data that you have.
It's more scientific, and it also allows you yo have a much better conversation with your stakeholders, your product owners, because you can say, well, instead of just giving you a date, but it's almost certainly going to be wrong, we're going to say, well, there's a 50% chance we finish it by this date, there's a 90% chance we finish by this day, and then 99% chance we finish it by this date. That's a much richer conversation because if it's like well, it's just something we want to get as quick as possible to test the market then 50% is probably okay but if it's legislative or something or it has to be there, then we will now say, well, we can do it by the 99% chance [inaudible 00:12:39].
It [inaudible 00:12:39] those two things and as I already had a platform, I thought, "Actually, I'll contact Matt, this'd be a great game to play to build online," and we did and it's fantastic and we believe it's better than the face-to-face game because there are things like in the face-to-face game, you have to roll a dice to see if things are blocked. You can do that all automatically in code, you can stop people moving cards when they're not finished or cheating, some people cheat but also, the really good thing is you get to the end of the game and you go look, here's your cycle time. Here's your flow efficiency that you've just done this game rather than that kind of stock kind of image because we generate that data on the fly as the games go through.
It's very, very powerful. You can't argue with this data, you've just done this and these are the results that you have just done as a team. As I say, it's really, really, really powerful and people get very engaged about it, they're always surprised by it and you can show the difference between the teams and what the different strategies they use [inaudible 00:13:38] at work. It's hugely engaging.
Jonathan: I find it's often difficult to explain-- something I maybe I've maybe learned through experience, it's really hard to convince somebody-- maybe I can articulate it. Maybe I'm talking about whip limits or something like that and the effect that it might have on your flow. I have seen it work enough times, I've read the goal, I read the Phoenix Project, I understand how this stuff works, but explaining it to somebody, you almost have to say, "You you need to go read these books now and have my last 10 years of experience before you understand it," but these games can kind of short circuit that, can't they? and provide a way to turn-- like in this example of the No Estimates game, you turn what is essentially, I don't know 20 weeks' worth of work into a 20-minute game and you can see how that works much faster than living it out and experiencing it yourself.
Steve: Exactly. It allows you to kind of distill the concept into a game and say this is the one thing I'm going to demonstrate and just do it very well with the game. I think that's-- I guess with all the messiness of real life, what's going on literally? So we've just got to concentrate on this one contract in this game. It just shows you how, it's a great way to learn about it.
The same thing with Coin Game is also-- that's another thing is because a lot of people play [inaudible 00:15:02] recording game or a penny game, whatever they want to call it, to demonstrate the small batch sizes because you get things [inaudible 00:15:07] but this version takes it another a step further. You play with a set of coins, there's £20 worth of coins of various denominations and the first round, you do a waterfall approach and then the second round, you do coins [unintelligible 00:15:23] but the third round, what happens in the first round, we give them two minutes, they don't deliver anything usually. The second round, they deliver the £20 in about one minute, 45 seconds something like that, and they go this is pretty good.
Then the third round, we give them 10 seconds to deliver as much value as they can. Of course, by delivering the highest value items first, they tend to deliver about 80 to 90% of the project value in 10 seconds and that's a real kind of eye-opener. It's every time we'll show people this, they're just, "Wow," the penny drops. It's a no-brainer.
Jonathan: You're demonstrating the Pareto Principle principle with coins in 10 seconds.
Steve: Exactly. The question really is, because it's actually coins, it's very easy to say look, you're actually delivering value. You've delivered £18 of value, it really rams home that value is what we should be delivering.
Jonathan: What other games do you have on the platform right now?
Steve: The other games? Well, I've got a few that I've just got knocked off people. We've got the Survival Game. You're cast adrift in a boat, but all of these things, the kind of old-style games, but because they're online, you play on your browser they're a bit more engaging than normal.
We also do-- I've forgotten the name of the guy who invented it, he'll kill me for that [chuckles] but it's on the website and that's Agile Battleships and that's a great way to show reports of feedback loops in agile [inaudible 00:16:58].
Jonathan: Explain that one, I haven't played that. Explain how that one works.
Steve: It's just very simple. It's not an agile battleship. Basically, you have a set of ships and the other person has to on a grid try and hit without seeing that they are on you and you tell them if they've hit or not. The traditional battleships game, but one person gets the feedback of whether they've hit the ship or not after every every move. The other one gets feedback at the end. [laughs] So it's fairly obvious who's going to win. [laughs] Every time. It's a very simple and quick game but it's just-- for anyone who knows battleships, it has a little twist on it to show the importance of [unintelligible 00:17:36]
Jonathan: Are there any games that you're working on right now that aren't ready yet?
Steve: Well, the interdependency was one. We're trying to turn that into a game rather than just a simulation. That's very early stages. The other game we're working on is the Pipeline Game, which is a terrible name. Marketing's not my strong point, but the idea here is you have a set of things you deliver and some of these [inaudible 00:18:08] and you have to make a decision whether to fix the bugs or not.
The idea is to explore because they if you do fix those bugs, sometimes the customer doesn't see them. They're overwritten by other things you deliver on that, that kind of thing. You might waste time triaging bugs and fixing them and putting the effort in and not delivering other things. To deliver bugs that the customer doesn't see or doesn't care about. Everything has a customer satisfaction kind of value added to it and a negative one for bugs and so on.
As as you go on, you realize that when you're delivering this stuff, the things you're delivering are making up a pattern. Then you go, "Oh, I see. Now I know which things I need to deliver". The idea is that by delivering stuff you're working out what it is the customer actually wants as it all comes together and it just allows you to explore the-- obviously, you don't want to just deliver all the bugs willy nilly because that's really bad, but also do you really want to waste time fixing some minor bugs or some bugs that the customer might not see? And which is more important to the customer?
Ultimately, their satisfaction is giving them what they want or giving them 100% quality stuff with no bugs ibn it. So it's exploring that kind of spectrum. Obviously, there's no right or wrong answer, really, it's clearly somewhere in the middle but obviously, enough quality to keep them happy but also you want to deliver fast enough to deliver what they want. So it's how we explore that thing. I've played it a couple of times. It needs a bit of work but it's getting there.
Jonathan: This is fun. I've played a handful of these games before. Of course, we talked before and you showed me some of them and they're fun. I would love to collaborate with you at some point on a DevOps game. [chuckles] I don't know what it's going to look like yet, but I think it would be fun to-- I don't know. I guess there is a Phoenix Project game that I haven't played yet. You have to hire a trained game facilitator to come do it with your team. It's not something you can just buy it off the shelf or play it online. Maybe someday I'll play that game.
Steve: Yes, I suppose it's just a DevOps game. You could kind of explore the difference between having a separate ops team and bringing out a team that does the deliveries and sales and see the difference will bring that into the team. Maybe that could factor.
Jonathan: Yes, there's so many different areas of DevOps that could be explored. That's a great one. Should you have your ops people on your dev team, or should you have separate teams? One of the things I really would like to focus on is batch size. I mean, your Coin Game already helps with that, but the idea of adding an element of risk to each iteration.
Sometimes, an iteration or release fails. It doesn't get deployed, or you decide to revert it because the customer needs have changed or whatever. Adding some element of-- some of your batches are discarded. That means you need smaller batches too so that you don't-- if you wait till you have 15 things ready, and you have to discard them all, you would lose a lot more than if you just lose one. Something like that would be a fun sort of game to explore from [crosstalk].
Steve: Yes, absolutely. Yes. Yes, I've had some very real-world experience by a previous company. I probably shouldn't name them. They were doing scrum sprint delivery every two weeks, quite happy with it, which is great. Then I pointed out, it actually failed [inaudible 00:21:43] 60% of those deliveries [inaudible 00:21:47]. They went, "Oh, that's bad," so they stopped developing new features and spent three months building a CICD pipeline. By the time I left, they were delivering twice a day, and the projects were going, "This is great. I can find out what the customer wants twice a day rather than once before [inaudible 00:22:04]. It's game-changing." It'd be great to build some kind of game around that.
Jonathan: Yes, that'd be fun. I just liked the idea of introducing these games and the idea of doing games as a way to make a point. So if you're listening and you're struggling with convincing your team that smaller batches make sense or that no estimates make sense or many other things, maybe you can use one of these games. Maybe, I don't know if you want to talk about this. How could you go about creating your own game? I don't know if that's something you're prepared to discuss.
Steve: Yes, it's a tricky one really. All right, I think the thing is the platform that I'm using is based around Vue.js and Node and Mongo. It's actually very quick to knock up new games. If anybody's got any ideas, I'm happy to collaborate with them on those. I've built a couple. I've started working with a couple of people on some of those things.
I think the game design is tricky. I think the thing to do is to distill out what concept it is you're trying to get across, and strip everything else away from that. A lot of these games get too complicated. I've seen people use the Coin Game, the physical one, and they had various bits in [unintelligible 00:23:22]. It dilutes the point that the key space is that one point I want to make very strongly and just make it very strongly and that's it ad the game's short.
You don't need to make it complicated, make it very simple. [unintelligible 00:23:35] Kanban game that lasts a couple of years, I think, if you play it properly. I'd say it's very good. It's trying to do all things. I think the best games are the ones that just say here's one point, and we just ram it home so you can't possibly misunderstand the point I'm trying to get across, just that one point [inaudible 00:23:55].
Jonathan: Is there any risk in or have you received feedback or pushback from people who say, "Yes, I see the point of your game, but I don't think it's valid. It's too simple. It's not realistic because it's too simple." Have you ever gotten criticism like this? If so how do you address that?
Steve: Yes. Sometimes, people say that. Particularly with our No Estimates game because it's based around that perfect data that people will say, well, it's-- especially when it gets discussed at the Monte Carlo simulations and then how you can forecast them. It's very much like, "Well, what about this? What about if this happens? What about if the team changes size? What about if our tasks aren't all the same size?"
The great thing about the Monte Carlo is all of those kinds of variations are taken care of. It doesn't matter what variations are in your data. They're taken care of by because you're doing simulation rather than estimating. People do sometimes go, "Bit too simplistic,' but I think if they forget the underlying concept, they take that away, and they can dilute it for their team. The Coin Game, particularly, it's like you should deliver the highest value items first. You always get kickback on that. People say, "Well, I think it's really working in banking," and [crosstalk]
Jonathan: Everybody's business is a unique snowflake, isn't it? [laughs]
Steve: Exactly, exactly. What they always say, what's the point of delivering the highest value items first if we've got to deliver everything anyway legally? It's a legal reason. I say, well, because I have this very much when I was at ClearBank and we were doing exactly that kind of thing. It's like, "Well, you're actually better off when it gets to the deadline, instead of saying to the regulators we haven't delivered anything, if you say, we've delivered 90%, they'd go, "Well, that's okay." That 10% that you haven't delivered is the lowest risk item for those value items, things that people don't use.
So you're still covering yourself even if you get fined for that bit you haven't done, it's going to be smaller than if you've left a pretty big thing off the bat. Like we just worked through alphabetically or something. So far the biggest kickback I usually get is why do high-spend items first if it's just [unintelligible 00:26:12] avoid that.
Jonathan: All right. If anybody's interested in collaborating with you, or they have a great idea for a game, how can they get in touch with you?
Steve: Yes, just go to the website. They contact me straight from the website is easiest. There's actually a page on the website called Labs, which you can go to, which has got stuff I'm working on. You can enter your own there [inaudible 00:26:35]. Yes. Just get in touch and we'll have a discussion. I'm on LinkedIn, Steve Wells on LinkedIn.
Jonathan: Give the website address one more time.
Steve: Yes, it's agilesimulations.co.uk.
Jonathan: All right. Great. Is there anything you'd like to add, Steve, before we sign off?
Steve: Yes. Probably just the other thing. It's just based off the assessment thing that I'm doing. That's quite new. I think everywhere I've worked, we've always done the Spotify health check. It's great. It's really, really great. I think it is really engaging. But it's always a complete nightmare because you have to have a spreadsheet of all the results. It's a real pain
What the assessment thing does is it basically stores all that stuff in a database so you can look at one team at a time. You can look at individuals on the team. You can look at it across the organization. You can compare teams with each other. All of that data is already in there, and it just takes away all that hassle of the spreadsheet phase. That's the worst part. So if anybody wants to use that or any other kind of assessment like in agile [inaudible 00:27:32] that's over there. I think the key to that is it's not particularly clever like the games or anything, but it does save a lot of time.
Jonathan: Is there a subscription fee for people who want to use these games and simulations?
Steve: Yes, it's quite low. I think it's about 5.99 a month for a lot of the games, and the assessment's 11.99, so it's [crosstalk].
Jonathan: That's in pounds. If you're in the US or Europe or somewhere else, just do a currency conversion.
Steve: Yes, in pounds. Yes, it's very low. It just pays for my server. [laughs]
Jonathan: Yes, quite accessible. Yes. Great. Well, I love that. I love the topic. It's been fun talking with you, Steve. Thanks for coming on. Let's be in touch and do a DevOps collaboration at some point.
Steve: Absolutely. I look forward to it. [laughs]
Jonathan: All right. Thanks for listening, everybody. Hope to see you next time.
Steve: Cheers.
[music]
Jonathan: Find me online at jhall.io. The theme music is performed by [unintelligible 00:28:36].
[00:28:41] [END OF AUDIO]