Ok, after more than 2 years of studying Lean and Agile and a little over 1 year since I got my Scrum Master certification, I am finally a Scrum Master (albeit part time) in a project.  I haven't got full control of the scrum process and I wasn't Scrum Master from the start (I was on leave when the project started) but it is a start and there have been and still are a few challenges.

Last Friday I did my second retrospective and I tried to do one of my own making this time.

After a successful showcase the day before (It was the only time we could get all the stakeholders together – so we had a 9 day sprint) I didn't want to focus on the success. Unlike most projects I've worked on, when something is successful – we tend to focus on the successes and the failures and problems get shoved under the rug. This time I wanted to make them front and center.

So, with the sprint report in hand showing a big cliff after 5 days of work, and buttering everyone up with doughnuts we went to work.

The question became "How can be make a sprint more linear in execution instead of the cliff we had?" This became the guideline for the retrospective, but what I was really after was any problems.

I had 3 rules for the Retrospective.

2. No one can have a doughnut until they bring up a problem. This was to firstly give everyone an incentive to speak up. Doughnuts can be good incentives – except for those who are looking out for what they eat – but they still got involved.
4. No Blaming, finger pointing. I don't want anything said to be held against anyone else.
6. No excuses. I don't care there were BAU issues during the sprint.

The first step was to get a list of problems, issues, anything that you hated and anything that you think prevented you from completing stories in a linear fashion. We did this for the first 15 minutes.

Next we identified any duplicates and prioritized the first 5 problems.

The final step was to go through each of the 5 problems and work out the "Why?" the problem occurred. "How?" we can overcome the problem and finally any "Action" that needs to be done.

The board was broken up as follows.

In the Problem section, I inserted the first of the 5 problems.

In the Why, the team then brought up reasons for the problem with me prompting to drill down. I was trying to use the 5 why's technique to get to the root causes. I probably didn't do so well, as there was many root causes, but it is still early days experience wise for me.

In the How section, we brought up contingencies and countermeasures for the causes of the problems.

Finally in the Actions section, we bought up actions for the Scrum Master, Product Owner and Team Members either collectively or individually to do something. These were not assigned, but members decided to take responsibility for the actions.

I think the whole process went fairly well with the only problem that we went overtime by about 10 min. (From 1.5 hours time-boxed for the retro because it was a 2 week sprint).

The reason I liked this type of retrospective was that it actually focused the team on individual issues and problems that "they" found and had issue with. The sprint report gave focus  as to what was wrong rather than pie in the sky thinking.  Now we see what we can do about it in the next sprint.

As a personal note – Implementing Scrum is hard. Especially when you are doing it the first time and have no idea what you are doing, even after studying it for so long. I have this mental model in my head of what a Scrum sprint should look like and we have varied wildly from that. I'm not going to take this as a sign that Scrum doesn't work – but as a sign that I'm doing something wrong, which I know I am. I feel that my job now is to reign in the bad practices and try to introduce good practices as I understand them in gradually. For those practices that I don't quite understand, try something and see if it works while still staying to the scrum framework.

Once everything is reigned in, then start taking stats more seriously and be more aggressive in our improvements.

At least that is my thinking – which is going to be hard with a 4 sprint project. But who knows, it might help with BAU work in the future after this project.