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.
Women, it is said, have a higher pain threshold than men. I saw evidence of this as I watched my wife give birth … twice. She went through something that I can’t even imagine having to endure. I’d have screamed ‘epidural!’ the moment the first contraction hit, but then I am known to be a bit of a wuss. My wife however, gritted her teeth and got on with it, I’ve never been more proud.
I’ve witnessed a similar thing with scrum teams. Some of the teams I coach have an extremely high pain threshold when it comes to dealing with impediments. It’s often been one or two days later that I’ve even heard about the impediment, let alone had a chance to deal with it. I suspect this might happen in other teams too and it’s worrisome; it may mean that the team doesn’t believe their SM will be able to remove the impediment (which would illustrate a trust issue and is the subject of another post), it might be a show of machismo to tough out the impediment themselves and resolve it without bothering anyone. This is an honourable motive, but chaps, this isn’t 12th century Japan, if you need help, you can, and should, ask for it. Understanding when you’re impeded and recognising the need to seek help is a more macho thing than flexing your muscles and baring your teeth, it also makes the ladies swoon*.
However, the most likely reason that people don’t raise the issue, is the team simply don’t see it as an impediment in the first place. In standups, or in just day-to-day team chat, the term “I’m waiting for…” crops up quite frequently, usually in reference to the design or operations team. This term is poisonous, it’s a pseudonym for “I’m impeded by…” and teams don’t recognise this is the case.
If you’re waiting for something to occur before you can do something else, you’re impeded by it and your best course of action, if you’re unable to un-impede it yourself, is to raise it to your SM (or your coach. ;)) and have them try and remove the block for you. Next time you catching yourself saying “I’m waiting for…” remember, you’re impeded.
Don’t tough it out, leave the high pain threshold stuff to the mothers of the world, they’re much better at it.
Recently I had a retrospective with one of my teams after two failed sprints. They cited unplanned tasks as one of their issues and suggested that perhaps the scrum framework wasn’t right for the kind of project they’re currently doing.
To give some context, this is a long running team on a long running project with no kind of release windows. One mistake that we did make was that there wasn’t a ‘Sprint Zero’; a chance to look at the project as a whole and do some time-boxed up front planning for a sprint. However, we’ve entered two sprints without some knowledge of how we plan to do things and it’s caused bad sprints.
When we began to plan the current sprint. There were some ‘technical’ stories in the backlog, for large chunks of backend work which had other stories dependent on them. They were all estimated quite high, without acceptance criteria or the ‘As a …, I need …, so that … .’ stanza to support them. This is fine, the stanza is only important when it provides value and usually not for technical stories. One of the problems was not having acceptance criteria, so the first thing we did was to define those.
After that and to get to the crux of the post though, I asked :
Describe this story in high-level steps.
To which the team discussed what would be done to do each story, we defined the tasks at a high level (much like you would do when planning proper), but after each task was defined, I asked the team to estimate the tasks in story points. It was an eye-opener!
The tasks were all coming in with estimates of 2’s and 3’s. Which meant that, when the broken down, estimated tasks were added up, they were more than the original story. This usually happens, but it was an ‘Ahha!’ moment for the team. It allowed them to think more abstractly about the work. It’s not the plans that are valuable, but the planning!
To compound the issue, we’ve been getting hung up on the idea of each story delivering functionality which we can demo. While this is a noble goal, I’m sure it’s not always possible. This was causing huge estimates on stories and, as we know, bigger estimates mean lower accuracy on that estimate. With this constraint removed, the team breathed a sigh of relief and began writing stories which were meaningful and well sized. What actually came out of it is that, once we’d broken them down, we could see that for some of them, there actually were things we could demo; speed improvements on database queries and data integrity which DO provide value and so can be demoed.
Finally, when choosing the stories to add to the sprint, the team committed to work which they used their gut feel (and their velocity, but only as a guide) on what they could fit in. I went through each story asking, ‘Can we do this and all the previous stories?’ They committed to less than they would have had they just added the original stories. Meaning that, the non-decomposed stories were causing them to overcommit without recognising it.
So, if you’re failing sprints due to unplanned work cropping up and causing you to have over-committed, then ask for high level tasks on how to complete the story and estimate each of these tasks as if it were a story, you can go too far by decomposing each task to a story level, but if you’re finding this is the case, then your failed sprints probably aren’t caused by your stories.
I like retrospectives, actually, I love retrospectives. Especially retrospectives that really get to the root of any problems the team are having and then get a great solution or at least something to try. The trouble is, retrospectives can often be stale, how many times have you been in a retrospective and had this:
So, um, yeah, good sprint, I think everything went well, didn’t it? I had a problem with some testing, but I fixed it. What was it? I can’t remember. Something to do with fixtures, but it got done.
The problem with memories is that they’re fallible. Who can remember what you did two days ago, let alone a week ago. Certainly me and, it appears, neither can the teams I coach. There are things, youcando to make retrospectives better, but this wasn’t so much a problem with the retrospective as a problem with memory. So, what did the teams do? Added a timeline to their sprint backlog. It’s quite simple really. Create a grid on the bottom and, in every standup, discuss whether anything happened yesterday that could be added to the board. The idea is to get key things on there, so, stuff that went wrong, stuff you noticed or learnt, good stuff; use it as a way to remember the timeline of the sprint. When you get to the retrospective, you’ll then have an entirely different conversation than the one above.
Some of the teams have gone a step further and added an arrow to remind them which day of the sprint it is and even added holidays/absences. What do your teams do to remember their iteration?
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.
I’ve taken some queues from the article as he talked a lot of sense, and wrapped an agile spanner around it.
The key is in the name, ‘agile’. We should turn to the holy grail; the 12 principles and four core values of the agile manifesto when thinking about how to appraise people people in our department. The four main points to take from the manifesto when thinking about appraisals, I think, are (paraphrased for context):
People and interactions over processes and tools
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts it’s behaviour accordingly.
Continuous attention to excellence enhances agility
Simplicity is essential
So, with this in mind, we can see what an agile appraisals needs to:
Dispense with forms and formality and concentrate on the conversations;
Look at how the team can work better together.
Individual agile appraisals
In individual appraisals, the ‘team’ are the boss and his/her subordinate. The boss’ focus of an appraisal should switch from the traditional “How are you performing for me?” to, “How can we work better together?”. The idea is that, the appraisal is about doing things that make the relationship between the boss and subordinate better and allowing the subordinate to appraise themselves. What do they need to do to make their input more valuable and what do they need from their boss?
This could be in terms of more training, guiding, coaching, tutoring or it could also be in terms of their relationship “I need you involved more in what I’m doing.” or “Help coach me on unit testing”. The subordinate should talk about how they’re going to make the relationship better and the boss should reply with “How are you going to do these things and, more specifically, how can I help you do that?”. This also has the benefit of reinforcing the Stop, Start, Continue idea of appraising your boss.
The whole idea here is to inspect and adapt, to spend some time reflecting how things are going and suggest and then try some ideas for the next period which reinforce the idea of a ‘team’ relationship between boss and subordinate and to ensure that the subordinate improves on issues that are important to them as well as being beneficial to the greater good of making quality software.
Bare this in mind during any appraisal: “Given who I am and what I am learning about this other individual, what is the best way for us to complement each other in getting work accomplished with excellence?”
The appraisals should be regular, at least once a quarter and last no longer than one hour. An appraisal can also be arranged at a convenient time for both boss and subordinate if either feels that their working as a team is suffering for any reason or that something that was agreed isn’t working or needs a tweak. The notion of ‘annual appraisals’ is absurd in this context.
Team agile appraisals
Team appraisals can be run in the same way. These shouldn’t be confused with the sprint retrospective. The team appraisal is where the whole team gathers in one place for a time (not sure if a time box is relevant here, I think it should be no longer than half a day perhaps, but no less than two hours) and in turn, each person works on the mantra above (“Given who I am and what I am learning about this other individual, what is the best way for us to complement each other in getting work accomplished with excellence?”), says how they feel they could improve to benefit the team and then the team provides feedback on what the team member said and perhaps offer any help, or suggest ways in which the team member might meet that improvement.
This is not an opportunity to bitch and moan. This is an opportunity to inspect and adapt and reflect on how the employee works within the bounds of their team. This is like a retrospective in many ways, instead of being about the process, however, it is about themselves.
They have the option of having their manager present, but it isn’t essential and if they don’t want them, they should not be forced to have them. The team appraisal should happen BEFORE the individual appraisal, this will give the team time to reflect honestly on how they feel they need to improve without fear of reprise, and then take this to their individual appraisal, hopefully without modifying their feelings too much before they sit with their boss.
It should be made explicit that annual appraisals are nothing to do with pay reviews. Appraisals are NOT for showing off how wonderful the subordinate is, no one writes things down they’ve done all year, they just get on with their job and do the best they can. If the appraisal was about that, the boss and subordinate would be working at cross purposes: the boss wants to talk about how the subordinate can improve and the subordinate wants to talk about all the great things they’ve done. The pay review meeting (if there even IS one) should be entirely separate.
The appraisals are about improving working relationships, not about money. I can’t stress how important this is. Without this explicitly stated, it will undermine the usefulness of the appraisal.
Another issue to think about when using money as a motivator is that it will only work in a narrowly defined way. People will do EXACTLY what is asked of them in order to get the bonus, or the payrise. They will do nothing more and nothing less, just what is required to pass the test and win the prize. Mary Poppendieck had this to say:
Using money as a motivator is like playing with dynamite because money is a VERY effective motivator. Monetary rewards motivate people to do EXACTLY what is being rewarded – not necessarily what the organization intended to reward, but EXACTLY what is being measured to generate the reward. Therefore monetary motivators have a long track record of generating unintended consequences. If there is any apparent competition for the money, money motivates people to get as much as they can for themselves. Thus monetary motivators have a track record of suppressing collaboration. Finally, bonuses for performance rapidly come to be an expected part of the landscape, replacing passion and dedication as motivators . These are things you probably cannot change about using money as a motivator.
– Mary Poppendieck
Annual appraisals or performance reviews are supposed to be an objective evaluation of the employee that helps with determining payrises derived from performance and to let the employee know where they can improve. In reality, this is not a majority of peoples view; most folks see appraisals as a waste of time: they are dispiriting and foster resentment, cynicism and inherently dishonest, instead of promoting honesty and candour. Reviews are political and subjective and create a chasm in boss-employee relationships. The link between pay and performance is tenuous at best and they are in no way objective. Would two bosses give you the same review?
Yesterday in a retrospective a pretty awesome thing happened.
The QA in the team highlighted an issue whereby he wasn’t getting the visibility he needed on the bugs he’d raised and when they were fixed. He suggested a potential solution and the rest of the team didn’t agree. They headed off, all of them, the QA included, into a discussion about how to solve the problem and came up with a possible solution involving an extra column on the Sprint Backlog. Thing is, some of the guys didn’t *quite* understand the premise and the QA guy wasn’t sold.
So, I suggested some roleplay.
As you’d expect, everyone moaned: “Bah, roleplay, what a crock!”, however, after another five minutes of inane chatter on the subject, I mentioned it again, except, this time, I leapt up and drew up some sprint tasks on post-its and stuck them on the pretend Sprint Backlog they’d made to illustrate their points and got people up to play the roles of developers, reviewers and QA. We ran a two week sprint, with four tasks, in two minutes and it worked. It proved that their idea was a little confusing and they decided to try something else.
So, if you’re stuck at an impasse about process in a retrospective, spice it up a bit with some role play and get the team acting out their sprint.