Do you fit into your role?

Scrum Guide defines different roles in Agile Team but not everyone read Scrum Guide.  Indeed, I have met Scrum Masters and Product Owners who haven't had any idea what is expected from them or do they fit into their role. Some of them have been nominated into that role, some of them have themselves wanted to take that role but with their own interpretation of role and some have taken the role thinking it is their next step in their career.

Once I interviewed candidates for Scrum Master position. I asked candidates what would make them great Scrum Masters and I was amazed how many people thought Scrum Master to be a team leader or supervisor. 

"I know each team member competence so it is easy for me to make sure right people are doing right things."

"I am really good at making progress reports and I know I can make people deliver more."

"You can trust me. I will supervise the team to be the best team."

I have seen how role of Scrum Master have been given to a person who was the most silent team member. Or to a person who wasn't respected at all in the team. I have seen people leaving the role as it was totally something they thought it to be. I have seen people staying in their role even it wasn't any fit for their personality. I have seen Scrum Masters who didn't act like one but made sure that as many as possible outside the team knew that they were Scrum Masters  - it was all about them!

Product Owners are no different story. How can you succeed in your role when you don't have any clue what that role is?  Quite often I have seen people thrown into the role with statement "it is just a minor thing you do - so don't worry, it won't take a lot of your time". What an understatement! 

In my opinion role of Product Owner is even more misunderstood than Scrum Master. Also more often they have been confused what is expected from them. Some of them have been surprised that they are needed more often than in Planning and Review meetings. 

"I don't have time for team members questions. Can't they list them and I answer them when I have time?"

"Why I need to participate all these meetings? I already told the team what they should do."

I have seen Product Owners who didn't want to order the backlog because everything was equally important. Or who couldn't say "no" to any request and promised the team to deliver far more than they can based on their capacity.

We should more consider if the person is right fit for the role instead of putting people into these two key role in Scrum just because they are available. And also ask people to consider are they the right fit and make sure they know what they are expected to do in their role. That would benefit all - people would be happier and organisations would get more value. People need to be educated, they deserve the chance to succeed. Scrum is not rocket science but something is good to know when jumping into it!

But world is weird. I found this video which would help me to give right answers in Scrum Master interview. If I ever interview Scrum Masters again I make sure to listen carefully in case the interviewee has been listening this video.

Online Daily meeting

How to have an efficient Daily meeting with distributed team? If only I know the solution I'd be happier Scrum Master. I have faced different challenges with different teams. As  I haven't ever been Scrum Master for colocated team I can only imagine how different that would be if all team members are in the same room standing around board.

Personally I feel that when we have these meetings online it goes more easily on reporting mode. Team V had habit to report in Daily meetings in alphabetical order. So every day mr A started and mr T ended the Daily. In the beginning I thought that it is okay as it is easier for them because I didn't have any ball or stick to throw for next person. It was clear for them and I also learned their voices better even if they didn't say who was talking.

After a while I started to feel anxious and I wanted to change the way we do it. Biggest reason was that team V was divided into three sub-teams who worked on same issues. Meaning that mr A  and mr N were talking about work they did together. After mr A another sub-team members told about their work and then we got back to starting point when it was mr N's turn. So together with team we agreed that each sub-team is talking one after another and then we move to next sub-team.

I didn't like that way either. We really didn't get enough value out of our meetings. One person told what he did and others said "I did the same". Even I knew that it is not the whole truth. They were not all the time working on same issues.

Index cards

So after a while I changed again. I took index cards into use. I wrote team members names in the cards and before the Daily meeting starts I shuffle the deck of index cards and ask people to talk in that specific order. I also make short notes on each card what is going on. I believed that this way when team members don't know when they turn is they focus on the meeting and listen each other.

In past I coached a team which was really creative how they run their Daily meetings online. For example once a week they had "colour day". One team member selected a colour and after all people wearing cloths having that colour had their turn last one selected a new colour. It was fun. 

No big news - I believe - that I now after a while I feel we need to do something else. Even we have been able to start talking about ongoing work and asking support it is still too often team members reporting to me or to Product Owner.

I have added 15 minutes Meet after -session after our Daily meeting and more and more we are utilising those minutes. Those sessions are more like what I would like team to have. Should I stop having Daily meetings as such and agree that we don't report - we discuss ongoing work. Might that end up being disaster like there would be team members who never say anything? Focus would be on the work.

Or is it irrelevant that team is distributed and the real issue is that we don't know how to have efficient Daily meetings? Do we even know what is the purpose of Daily meeting? What if we stop having Daily meetings? What I have done wrong? Should I step out and let the team V find out the way that works best for them? What if I simply stop participating Daily meetings?

I seem to have more questions than answers. Perhaps some answers can be found from this short video.

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.