My wife is awesome except for the odd occasion when she stomps all over one of bright ideas. Then, obviously she turns into an insufferable little smarty pants.
Such an event happened recently, when I showed her some of my blog articles. On reading the stuff I had written on Situation Cards, she simply said:
"Hmmm.... these look like Social Stories..."
What? Surely, you must be mistaking my incredibly creative Situation Cards with something else.... Turns out, not.
Social Stories and Comic Strip Conversations are used to help kids with autism understand social situations.
Although the value I was trying to derive from Situation Cards is slightly different, the medium and concept are the same. These have been around since the early 1990's and were created by Carol Grey.
There is a load of information on these which is well worth diving into if you found the idea interesting. For example, Carol Grey uses colours to indicate different feelings or ideas.
Although this was designed to help kids with Autism, Social Stories and Comic Strip Conversations have been used with a wide range of people and circumstances, so why not understanding business value too?
Monday, 21 September 2015
Thursday, 17 September 2015
Super quick themed retrospectives
At the beginning of my current role, I decided (possibly foolishly) that I would not repeat a retro with the same team. The goal was to create a new retro for each team, every time.
Some, I have lavished time on but when you need to pull one together in double quick time, I took the advice of Helen Meek who is the master of the themed retro.
The theme is usually a movie but musicals, sports, bands or TV shows are equally applicable. You can get creative with this and I think pretty much anything goes.
We all want to get actions from our teams so we pose questions about the sprint to help them look back and find those improvements e.g.
etc etc
Using the theme, we can cunningly wrap the same questions up to keep the whole thing interesting and unique.
Here is an example:
Happy, Mad, Sad is sooo 1990s! Replace Happy with Joy, Mad with Anger and add Disgust and Fear and you have the main characters from Inside Out:
Quick and easy. Also works with kids up to 8 years old :)
With a bit of imagination you can pick 3-5 scenes from any film and come up with some questions to get your team thinking here are some examples from "The Internship" (which was an unpopular choice solely due to it's Rotten Tomatoes score, geeks eh?):
Since these are quick, you can tailor them to the teams current situation. When a few people left one team, I quickly added a '"How are we going to stay together?" question in a matter of minutes.
Google is an obvious place to have a look for scenes from films or you could have a look at film-grab.com to get those ideas going. Here's one that Dan Rushton sent me, which made me chuckle:
Still stuck for ideas? Get the team to suggest a movie or something they are interested in. So when I heard one of my teams discussing the Great British Bake Off...
Maybe it could be a new film they are all talking about? Maybe a Xbox/PS4 game? A season finale, perhaps? The format is simple and flexible and I enjoy them as fillers between more focused and structured retro's when there is something I want to "deep dive" into.
Be warned. Some people don't get metaphors. There is no helping these people, believe me I have tried :(
For a masterclass, be sure to visit the many blogs of Miss Meek, enjoy!
Some, I have lavished time on but when you need to pull one together in double quick time, I took the advice of Helen Meek who is the master of the themed retro.
The theme is usually a movie but musicals, sports, bands or TV shows are equally applicable. You can get creative with this and I think pretty much anything goes.
We all want to get actions from our teams so we pose questions about the sprint to help them look back and find those improvements e.g.
- What problems did we encounter?
- What's going to hit us next?
- What went well / not so well?
- What went according to plan?
- What caught us by surprise?
etc etc
Using the theme, we can cunningly wrap the same questions up to keep the whole thing interesting and unique.
Here is an example:
Happy, Mad, Sad is sooo 1990s! Replace Happy with Joy, Mad with Anger and add Disgust and Fear and you have the main characters from Inside Out:
 |
| What made us happy? |
 |
| What did we find unpleasant? |
 |
| What made us sad? |
 |
| What should we be scared of? |
 |
| What made us loose our temper? |
With a bit of imagination you can pick 3-5 scenes from any film and come up with some questions to get your team thinking here are some examples from "The Internship" (which was an unpopular choice solely due to it's Rotten Tomatoes score, geeks eh?):
 |
| How did we help each other out? |
 |
| What did we get wrong? |
 |
| What can we celebrate about this sprint? |
Google is an obvious place to have a look for scenes from films or you could have a look at film-grab.com to get those ideas going. Here's one that Dan Rushton sent me, which made me chuckle:
 |
| Did we see anything shocking? |
 |
| What was our showstopper? |
 |
| What was the technical challenge? |
 |
| Which of our creations would have turned Mary's stomach? |
 |
| What did not go according to plan? |
Be warned. Some people don't get metaphors. There is no helping these people, believe me I have tried :(
For a masterclass, be sure to visit the many blogs of Miss Meek, enjoy!
Wednesday, 2 September 2015
Why Scrum teams between 3 and 9?
We all read the Scrum Guide but have you ever wondered why the band of sizes that is prescribed?
Recently, I have been working with a large team which was 10 people (8 developers and 2 QA). It was interesting to see the problems that came from this size team so I thought I would jot them down.
Problem 1 - Capacity
If you have a large team, you end up with a large capacity. A 2 week sprint for 10 people means an epic 540 hours (6 hours a day for 9 days, after taking out 1 day for ceremonies). That's a lot of work to prep and get ready! Most sprints we found it difficult to prep enough for a commitment against our full capacity, forcing us to bring more in mid sprint.
Problem 2 - Prep
Having mentioned prep, the larger the team the more difficult it is to get everyone focused. It also has the side effect of you sacrificing over a days development for each hour you prep. This is obviously scaled up, you cannot escape this - but the larger the team, the slower the prep felt which means the losses are amplified. We had an additional problem that our team area was not really big enough for everyone to see the ample 50" screen we used to access our backlog.
Problem 3 - Crowd Control
Prep and retro's were interesting times for the Scrummaster. Getting people focused and keeping them there was challenging. Finding a space which we could work with was a challenge. Prep sessions were either silent or we had too many voices at once, which we needed to work harder to bring everybody under control.
Problem 4 - Visualisation
Large capacity means lots of stories. We found it difficult to visualise the work simply because we could not get it all on the wall. This meant we often had stories 'waiting' to make it to the board. This made if difficult to see the full picture for both the team and the stakeholders.
Problem 5 - Ceremonies
With more people we needed more time for pretty much every ceremony - this ate into our sprint window. With lots of work the planning sessions often turned into epic half day marathons that everyone hated and retro's would take about 50% longer just because it took a bit longer to coordinate the team for each part of the retro.
Problem 6 - Sprint Composition
We had to be more careful about what tasks ended up in a sprint. With so many people, we often ended up with stories that blocked each other since they were in one area that shared code, unit or integration tests. This stopped us from being able to work in parallel on them. One sprint contained only stories for a single component, which caused us a multitude of delays as we tripped over each other repeatedly.
Counter measures we tried:
Split Prep - We did 2 rounds of prep, allowing us to sanity check the requirements and do investigation using the bare minimum of developers, minimising the impact on the team. Our desired outcome from this round of prep was that the developers involved would present the story to the rest of the team, replaying allows the PO to confirm solid understanding. By the time it got to the team we knew it could be done and had any investigation/spikes covered so it was all about spreading understanding of the story.
Timeboxes - when we had the full team at any session we enforced 1hr timeboxes. More than that and people were too fidgety to work with. If we needed longer we broke up for a 15min break to get refreshments and repeated the time box.
Diverge and Merge - in planning we asked the whole team to task out the story. There was obvious duplication but the differences were the interesting bits that leverages the teams different thinking on the problem - some people thought of things that others did not. We then had a game to see who could keep the most stickies on the board. This worked better than allowing one person to drive but was not always liked by the developers. Main benefit is you get everyone engaged.
Two Boards - for a while, we had 2 different boards for different classes of work. This allowed us to visualise everything but also meant we had 2 stand ups. Not going to lie, it was weird.
Two Retro's - we did 2 retro's for the first sprint so we could keep the groups small. Universally hated by everyone we did not do it again. The split was based on the classes of work we used to split the boards BUT people worked across the boards so it was very odd. Not recommended.
Huddles - we often had 2 standups a day to coordinate work. With a larger team, they can burn through tasks quickly when working in parallel on a single story. This meant more coordination that a single stand up was needed. Wasn't a bad lesson to be honest and we do this even now when tasks are not moving or causing problems.
In conclusion, the 9 boundary is probably arrived at from trial and error. We were only 1 person over the 9 but we saw some interesting effects - I would guess team 8 and up might see some of these issues.
We had 2 BA's as well as the PO and myself making the full Scrum team a whopping 14 people at the majority of the ceremonies. Although the Scrum guide only considers the development team, you might was to think a bit broader and how that might effect your ceremonies.
One question I was asked - why not split the team into 2? This team worked on a single product. Splitting the team would have meant extra coordination by the team to make sure that what they were working on was known about by the other team. The team were also concerned about knowledge transfer, which they had worked hard on in the last couple of months leading to much better product knowledge throughout the team - splitting the team could have set back this progress.
My sweet spot seems to be around 6 - large enough to deal with holidays and sickness but small enough to enable knowledge transfer. This also feels about right in all the ceremonies.
Recently, I have been working with a large team which was 10 people (8 developers and 2 QA). It was interesting to see the problems that came from this size team so I thought I would jot them down.
Problem 1 - Capacity
If you have a large team, you end up with a large capacity. A 2 week sprint for 10 people means an epic 540 hours (6 hours a day for 9 days, after taking out 1 day for ceremonies). That's a lot of work to prep and get ready! Most sprints we found it difficult to prep enough for a commitment against our full capacity, forcing us to bring more in mid sprint.
Problem 2 - Prep
Having mentioned prep, the larger the team the more difficult it is to get everyone focused. It also has the side effect of you sacrificing over a days development for each hour you prep. This is obviously scaled up, you cannot escape this - but the larger the team, the slower the prep felt which means the losses are amplified. We had an additional problem that our team area was not really big enough for everyone to see the ample 50" screen we used to access our backlog.
Problem 3 - Crowd Control
Prep and retro's were interesting times for the Scrummaster. Getting people focused and keeping them there was challenging. Finding a space which we could work with was a challenge. Prep sessions were either silent or we had too many voices at once, which we needed to work harder to bring everybody under control.
Problem 4 - Visualisation
Large capacity means lots of stories. We found it difficult to visualise the work simply because we could not get it all on the wall. This meant we often had stories 'waiting' to make it to the board. This made if difficult to see the full picture for both the team and the stakeholders.
Problem 5 - Ceremonies
With more people we needed more time for pretty much every ceremony - this ate into our sprint window. With lots of work the planning sessions often turned into epic half day marathons that everyone hated and retro's would take about 50% longer just because it took a bit longer to coordinate the team for each part of the retro.
Problem 6 - Sprint Composition
We had to be more careful about what tasks ended up in a sprint. With so many people, we often ended up with stories that blocked each other since they were in one area that shared code, unit or integration tests. This stopped us from being able to work in parallel on them. One sprint contained only stories for a single component, which caused us a multitude of delays as we tripped over each other repeatedly.
Counter measures we tried:
Split Prep - We did 2 rounds of prep, allowing us to sanity check the requirements and do investigation using the bare minimum of developers, minimising the impact on the team. Our desired outcome from this round of prep was that the developers involved would present the story to the rest of the team, replaying allows the PO to confirm solid understanding. By the time it got to the team we knew it could be done and had any investigation/spikes covered so it was all about spreading understanding of the story.
Timeboxes - when we had the full team at any session we enforced 1hr timeboxes. More than that and people were too fidgety to work with. If we needed longer we broke up for a 15min break to get refreshments and repeated the time box.
Diverge and Merge - in planning we asked the whole team to task out the story. There was obvious duplication but the differences were the interesting bits that leverages the teams different thinking on the problem - some people thought of things that others did not. We then had a game to see who could keep the most stickies on the board. This worked better than allowing one person to drive but was not always liked by the developers. Main benefit is you get everyone engaged.
Two Boards - for a while, we had 2 different boards for different classes of work. This allowed us to visualise everything but also meant we had 2 stand ups. Not going to lie, it was weird.
Two Retro's - we did 2 retro's for the first sprint so we could keep the groups small. Universally hated by everyone we did not do it again. The split was based on the classes of work we used to split the boards BUT people worked across the boards so it was very odd. Not recommended.
Huddles - we often had 2 standups a day to coordinate work. With a larger team, they can burn through tasks quickly when working in parallel on a single story. This meant more coordination that a single stand up was needed. Wasn't a bad lesson to be honest and we do this even now when tasks are not moving or causing problems.
In conclusion, the 9 boundary is probably arrived at from trial and error. We were only 1 person over the 9 but we saw some interesting effects - I would guess team 8 and up might see some of these issues.
We had 2 BA's as well as the PO and myself making the full Scrum team a whopping 14 people at the majority of the ceremonies. Although the Scrum guide only considers the development team, you might was to think a bit broader and how that might effect your ceremonies.
One question I was asked - why not split the team into 2? This team worked on a single product. Splitting the team would have meant extra coordination by the team to make sure that what they were working on was known about by the other team. The team were also concerned about knowledge transfer, which they had worked hard on in the last couple of months leading to much better product knowledge throughout the team - splitting the team could have set back this progress.
My sweet spot seems to be around 6 - large enough to deal with holidays and sickness but small enough to enable knowledge transfer. This also feels about right in all the ceremonies.
Subscribe to:
Posts (Atom)