The most important meeting - Retrospective

In my opinion Retrospective meeting is the most important meeting to have with any team. And it is the meeting some teams think they can skip. I have been asked "can we skip Retrospective this time as we are busy with ...?" or "Do we have to have these retrospective meetings, can't we just concentrate on working?"

I do understand teams when there is no value added in these meetings. And I feel it is my responsibility as Scrum Master to make them value adding meetings where people want to join and give their input how team should and could improve. I don't want sit in the meeting which doesn't offer anything to me or to my team.

I don't understand though when team is telling me that they have nothing to improve anymore so they can skip these meetings. I wasn't Scrum Master at that time - I was Agile Coach for several teams and their Scrum Masters and Product Owners when this happened. One Product Owner in all his honesty told me that the team is doing so great that they simply don't have anything to improve. They can from now on skip these meetings and by the way, they can skip some other meetings as well. Why to spend time for planning together when Product Owner can plan behalf of the team together with Business Analyst. Team can concentrate on the real work.

Immediate thought in my head was "I would like to facilitate your Retrospective meeting!" In my opinion almost all challenges team faces can be worked in Retrospective meetings. Impediments are something to solve throughout Sprints but other kind of challenges  I'd leave for Retrospective. I struggled a lot in that situation: should I let the team to have their way or should I act. In the end I discussed with Product Owner and let the team to decide. Unfortunately I left the company quite soon after that event so I don't know what happened.

I like to keep my teams on their toes and I vary a lot how we do our Retrospectives. Personally I hate when things are repeated the same way again and again. Before each Retrospective I look back and think do I have something special in my mind - kind of theme to handle - or do I want team to give topics to discuss. Then I decide how I facilitate the Retrospective: which tools or techniques to use - that is always my first decision to make before any Retrospective meeting. Sometimes I change my mind just before meetings starts and improvise.

I search inspiration from books and internet. Lately I have created my own techniques and I have experimented lot of different techniques. My challenge is to work with distributed team and I facilitate online Retrospectives. I hope there would be more material on how to facilitate online Retrospective or any other online meetings. Extra challenge in my current environment is that I am not  able to utilise what ever applications or online services. I have to figure out my own ways. I have to adjust and use what I have and improvise. That keeps me on my toes as well.

Quite many Scrum Masters in my unit are facilitating their Retrospective meetings in the same way every time. I have been told that teams don't like to vary or they themselves believe that it is the most efficient way not to vary. Some have told that they have planned to change but then they end up to have it in the same way as they didn't figure out what else to do. Sometimes I can't help myself thinking how could I help my colleagues to go beyond their comfort zone and try something new, something different - do an experiment and learn from it. Some of my colleagues are so busy "with the real work" that they don't find time to look for inspiration and plan something different.

Note to myself: I need help my colleagues!

Me, myself and I in the team

It is not once or twice I have been in Sprint Review or Sprint Retrospective meeting where someone has said big smile in his face "I did all my stuff!" when more than half of Sprint Backlog items were not completed. Or in the middle of the Sprint one morning in Daily meeting someone has said "I have completed all my issues, can I pick up something new from Product Backlog?" while others struggle with work they have picked up.

The whole concept "working as a team" is difficult for those who have been rewarded throughout their career for their own contribution. It has been important to be better than others to get promotions and pay raise. And there are always people who simply not are team player. It is all about "Me, myself and I" instead of "we".

It must be awful to be allocated in Scrum team if you don't consider yourself as a team player. One might be wondering why I need to plan my work with others, why I need to tell anyone what I am doing as long I get it done. I might have been one of those long time ago. I haven't been devoted Agilist always.

When I first time ever heard about Agile development my first thought was "it is not going to fly". At that point of time I worked as requirement engineer and when now looking back I thought me and my colleagues to be the most important part of any development as we were the ones telling what need to be done. Few years later I started to work as tester and had another brilliant idea: I am the most important as I am the last barrier and prevent all the bugs going into production.

About seven years ago I started see things from different perspective. Why we don't work together? I started look into Agile framework and found out there are other ways. We can build teams who has all the needed skills and people work together. It took long time for myself to change my thinking but I feel I needed that long journey.

It is no surprise that if teams are formed and they are told "you are now Agile team", they don't know what is coming. It should have been me explaining and helping them in their journey. Everytime someone said "I did all my stuff" I should have understood I haven't done my part, not yet.

Great teamwork starts with people and practices. It simply isn't enough to say "you are a team". What does it mean to work together as a team? What are good practices to introduce to a new team?

When I started to write this post, I had totally something else in my mind than what I have written here. While writing I had time to think, rethink, and reflect and I ended up to conclusion I haven't been very good Scrum Master or Coach. I haven't really considered the background of team members, the environment or the organisation around the team. I have just been thinking selfishly how stupid these people are when they don't see the value of teamwork.

Why McPhee

When I started with team V, they were just starting their Scrum Journey. They had worked in Kanban mode and all the sudden they were expected to be a Scrum Team. I had the pleasure to help them in their journey from the very beginning and not all steps had been so fluent. After  half a year I had feeling we are not improving fast enough. There were pressure and expectations outside from the team. As usual I found myself to be the reason for that. I felt I haven't been expecting enough from the team, maybe even done too much on behalf of them.

I decided write a letter to the team. I considered different approaches and any of them didn't feel right. Then I got an idea: I write them letter from Soikka McPhee. I am used to work with teams who are either just starting or struggling with their Agile Journey. I don't say I felt being not wanted but somehow I saw that Nanny McPhee and her way of working were a match and immediately got  many ideas how to utilize Nanny McPhee's philosophy. 

So I wrote a letter about our journey, what kind of challenges we had face and what is there to come and signed it "Soikka McPhee".

Those who have seen Nanny McPhee movies  hopefully remember that in both movies Nanny had 5 lessons to teach.

In the first movie "Nanny McPhee" Nanny went to the Brown household to tame Mr Brown's seven bad-manner children. Her five lessons to teach were:

1. They will learn how to say "please" and "thank you"
2. They will do as they are told
3. They will learn to dress on their own
4. They will learn to listen (I am not sure whether this lesson was more for the father than for children)
5. They will be prepared to face the consequences of one's actions.

From these five lessons I couldn't easily formulate my own five lessons to teach or didn't really found any similarities what I have taught for earlier teams I've worked with. 

In the second movie "Nanny McPhee and the Big Bang" Nanny went to a farm to help a harried young mother who was trying to run the family farm while her husband was away at war. Nanny taught farmer's children and their two spoiled cousins five new lessons.

1. Stop fighting
2. Share nicely
3. Help each other
4. Be brave
5. Have faith

In these five new lessons I can more easily formulate my own lessons to teach but I am not quite there yet. With help of my ex-colleague I have started to rephrase the five lessons I as Scrum Master want to teach to my team considering all the previous teams and what I have taught to them. I can't wait my next letter to the team V explaining what are the lessons I want to teach them.

I want to look back and gather lessons from the past. I have myself learned a lot during these recent years when I have been working as Scrum Master or as Agile Coach. How have my own lessons evolved during these years? Teams have been different in many ways and tricks which have worked with one team have been doomed to fail with another team. 

These lessons, learnings and stories I want to share and this is why I now start this blog. I hope there is even one person who can get something for himself by reading my posts.