# Sunday, 11 August 2013

As a child my parents used to take me and my brother to Wells next the sea for holidays. I have to say it is my favourite beach and it brings back many fond child hood memories for me.

Faced with what to do with my parents, my nephew and the dog for 4 days recently, I happened to be cruising the internet and came up with the brainwave to relive my youth and booked up a caravan for us all at the very same site. This was my opportunity to take my nephew on the same adventures his dad and I had when we were younger.

Now, those that know me wouldn’t expect the words Helen and caravan to be in the same sentence, but I took the risk and ensured that I ordered the luxury version. I must say though that caravans have significantly improved since my child hood!

Wells has a fantastic beach, pretty woods and a little train to take you to the quaint town centre. Once in town, there’s time for the rock shop, fish and chips and a spot of crabbing. I whole heartedly recommend paying a visit if you have never done so.

547374_10152097486218975_1486863610_n552635_10152097482848975_811090123_n935854_10152097482623975_1344478238_n994259_10152097482188975_709163709_n

So whilst I was reminiscing and retrospecting with my nephew,  a couple of my friends were struggling to retrospect with their own teams. One was advised that ‘The team didn’t need a retrospective as nothing has happened’ and the other was encouraged to squeeze it into 30 minutes. Even the most mature teams would struggle in 30 minutes, but this team was only on sprint 3 and most certainly needed to discuss their issues.

This is not the first time I have seen these behaviours. Teams are not always seeing the value of retrospectives, and from my experience I would say the reasons are in the following areas:

  • They are not engaging for the team
  • Improvements or challenges get discussed, but nothing ever get resolved
  • Not facilitated well so the lose momentum and focus

Let’s tackle these one at a time.

Making your retrospectives engaging

It never ceases to amaze me how many people I meet who don’t vary their retrospective techniques, and still use the classic (What went well, didn’t go well, etc).

I encourage 3 types of retrospectives;

  • Team retrospective – A look at the last iteration from the Scrum Team perspective
  • Release retrospective – A look over a release or period of time and could include people external to the Scrum Team
  • Deep dive – A targeted retro to tackle a specific problem e.g. Why do we never complete all the stories?

There are great books and websites out there that host a whole plethora of techniques for every possible situation you find yourself in. Each team is different and will have their favourites, but variety is the spice of life. One of my earlier teams were extremely creative and so they got the most out of the drawing, word association and improve types. Others were more data driven around milestones.

Never be afraid to try out new techniques and if they don’t work, move onto the next. No one wants to be doing the same one forever! I also encourage that you get people up and active, no one wants to be glued to a seat.

Continuously Improve

Why wouldn’t you get demotivated if you are raising issues or improvements that never get actioned, and are talked about sprint after sprint. As ScrumMasters and Coaches we should be encouraging the teams to discuss these items, find solutions and take the actions into the sprint. We cap these at 2 or 3 per sprint to ensure that they are committed to and can be resolved. We need to ensure that we allow time to complete these activities as part of the sprint planning meeting.

We should also be encouraging those larger action items to be raised as user stories, and discussed with the Product Owner for scheduling as part of the Product Backlog.

Regardless of how we action them, all of the issues or improvements need to be stored, visible and brought to each of the retrospective meetings so they aren’t forgotten, and can be brought into play at any time.

Also as a ScrumMaster consider whether it makes sense for you to resolve any of these for the team yourself  E.g. Getting super sticky post it notes as the others fall off the wall.

Ultimately if the team see that issues are resolved and improvements implemented, it will encourage them to raise and resolve more. Leading to high performance  and self organisation.

Get organised

It is not acceptable to rock up unprepared. You need to prepare! Even seasoned professionals need time out to think about how they are going to facilitate the session, and help to drive out learning and information.

I usually book a timeslot of 2 hours for a retrospective and look to reduce this as the team matures. Conducting a release retrospective can take up to half a day depending on complexity of the release. Either way, leave yourself plenty of time to achieve the goal.

The book Agile Retrospectives by Esther Derby & Diana Larsen gives a good structure for us to follow and the percentage of time suggested for each section.

image

  • Set the Stage 10-15%
  • Gather Data 15-20%
  • Generate Insight 15-20%
  • Decide What To Do 20-25%
  • Close 10-15%
  • (Breaks 10-15%)

Using this structure,  slot in the format of the retrospective and maybe an ice breaker or closing game for the team enjoyment. Icebreakers are a great way to get people talking and can be used on teams that have been together for a while also. It is a fact that if you can get people to engage and speak in the first 5 minutes of a meeting, then their contribution to the meeting will be increased compared to those who did not speak.

Facilitation of this meeting is another important aspect. ScrumMasters need to be reading the unsaid word in the room through looking at the teams body language, and listening to what they are saying. Using these observations you can then interject with powerful questions to help draw out more information or feelings.

Sometimes I come across very laissez-faire ScrumMasters. There is nothing wrong with having a laissez-faire style of leadership, however some use it as an excuse to take a back seat. They can sometimes hide behind saying they want the team to solve their own problems. I agree that teams need to solve their own challenges, however sometimes the lack of facilitation by the ScrumMaster is not laissez-faire but lack of interest or they don’t understand the problem. Never be afraid to give options on how you have seen other companies solve similar problems. This can point them in the right direction, but ultimately they will implement what’s best for them.

Final thoughts

Retrospectives are a must have part of any team and the appropriate time and consideration need to be given to them.

I challenge you to take a look at your own practices in this area and see where you can make improvements.

Get in contact if you need any help or want to brainstorm techniques.

.


Sunday, 11 August 2013 23:42:55 (GMT Daylight Time, UTC+01:00)  #    Comments [0]


# Friday, 12 July 2013

One of the best bits about working in London is the number of restaurants you have at your disposal. Being from Norwich I have pretty much been to every restaurant in the city so it is exciting to be faced with so much choice in London.

My most recent quest has been to find the best steak in London. Luckily, I have a couple of friends who help me indulge in this pleasure and we have been working our way around them.

Part of the experience at the end of a meal is a retrospective on where we think the restaurant rated on the Meek Scale. The scale is based on:

  • Taste
  • Cost
  • Ambience of restaurant
  • Service
  • Portion Size
  • Value for money

Taking all of these into account we rate the restaurant out of 7 and I have formulated my list of favourite restaurants. Being a geek I have not just done this for steak restaurants, but for all restaurants I have visited in the last 15 months I have been in London. As you can imagine it is quite a list Smile

I guess this information would be valuable to the restaurants as I would expect they continually look to improve the experience for the customers and best practice for their staff.

So why do we not do this for the teams we are working with?

Well firstly we would never want to rank teams or have the information used as a stick to beat them. But the concept of holding a team retrospective based on the best practice we see in really high performing Agile teams sounds useful.

At my last client I introduced something called Evolutionary Stages to of the teams. I cannot take sole credit of this as it was initially created by Steve Garnett, however the other RippleRock coaches and I certainly drove it to the next level of adoption.

The concept is a tool that enables teams to self-reflect on where their Agile, development and testing practices are compared to best practice and taking it one level further to the company’s long term goals.

I have written a user experience report on our journey and findings for your enjoyment.

Final Thoughts

Continuous improvement is vital in the tough and changing world that we live in. If organisations are going to continue being profitable and market leading we cannot afford to rest on our laurels. We need to be continually thinking about evolving ways of working.

Evolutionary Stages is a great tool to help you focus on team and organisational practices, tracking from start to the end point of your journey. We often forget about our starting point and fail to celebrate our successes along the way. Let’s stop and celebrate what we have achieved.

If you happened to be interested in my list of ratings for restaurants I have visited – then drop me a line and I will send it to you Smile

.


Friday, 12 July 2013 09:39:58 (GMT Daylight Time, UTC+01:00)  #    Comments [0]