I help my first retrospective for a while recently (that’s not to say the team hasn’t been retrospecting, just that others have been doing it in my stead!) and the team wanted to do the Mad, Glad, Sad exercise.
Shockingly, I didn’t know it. Or at least, I didn’t think I did.
The exercise starts with everyone writing on three different coloured posts-its the things that made the mad, glad or sad during the sprint. We then stuck them all up on the whiteboard under an appropriate picture.
We all studied it for a while, but I couldn’t really work out what the difference was between mad and sad. The idea of a retrospective is that you inspect and adapt. Look at what you did, how you did it and change things if they need improving. The idea of mad and sad should be things that, affected us negatively that we want to change in future sprints.
But what is the difference? I asked the team. They didn’t know either.
So, we set about trying to decide what each thing meant. In many retrospectives in the past, we’ve realised that there are things that went wrong, didn’t work or just plain sucked that we could fix and there were things that can be classed as ‘Shit Happens’. Stuff that, while we might expend some effort in fixing them, are unlikely to occur anytime in the near future, so we draw a line under it and move on – there are always more pressing things to deal with.
So, using this idea, we renamed Sad to “Get stuff off my chest” and Mad to “I’m not going to take it ANYMORE”.
This means, we can highlight things that annoyed, frustrated or saddened us, but that, realistically speaking, there isn’t a lot of value in dealing with and then the stuff that REALLY got under our skin and we have to deal with.
Once we’d renamed them, we then re-sorted the post-its we’d stuck under the two columns and found that, things we might have dealt with as a real problem and spent time working on, were no more than just people wanting to have a rant, and real problems might have been overlooked as they hadn’t been applied with enough gravity. Perhaps the team member feels that it’s just something bothering them and doesn’t want to make an issue of it.
We worked through all three columns and, during discussion, decided to move some from Sad to Mad and vice versa as we discussed the pros and cons of each. In the end, we had a good, solid list of things that ‘we’re not going to take ANYMORE’ which turned into a list of definite actions.
So, if you run this exercise with your team, check their and your assumptions about what Glad and Sad mean – you may be met with blank looks – and make sure you all have the same understanding to make a good exercise into a great one.
I read in my twitter stream today, this from @lloydwatkin:
I really hate bullshit phrases used in tech, my latest word of hate is ‘timebox’ 04/05/2011 15:16
and it got me thinking about time boxes. I use the word a lot and use the concept of time boxes in almost everything I do and Lloyds comment made me think “is this just a bullshit idea, or just a bullshit word, or bullshit in general?”
When meetings suck
I don’t know about you, but I’ve sat in my fair share of meetings that totally sucked. No one really had much to say, the conversation goes off on tangents, someone announces that we can’t talk about that now as it’s part of a ‘series of conversations that we need to have’ and everyone inwardly groans. There’s no agenda, no action points … nothing. Usually one person will dominate the room, quacking on as if they love the sound of their own voice, making statements based on little more than opinion, causing everyone in the room to raise an eyebrow and, maybe, an eye from their game of Angry Birds under the table. People pretend to take notes on their pads on their knees, when really they’re drawing larger and larger concentric circles and colouring every other one in while perhaps writing a poem, or ode to boredom*.
These are the meetings that everyone hates, when there are too many people, no agenda and people prone to waffling about shit only 20% of the room understand or care about. How does time boxing help here?
An agenda is a time box. If you’re booking or facilitating the meeting, you’ll find that an agenda and the authority to chair the meeting are all you need to have a successful outcome (assuming you have an idea of what the outcome should be). When you book the meeting, set the agenda in the meeting request:
00 – 10mins – Welcome and introduction
10 – 20mins – Talking about the herping
20 – 30mins – A demonstration of the derpa-machine
30 – 40mins – The future of the thing
40 – 60mins – Q&A, action points and AOB
These are time boxes. Maybe you don’t call them that. Most people call them agenda points and many people will leave off the timings, but by adding the time boxes to it, you’re subconsciously telling the attendees that, unless something extra happens, this is what we’ll discuss and this is how long you can expect it to take. If 50% of your attendees don’t care about the herping and 50% don’t care about the derpa machine, then those people know exactly how long they can draw concentric circles or play angry birds for. Or, they’ll know they only need to give 10mins attention to something they’re uninterested in and that’s better than 60mins attention to find the 10mins you’re interested in. Doing an agenda will also give people time to think about what they should be doing to prepare for any, all or just their part of the meeting. Finally, by setting a perimeter around an acceptable length of discussion time gives you the authority to say: “OK, we’ve run out of time for that agenda point. Batman and Spiderman, if you have more to say on this matter, please book another meeting and invite those people relevant. OK, so onto the next point…”. Trust me, people will be relieved.
So, by simply adding some timings to your agenda (which we can agree are useful) you’ve created time boxes. Things look good for time boxes so far.
What about meetings that can’t have an agenda?
Well, some meetings can’t. In SCRUM there are two that definitely don’t have any kind of official agenda; retrospective and sprint planning. Retrospective is a meeting where the team discusses HOW they did the work in the last sprint and what could be done to make it better. Generally, this involves everyone taking turns to say what they though was good, bad and how they think it might improve. Timeboxing here lends itself well in that, you divide the length of the meeting (in minutes) by the number of people and that’s how long each person get’s to speak for. They’re each time boxed. If there are six people retrospecting for an hour, they get 10 minutes each.
As for sprint planning, you can do the same with each section and then the stories. You’ll have to play with timings, but I suggest:
00 – 10mins – Cocking around that devs do getting coffees etc. 😉
10 – 3omins- Quick groom of the backlog
30 – 60mins – Work out velocity and commit to stories
60 – 240mins – This is where it get’s fuzzy. It all depends on how many stories you’ve committed to. If you’ve committed to, say, three. Then divide the remaining time by three and get on with it. If it’s many stories, then perhaps set aside 45mins for the first story, 30mins for the second and 20 mins for the rest. Remember, you don’t have to do all your planning up front!
So, score two for time boxes. Without time boxes, sprint planning would but much harder and probably longer. Besides, they’re also one of the basic rules of scrum!
But that’s not all…
When scope creeps
Imagine, if you will, that you’re working on a bit of software, or a website and you show it to the stakeholder. They say “Hey, that’s nice, but can you…” and then give you a list of amends, some of which are huge. Welcome to scope creep.
If you’ve been in software or web development, you’ll have been a victim of scope creep. You get the list, you work your way through it and, all of a sudden, you’ve run out of time.
“But wait, ” you say, “surely time boxes cause this ‘lack of time’ problem.” Well, yes and no, but they definitely provide you with a reason NOT to do the stuff that has crept out of scope. Scrum is based around the idea of time boxes. Without them there wouldn’t be iterations. An iteration, or a sprint, is a timebox. Sprints don’t get extended, or shortened (although they can be cancelled). At the beginning of a sprint, the team commits to a bunch of stories that the product owner wants done. They work on them and, when nearly finished, will show the product owner or stakeholder who might say “Hey, that’s nice, but can you…” . To which you answer…
“… No, but if you wait unti the end of the sprint and ask me, I’ll do it then.”
Anybody reasonable can see that it’s a good compromise: work has been asked for that is clearly out of scope. The developer doesn’t have time to work on it during this timebox, but the timebox is there, defined and immutable, therefore can be used placeholder for when the work CAN be done (apart from the fact that the extra work needs a user story and estimation and prioritisation etc) and the stakeholder or product owner only has to wait until the end of the sprint (the maximum wait will be two weeks). Usually, by that time, they decide it’s not a relevant change anymore, or it was so insignificant as to be forgotten.
The point is, it’s there to add some boundaries, to protect the developers from scope creep and to protect the stakeholder from adding work that isn’t well thought out or valuable (this is quite a simplistic view, but it proves the point of the value of time boxes. Obviously, lot’s more comes from the scrum framework in order to derive value, but out of the scope (fnarrr!) of this article).
Right, so that’s three for three … next!
When the kitchen is a mess
So, when I said I use time boxes in almost everything I do, I meant it. I mean even my personal life and I suspect you do too (even you @lloydwatkin!). As an example which is fresh in my mind from last night: I was tidying the kitchen and had set myself some time boxes: 10mins to wash up, 5 mins to clear and clean the table, 5 mins to sweep the floor and 10 mins for extra stuff — 30 mins to clean the kitchen.
With these time boxes set for myself, it become a challenge to get this stuff done in those time boxes. And lo and behold, it takes 30 mins to do a chore which might otherwise take me an hour and a half (most of which would be procrastination). It also stops me from doing too-much-work (K.I.S.S!) as I might put something in a cupboard and think “Hmmz, that cupboard is a mess, I’ll just give it a quick tidy.”, et voila, scope creep.
Finally, time boxes aid immensely with parenting. If you’re a parent you’ve probably said (or shouted): “10minutes until bedtime!” and this creates an unwritten expectation (much like the meeting agenda or the sprint length) that, at the end of 10 mins, some action will happen (bedtime). Instead of the ambiguous “Bedtime soon!” which leaves it open ended and easy to abuse.
What to avoid
Boyles law states:
For a fixed amount of an ideal gas kept at a fixed temperature, P [pressure] and V [volume] are inversely proportional (while one doubles, the other halves). – Wikipedia
Which means, gas will expand to fill available volume. This law can also be used to describe development:
For a fixed amount of ideal developers kept saturated in caffeine, velocity and time are inversely proportional.
Which means, work will expand to fill the time allocated to it.
This is not always true, but you should be wary of it. Some teams will feel that, they have two weeks, so they can take it easy if they’ve underestimated a story or two. This is not fine. Velocity should remain constant. If at any point your teams feel they have undercommitted, then commit to more, or do something with value to the team – rebuild a tool, or refactor some code or SOMETHING and perhaps next time, commit to a little bit more and see if you can stretch a bit further. It’s a limbering excercise.
A time box is a limit, not a goal. If you’ve got a 10 minute time box in a meeting, or elsewhere, you don’t have to fill it, you just have to have finished within that time box.
Scrum is not about keeping the faith, I am completely committed to scrum, as, I think, are you. It’s about hearts and minds. American military generals bang on about it all the time and for good reason. For months and months we’ve been calling it a “stand up” or a “scrum” and, on the very eve of launching our latest product, which was designed, written, managed and launched using scrum, we switch to calling it a “huddle”. What this says, unconsciously perhaps, is that we stopped doing a standup and when we switched to a “huddle” the product got launched; not a good advert for doing scrum.
Might sound like a bunch of crap, but it’s all psychologically sound.
We are a scrum team, regardless of whether we’re actually in a sprint, if we all stand up at the beginning of a day, then we’re doing a stand up. We can do a huddle if there’s less people and it’s at a different time of the day, maybe. There are ceremonies and artefacts of Scrum and the last time I looked, a huddle wasn’t one of them. The rules are few, simple and really easy to follow. Breaking them, for whatever reason, should not be done. If you’re breaking the rules of Scrum, you’re NOT doing scrum! Simple as that. If you break the rules of chess, while you’re playing chess, you’re not playing chess and you’ll probably get a punch on the nose from your opponent for cheating to boot.
One of my responsibilities as a scrum master and dedicated member of the team is to improve the scrum process, this can only be done with more and more business buy in – if we start diluting it now, then we take two steps back. The product got delivered BECAUSE OF scrum, not in spite of it. Without scrum it would have been a different story (probably wouldn’t have failed, but it wouldn’t have been launched yet). I can only do my job with the help of the team and, although I don’t think you called it a huddle because you want to rename the standup to huddle, I need your support in pushing through scrum, which includes not diluting it.
Do you understand my point? It’s about cohesion and making sure we’re always an advert for ourselves and the way we do things and the reason for doing things and that we get things done BECAUSE of the CHOICES WE MAKE as a TEAM on how we do the things we do.
Our team sits in a horse-shoe shape where I work. Some people on the inside and some on the outside. There are no partitions, no borders and people only really put their headphones on when they REALLY want to get in the zone. Communication is key to having an effective scrum team and in this shape, totally co-located (even the DB team are in the horse-shoe and they’re not even part of the scrum team!) means communications is but a chair twhirl or a lean over the desk away.
So, with this much communication going on, is the daily stand up still worth it? Does it provide enough value for the team over and above that value currently being sucked from rich communication throughout the day anyway? It seems to be that the only people who might benefit from the standup, then, are the chickens, who really don’t listen to what we’re saying as they don’t understand it and are just there to wait until the end when they get a chance to say their piece.
Usually, not particularly interesting or worthy.
None-the-less, the stand up does provide a moment of the day at which you can see everyone’s trousers and shoes and feel like a “team”, a group of people all striving for the same goal and not a disparate set of developers hunkered behind a screen waiting for the end of the day.So, then, is the standup merely an ideal? Something that is important only for what it IS and not what it does or provides in the way of value? Perhaps, but I don’t mind either way, either options provides some benefit and some is better than none. Also, I like to look at shoes.