Just recently, an update to GMail totally threw me when it subtly changed the way it did something that I use many, many times a day. Although this change probably seemed trivial to the team at Google, it really has been a pain in the neck for me.
Changing the user experience for a popular piece of software is a difficult tightrope to walk. Too little change and you stifle progress whilst changing it too much risks loosing or annoying the user base.
So what caught me out? I get a notification of what has changed in my groups as a top level entry in my inbox. I found this useful since I could simply go to the group, see what has changed and read the items that were of interest at that moment. I return to my inbox and the notification would be removed - happy days.
The update has subtly changed this. Now, it seems to want me to read ALL of the items the notification is related to. If I don't then the notification remains at the top of my inbox until I have viewed everything it relates to or I simply dismiss the notification by swiping it to the left.
This is a tiny change in all reality, it could even be a mistake but I find this change in behaviour very annoying since it requires more action from me. I imagined how this might have been recorded:
Given 1 or more groups have been configured
When the user enters their inbox
Then a notifications is displayed for each group that has new mail
And the notifications are at the top of the inbox
And the notifications are ordered descending by the amount of new mail in the group
It has long been my contention that the words we use in scenarios are often a bit sloppy. In this case you could easily interpret this in 2 ways, which revolves around how we interpret a 'new' mail item. Is a mail item new if it has never been opened or when it has been seen via clicking on a notification?
By not really explaining what 'new' means we may have killed existing behaviour by simply misinterpreting what the original intention was. In this case the word 'new' is not clear as it is open to interpretation.
A good practice is to think how this could be interpreted in the future. Would this be exactly the same as now? If there is any doubt, then deliberating over the words used is a good use of time. The emphasis should be on the author to think about this rather than make the assumption that the reader will interpret correctly.
It is worth thinking about what you know and they don't - the conversation for my scenario may well have included what 'new' meant or it could have been well established by that specific team. Since it completely missing from the scenario, we will never know.
As the author we have access to the whole context of the conversation, so the odd word here or there does not appear to matter. If we take a step back and put ourselves in the place of our intended audience we can often see assumptions we have made and save them a lot of time and effort in the future.
Monday 30 March 2015
Tuesday 24 March 2015
Retrospective: The 'Perfect' Sprint
This retrospective switches the attention of the team from the sprint they just had and allows them to explore what their 'perfect' sprint would look like. I have used this with teams that had a bad sprint - topics from the sprint will surface irrespective.
We represent the sprint as 4 columns - Prep, Planning, Dev Day, Review. You can choose the columns you want to focus on. The team then write up stickies for their perfect sprint, focusing on a column at a time. You will find that opposites occur at this point e.g. the opposite of what actually happened in this sprint. You can pose questions to get to the root cause and add more stickies if required.
I usually pair people for this, which seems to work better that everyone individually participating. I allow a time box of about 5 minutes and then we quickly go through the points raised. You can group common themes at this point. We repeat this for each column in sequence, following a journey through the sprint.
The key is keep the team focused on the perfect sprint. You can dive into specific issues as required - these will likely be based on the current sprint so they make good topics for discussion. I found this fits into a 60-90min retro with 4 columns at a good pace. If you have less time you can use less columns.
At the end we start to highlight what is in our control. This is usually pretty high - 50-75% seems to be about right. This leads the team to the obvious question - why don't we have our perfect sprint more often, given so much of it is in our control?
This outcome drives which actions we want to take into the next sprint - taking one from each column is a nice idea, but it does depend on what you came up with.
We represent the sprint as 4 columns - Prep, Planning, Dev Day, Review. You can choose the columns you want to focus on. The team then write up stickies for their perfect sprint, focusing on a column at a time. You will find that opposites occur at this point e.g. the opposite of what actually happened in this sprint. You can pose questions to get to the root cause and add more stickies if required.
I usually pair people for this, which seems to work better that everyone individually participating. I allow a time box of about 5 minutes and then we quickly go through the points raised. You can group common themes at this point. We repeat this for each column in sequence, following a journey through the sprint.
At the end we start to highlight what is in our control. This is usually pretty high - 50-75% seems to be about right. This leads the team to the obvious question - why don't we have our perfect sprint more often, given so much of it is in our control?
This outcome drives which actions we want to take into the next sprint - taking one from each column is a nice idea, but it does depend on what you came up with.
Monday 23 March 2015
Retrospective: Ghost's of Retro's Past
This is a retro design to confront teams with actions from retros that have not been put into practice. Without actions there is little point in the retro, right? This is not a format you can run regularly - ideally you should not have to!
Start of by hunting down all the outcomes from the previous 4-5 sprints. Print them off in large print, cut into individual cards, fold them up and place them in a bowl. On a board or wall, draw out 3 columns - Ditch, More and Done. The team now take it in turns to pick an action from the bowl and place it in the column they think the action is relevant to.
Encourage discussion at this point - I played devils advocate often e.g. "I thought that was done?", "Didn't you do that?", "Yeah, we said that 3 months ago...." - you might not be so mean.
If actions are in More they are still relevant so there is no reason why they should not be done. Anything in More represents a missed opportunity for change. It is worth pointing out how awesome these ideas are and that they already came up with them - seems like a bit of waste.
Ditch suggests this is no longer relevant - you might want to explore if this is because they are old or we have evolved as a team. You might want to ask why didn't we need it? What do we know now that we did not know when we came up with this action? How did we ever survive without it?
You can also look at the Done actions and look at why they were Done - are they special/easy... what was different? It might come as a surprise how little has been 'Done'. This can be a valuable learning exercise in itself.
You can now focus the learning on why we did not do these things and then tease out which ones from More should we do immediately. Make sure the team buy into addressing these items in the next sprint. Ask the question "What could we put into practice today?".
Start of by hunting down all the outcomes from the previous 4-5 sprints. Print them off in large print, cut into individual cards, fold them up and place them in a bowl. On a board or wall, draw out 3 columns - Ditch, More and Done. The team now take it in turns to pick an action from the bowl and place it in the column they think the action is relevant to.
Encourage discussion at this point - I played devils advocate often e.g. "I thought that was done?", "Didn't you do that?", "Yeah, we said that 3 months ago...." - you might not be so mean.
If actions are in More they are still relevant so there is no reason why they should not be done. Anything in More represents a missed opportunity for change. It is worth pointing out how awesome these ideas are and that they already came up with them - seems like a bit of waste.
Ditch suggests this is no longer relevant - you might want to explore if this is because they are old or we have evolved as a team. You might want to ask why didn't we need it? What do we know now that we did not know when we came up with this action? How did we ever survive without it?
You can also look at the Done actions and look at why they were Done - are they special/easy... what was different? It might come as a surprise how little has been 'Done'. This can be a valuable learning exercise in itself.
You can now focus the learning on why we did not do these things and then tease out which ones from More should we do immediately. Make sure the team buy into addressing these items in the next sprint. Ask the question "What could we put into practice today?".
Friday 13 March 2015
Retrospective: Island Voyage
The concept behind this is to encourage the team to replay their sprint and discover key parts of their journey. The linear voyage you take the team on means we focus on the whole sprint rather than just remembering the final few days, which might not be the best to refer to.
You start with drawing an island in the top right of the board. This is the destination and represents what we delivered. Mine has palm trees and a tiki bar - it is a lovely place to be :) You can have fun with the name, mine was 'Delivery Island' which is a bit boring.
You start the retro by asking, which kind of vessel represented this sprint as the icebreaker. You draw this in the bottom left hand corner of the board. You can play with the speed of the boat, how large it was, was everyone on board, did we have space space for more stories, what kind of motor did it have, was everything ship shape - you get the idea. Naming the boat is a nice touch.
You can then spread out the visual cue cards for the team to see. These help them explain events or things they noticed on their journey to the island in the boat they described. I usually give a description of what they are too as this gets peoples creative side kick started.
If it was a not a clean sprint, you can ask the team where they got to. Was it close to the island? One of my teams decided they got to 'Acceptance Bay' but never made it the island itself. Maybe it went terribly and they ran out of fuel halfway?
Encourage them to use the cards as cues to describe their journey to the island, these can represent things we saw, things we avoided or things we did e.g.
During the journey you can experiment with detours - you can ask "did we have to go that way?", "Was this the scenic route - was there a more direct way?". You can also explore short cuts - these represent a better way of doing things based on what you know now - "Can you see a faster way of getting from here to here?". Maybe you the team got lost? If so, how did they get their bearings again?
The journey path can meander and double back on itself if the team had problems. It can suddenly go straight if there was a breakthrough. You can go around features if you avoided them (The Hurricane of Support) or show the path going through them (The Whirlpool of Broken Builds) if it was a rough time. You can stop off at places if you had slow progress and show the paths of other obstacles that you crossed which maybe hindered or halted your progress.
The linear nature of the journey lends itself to story telling and the nautical metaphor is pretty easy to grasp. By telling the story of the sprint, you often cover things that we might have forgotten about otherwise.
You start with drawing an island in the top right of the board. This is the destination and represents what we delivered. Mine has palm trees and a tiki bar - it is a lovely place to be :) You can have fun with the name, mine was 'Delivery Island' which is a bit boring.
You start the retro by asking, which kind of vessel represented this sprint as the icebreaker. You draw this in the bottom left hand corner of the board. You can play with the speed of the boat, how large it was, was everyone on board, did we have space space for more stories, what kind of motor did it have, was everything ship shape - you get the idea. Naming the boat is a nice touch.
You can then spread out the visual cue cards for the team to see. These help them explain events or things they noticed on their journey to the island in the boat they described. I usually give a description of what they are too as this gets peoples creative side kick started.
If it was a not a clean sprint, you can ask the team where they got to. Was it close to the island? One of my teams decided they got to 'Acceptance Bay' but never made it the island itself. Maybe it went terribly and they ran out of fuel halfway?
Encourage them to use the cards as cues to describe their journey to the island, these can represent things we saw, things we avoided or things we did e.g.
- did we avoid any big storms or did bad weather push us off course (hurricane)
- did we know where were going (compass)
- was our time kidnapped or did we have to go out of our way to avoid being kidnapped (pirates)
- is there blood in the water or do we need to be cautious (sharks)
- did we see anything amazing (sunset)
- did anything distract us (dolphins)
- was there somewhere we would have preferred to be (desert island)
- was there the threat of destruction (sea monster)
- what held us back or what stopped us from floating away (anchor)
- what could sink us or what did we manage to avoid (whirlpool)
- did we have anyone overboard (man overboard)
- where we all alone or did we loose our way (dead calm)
The cue cards mean the team don't have to draw anything but if you have a creative bunch, ditch those immediately! If they cannot see a picture that represented what they wanted then they can draw anything they like. You can find pictures easily on Google - I would watch out for mermaids though, they tend to be NSFW (you have been warned).
During the journey you can experiment with detours - you can ask "did we have to go that way?", "Was this the scenic route - was there a more direct way?". You can also explore short cuts - these represent a better way of doing things based on what you know now - "Can you see a faster way of getting from here to here?". Maybe you the team got lost? If so, how did they get their bearings again?
The journey path can meander and double back on itself if the team had problems. It can suddenly go straight if there was a breakthrough. You can go around features if you avoided them (The Hurricane of Support) or show the path going through them (The Whirlpool of Broken Builds) if it was a rough time. You can stop off at places if you had slow progress and show the paths of other obstacles that you crossed which maybe hindered or halted your progress.
The linear nature of the journey lends itself to story telling and the nautical metaphor is pretty easy to grasp. By telling the story of the sprint, you often cover things that we might have forgotten about otherwise.
Subscribe to:
Posts (Atom)