Troubleshooting Agile

Transcripts

10th October 2018

Welcome back to Troubleshooting Agile. It's just me this week, Squirrel - Jeffrey has disappeared off to Spain to enjoy a nice holiday, but never fear I've got something interesting to tell you about - or at least I hope you think it's interesting.

At least one listener thinks it is, he's Marcus, an old friend of mine, worked with me at a client of mine some years ago and he said “Hey Squirrel, why don't you describe that Post-it Factory game that you played with us?” and I said “That sounds like a great idea” so I'm going to do that.

It illustrates the notion of work in progress limits which is an important idea in Kanban, but even more importantly it illustrates the idea of throughput over utilisation, which I've talked about multiple times with Jeffrey on this podcast. I'm going to explain more about that idea at the end, because it'll be easier once you understand the game.

So the game is one in a long line of similar sorts of ideas - I suspect I got some of the ideas from these comparable game notions, where people try to illustrate Waterfall versus Scrum versus Kanban and so on, and they have all kinds of different methods - there's one involving pizza which sounds nice, so I'll put a couple of links to those in case you want to compare, I'll put those in the show notes for you.

But this one I like because it particularly doesn't require very much material and it's easy for me to remember - I just had to write down a few notes to remember it, I don't have to break down a bunch of rules or get a bunch of Legos or something like that in order to make it go.

So the materials you need are some post-it notes -if you're a good agilist of any variety, you’ll certainly have plenty of those - and you need some pens. You need at least three different colors, plus some black pens. So, once you have those materials and you have at least four participants, you're ready to go.

So your participants, you're going to want to explain their roles and you're gonna want to have a person who is going to be the Specifier and that person's role is going to be deciding what shape and what color to specify.

So you can think of this person as a customer if you like, someone who says I'd like to order a blue square or a red triangle, something like that. If the customer’s feeling particularly tough, he or she can say I'd like a purple and black octagon or something like that, but that's kind of being sneaky, you'll see that's not really the point.

So the second person is going to be the Shaper and that person picks up a pen and draws the outline of the shape that the Specifier has asked for. The third person will be the Colorist and this person's job is to fill in the shape with whatever the correct color is.

Oh sorry, the Shaper should also write the color or use the color of the shape, you can either outline in black or you can use the same pen - you get more competition for resources if you use the same pens, up to you whether you do it that way or not, but you can also write the words for the color, as the shaper does the shaping.

So the Colorist is coloring in and making sure that the shape is fully covered. And then the fourth person you want to pick carefully. So this person is going to be Quality Assurance and you want this person to be someone who thinks about things in a somewhat adversarial way, is kind of tough, is willing to say no.

So someone who just agrees with everyone and will allow, for example, a sloppy triangle or a teeny pink square or something like that, you don't want that person. Ideally, someone who actually works in quality assurance, who's used to finding bugs and commenting, but you really want anybody who's willing to be a little bit tough - this person will be checking that the color and the shape are correct, they match the specification and if they don't or if they're not high enough quality, for instance, if the coloring in is not full, then that person should put the post-it note on a reject pile.

If the coloring in is good and the shape is correct and so on, then it goes on to an acceptance pile. So what you wind up with is, of course, post-it notes passing among these people in that order, like an assembly line from the Specifier to the Shaper to the Colorist to the Quality Assurance person and then either onto the acceptance or rejection pile.

And so we're going to run this factory in one minute chunks, so you do need a timer of some variety, just pull out your phone or look at a clock if you need to. And we’ll want to time for 60 seconds for this factory to run and the measurement that we'll want to make is how many accepted post-it notes did we get - we can just count those.

So I often make a table on a whiteboard somewhere and I'll say for run number one, which is just a warm-up, I just want people to get used to the idea and I can give them some feedback about what they're doing and so on. Let's just see how many we can do.

So the group, depending on how efficient they are, might get, say, four post-it notes done in that warm-up round. And then I usually give them a second round and I say okay let's try this again and they go and they get it a little better, they're a little quicker at getting it done, so they might get, say, five done in that second go.

So then I try something else, I say well let's just see if we can do this as fast as humanly possible and what I want each of you to do, is to maximize your utilisation, I want you to draw as fast as you can, I want you to name the specifications as fast as you can.

I forgot something, the Specifier can write on the post-it note what the specification is - that's an optimisation that we can introduce here or at the beginning. So you might write blue square on the post-it note, that would be a way for the Specifier to go even faster him or herself.

Sometimes the participants have new ideas for how they can individually go faster and that's great, so I let them just come up with anything they want that will help them go faster and get everybody geared up and give a lot of cheerleading and get them excited and they say Ready Steady Go and off they go for another 60 seconds.

What of course happens and I'm sure listeners are figuring this out as you imagine this game being played, is that you get a pile up in front of the Colorist and the reason is you can specify really quick, you can write Blue Square pretty quick you can draw a Blue Square pretty fast, but if you have to color it in and you have to do a good job so it passes quality assurance, then you have to actually spend a little bit of time doing that so there's a natural bottleneck here. No surprise and this will be evident to everybody. But what's fun is that you get people who are a little bit competitive and they get going and they see that, in fact, they get a little pile in front of the Colorist and the Colorist sometimes then takes some shortcuts - this is where you need that quality assurance person to be extra careful and say “Oh no sorry, you were too sloppy in your colouring in and therefore you go the reject pile” so it doesn't get counted. Of course you only count those that are accepted.

So usually the number would go down at this point, so there might only be two or three or four completed. Whereas when they were just going at normal speed they would get five done. So this is an example where utilisation speed ups don't help.

So then the next round is about trying to get back to a good state. Then what you do is you introduce a work in progress limit. So you can go and look that up in standard works on Kanban like the original blue Kanban book, which I'll link to in the show notes. But the idea is simply that you say, if you reach this stage on your Kanban board - in our case if you reach this stage in our in our list of people, our participants, then you can only have so many that get piled up at that stage.

So you can make a little space and say only so many post-it notes can go here, just say only three can reach the Colorist - you want the group to help you figure out what's a good limit for the Colorist, because that's obviously the bottleneck.

And then we run another round and that's usually more efficient because the Colorist at least only has so many to do and the Specifier and the Shaper will just not have as much work to do, those people will be idle for a bit (that's going to come up in the next round)

But what happens is the Colorist is not frantically trying to keep up with an ever-increasing pile, which overwhelms is or her ability to color, but instead you get some idle initial people - the first and second participants don't have much to do, but the Colorist is not overwhelmed. So usually speed recovers, it’s still not great, it's still something like four or five, but it's better than it was when everyone was going as fast as they could.

And the final one is what I call fluid roles, so I say well look did everybody notice that Specifier and Shaper weren't doing very much, how could they help, what could we do. And they are various ideas people come up with, the most common ones are for the Specifier or the Shaper to jump over and do some colouring And then the other one is to recruit a Colorist, get somebody else to help so we got to color people, maybe even three. And once you get that parallelism in place then that unlocks a lot of capacity, the bottleneck is gone and usually that fifth round, people get seven, eight, nine post-it notes done, where previously they'd had five.

So I hope that illustration makes sense, that's how you play the Post-it Factory game. And what it's illustrating really is the idea that throughput is much more important than utilisation.

A common error is for teams, especially those with members who used to be in agencies or people who are currently in agencies, where you're billing for your time. You get somebody who says well gee what we want is for everyone to be typing all the time, we can't do any of that pairing stuff because we cut our number of productive people in half. We can't do any of this training or learning or improvement, because gosh that would that would reduce the amount of people who are typing.

It certainly increases utilisation to take steps like that, but the problem is that you don't get greater throughput usually when you get more utilisation. You tend to get a lot more wastage and you get a lot more problems of people trying to individually go fast, without making the overall system go faster.

And in fact, as is often the case, as you see in the game, you see that somebody who might be a specialist Shaper, who's really good at drawing really clear and clean and good squares and triangles and rectangles, actually turns into somebody who goes off and does some coloring and that's more efficient even though that's not that person's specialism. So what you'll see is successful agile teams will usually have some people who do generalist tasks and who are able to switch among other tasks as needed in order to fill gaps in capacity, just like somebody jumps in and helps the Colorist.

So I hope that idea of throughput over utilisation is helpful to our listeners. As always we'd love questions and comments. We're glad to get Marcus's suggestion for this particular podcast - worked out very nicely, thanks Marcus.

And if you'd like to ask us a question, come on a podcast sometime, make a suggestion, we're always glad to hear from you at troubleshootingagile.com - just jump on there and send us an email.

We'd also really appreciate it, if you enjoy these podcasts, if you'd consider subscribing in your podcast form of choice, because that helps us make sure that we can keep making these episodes and keep them interesting to lots of people.

All right thanks everybody, we'll be back to normal service with me and Jeffrey next week, thanks, bye now!

Show Links: