Yesterday I did something I have never done before in my 5 years or so as a scrum master…. I held a retrospective outside! My current team are based right in the center of London and are lucky enough to have a park right outside of the building. Yesterday was one of the handful of lovely sunny days we get in a British Summer so I made the suggestion we go outside. Here are some pictures
The team seemed to really respond to being outside and a very open and honest conversation about the team and the sprint they had just completed was had. The format of the retro was
- Intro – Movie review the sprint
- Gather Insights – 4 L’s – Liked, Lacked, Learned, Longed For
- Decide what to do – Actions were gathered as we discussed the 4 L’s and were summarised and evaluated as to whether they can be achieved in a sprint
- Closing – Thanked the team for their attendance and promised to buy them an ice cream next time we do a retro in the sun!
A couple of things I noted for the outside retro that you may want to consider
- London is noisy! We had Ambulances, cars, lorries and all sorts making noise during the retro which meant that sometimes it was hard to hear
- We had a dog who kept coming over for us to throw its ball to him, note: throw a ball once and a dog will always come back to you!
- Ensure you have something to stick post-its or cards to to take back, i had a notebook i captured all of the output onto so i could summarise when back in the office
I have recently started working with a team that i haven’t worked with before and to get an insight into how they have operated previously, what have they achieved in the past year and what they hope to achieve in the new year i held a Christmas Carol Retrospective.
My main stream of work is as a contract scrum master which means i tend to spend varying amount of times with clients and teams. Most of these usually involve some kind of handover from or to a new scrum master at some point. In fact just this week I have started a handover with one of the teams I currently work with to a fellow scrum master who is a permie where my current contract is as i start to work with a brand new team. This got me thinking as to what does or doesn’t help when it comes to handovers and whether there are any areas I could improve on.
Being from the “correct” side of the pond, thanksgiving isn’t a holiday I’ve ever celebrated but today being Thanksgiving in the USA it made me think what am I thankful for in my agile journey. I’ve used the giving thanks warm-up numerous times in a retrospective but never truly thought of the people who have helped me in my journey as a Scrum Master. Continue reading
Pineapples aren’t something I am overly fond of, whether it be on their own or heaven forbid on a pizza! The latter being an age old debate that I have found to split near enough every team I have worked in. However, pineapples are something i find very useful when working with Scrum teams.
Recently the team I am scrum master of had some tasks that were identified retrospectively that should have been tackled sooner in the sprint to have allowed the team to swarm more effectively on the story. To remedy this I printed and laminated a series of pineapples and encouraged the team to use them to highlight anything that if we sit on for too long will hurt us. Since introducing this the team are visualizing potential pain points and are being discussed more frequently, whenever these are present the team are now saying “who’s going to tackle the pineapple”. I find it a light hearted way to deal with an issue and helps the team self-organise around the tasks in their sprint. let me know in the comments if you have used anything similar.
I first read of this technique via LinkedIn from an ex-colleague a while back but cannot find the original source, if anyone reading this knows of this please let me know as i would like to credit them.
Yesterday i tried a new retrospective technique with the team i am scrum mastering. The inspiration came from here (thanks guys at Fun Retrospectives).
Its called the Hot Air Balloon and encourages the team to look back as well as forward. It also gives me a chance to try and improve my dreadful drawing skills (yes that picture has been drawn by a 31 year old man and not a child!)
I was recently asked by another Scrum Master to facilitate a retrospective for his team as he wanted to take part. The team were looking back over their Alpha phase of their development which was 10 weeks or so long.
As you would expect a lot of items came up during the retrospective as the team were looking back across quite a large period of time. One thing that was quite interesting was that some members of the team felt in their sprint retrospectives that they weren’t given the chance to voice their opinions as the retro’s very quickly became very tech heavy and in-depth (the team have faced a lot of technical challenges during this phase). This left the non developers on the team feeling like they were not really included in the conversation and lead to some discontent and bad feeling, which as anyone will tell you is not fantastic for team morale and productivity.
Recently I’ve been working on a greenfield project for a CMS website to replace a temporary site that was thrown together quite quickly. As part of this we held a discovery phase which enabled the team to establish user need, some very high-level technology explorations and create a backlog to estimate cost and size. The next stage of the project was to start building something which meant we needed to take our backlog and estimate it.
Recently I’ve noticed a worrying trend in a few organisations that I’ve worked with in that they think the Product Owner role is dispensable when using Scrum. At times it has been as extreme as not having a PO at all to the lesser end of the spectrum where there is a PO but they are doing this role alongside their usual “9-to-5” and can’t commit sufficient time to the team. Both scenarios (and anywhere in between) are dangerous and something i feel should be avoided.
Recently I have been working on a project for a new client delivering replacement digital processes for their paper based predecessors. Due to the nature of the work I am unable to provide specifics about the projects but can divulge the approach the team has used to achieve this work.
On day one of my assignment the team and myself were cobbled together and asked to finish off the project which was started six months ago or so. The project has been dormant whilst a third party went away and developed their part of the system in an waterfall way (perhaps i’ll save that experience for another blog!). Whilst a backlog existed it hadn’t been refined for around six months and contained some items that were done, some that weren’t required and was missing a lot of stories that we had to do.