Some thoughts on trainings

In my whole professional career in IT I have been training others. I am not an educated trainer not do I want to be fulltime trainer but I have always find myself some possibilities to train others. I am more or less self-educated wanna-be trainer but that haven't stop me. 

I have learned that interactive lessons are far better than lectures. I have done many of basic Agile trainings utilizing LEGO®  bricks. And I know I am not the only one playing with legos in Agile trainings. 

Some interesting examples from others

• Lego Simulation Scrum Workhop
• Book "lego4scrum"
  
• Case study "Lego Digital Solutions"

I know quite many have been participating trainings or workshops with lego games. I as a trainer am getting little bit tired for these lego games and I have heard trainees telling the same. After a while we all want something different. 

I haven't been conducting any basic Agile training for long times but if I'd definitely looked for something else. Nowadays, due to Covid-19, everything is happening remotely and for sure lego games wouldn't work really well. All around the world trainers have been looking for different ways to make trainings interactive in remote context. 

I co-facilitated couple of SAFe trainings before I changed job this autumn. Due to restrictions in organization we used MS Teams and  features made available for us. That was challenging but totally possible. It was up to us trainers and participants make these trainings interactive. I don't think it is fair to stay passive and complain afterwards that training should have been classroom training. 

It is totally possible to stay passive also in classroom trainings. In groups there can be someone who makes others do all the work and in worst case (s)he might be the one who complains all the time so that no one enjoy the training. I have meet these people - as well as a trainer and a trainee. And I have to admit - I have been one myself also. 

I have been wondering myself what does it tell about me or the others who are not willing to participate trainings which require interactions with other trainees. In Agile teams, collaboration and cooperation are important. What if you are not able be interactive and cooperate with your colleagues in one training - can you really be a team player. 

Well, of course, there are people who simply hate games. For them these games are the worst nightmare. I have been wondering often what we should do with these guys. Maybe if I had degree in education I would have answer for that question. 

I have never been in training where I wouldn't learned something. Even the facilitation training I hated truly - even from that training I took something with me. Sometimes I feel that people are not taking the responsibility to learn. It is not your trainers fault if you don't learn anything or pass the exam. I so do think taking ownership and responsibility of your own learning is the key. 

Taking ownership, being responsible, collaborating - all that you need when being part of Agile team. No matter whether you follow Scrum or are part of Agile Release Train - you need those actions. If you don't like lego bricks or hate games consider how you can contribute and don't be the stick in the mud. 

Is it Done or Done-Done

Quite often I have discussed with teams whether something is Done or not. Is it Done or really Done, which we call Done-Done. I know I am not the only one struggling with this. 

There have been different reasons for this discussion.

"We don't have any QA in our team." >> Sounds pretty much similar to discussion I once had with one developer. He told me he doesn't need to unit test his code because we have a tester in our team and he can't do her job. Can't or won't? 

>> Also reminds me that in some teams they had historically, before starting to follow Scrum, done so that business experts had tested what ever they had done. Situation changed when the team were forced to start use Scrum board and practices. None of our backlog items were completed during the Sprint because business experts were not available. Even after we tried to discuss with them about schedules and dates.

"We develop in this Sprint and testers test in next Sprint." >> Same team didn't want include testing effort in estimations. They also wanted to close development issues and create new one only for testing. Because testing is not part of coding. They also considered refinement is not a team activity - it is job for business analyst. 

Why I still see teams who consider testing being something happening outside of the team, someone else testing somewhere where developers and testers don't ever meet? I am - also - certified trainer for course "Whole Team Approach for Agile Testing" and I feel really sad when teams don't see the key point - it is team's responsibility.

Today I wrote kind of poem for this. This I will share with my current teams and stakeholders at some point. 

Is it Done or is it Done-Done - that is the question:

Whether it required to be tested

Whether it is enough when developers tested

Whether we prefer manual testers to be involved

Is it Done or is it Done-Done - that is the question:

Whether we have build quality in 

Is Product Owner interested in

Does Customer want fix quickly in

Is it Done or is it Done-Done - this is the answer:

Well-functioning agile teams don’t need two concepts - Done and Done-Done

A PBI is a complete slice of product functionality, 

One that has been designed, built, integrated, tested, and documented 

And will deliver validated customer value

By the book

While reading book Coaching Agile Teams (by Lyssa Adkins) I got first time ever introduced to Shu-Ha-Ri. How your style as Agile Coach or Scrum Master changes with the team as the team move between Shu, Ha, and Ri. 

(source: https://www.kimusubiaikido.com/blog/meaning-shu-ha-ri)

Shu Ha Ri is a term the Japanese use to describe the overall progression of martial arts training, as well as the lifelong relationship the student will enjoy with his or her instructor.

Shu can either mean "to protect" or "to obey." The dual meaning of the term is aptly descriptive of the relationship between a martial arts student and teacher in the student's early stages, which can be likened to the relationship of a parent and child. The student should absorb all the teacher imparts, be eager to learn and willing to accept all correction and constructive criticism. The teacher must guard the student in the sense of watching out for his or her interests and nurturing and encouraging his or her progress, much as a parent guards a child through its growing years. Shu stresses basics in an uncompromising fashion so the student has a solid foundation for future learning, and all students perform techniques in identical fashion, even though their personalities, body structure, age, and abilities all differ.

Ha is another term with an appropriate double meaning: "to break free" or "to frustrate." Sometime after the student reaches dan (black belt) level, he or she will begin to break free in two ways. In terms of technique, the student will break free of the fundamentals and begin to apply the principles acquired from the practice of basics in new, freer, and more imaginative ways. The student's individuality will begin to emerge in the way he or she performs techniques. At a deeper level, he or she will also break free of the rigid instruction of the teacher and begin to question and discover more through personal experience. This can be a time of frustration for the teacher, as the student's journey of discovery leads to countless questions beginning with "Why..." At the Ha stage, the relationship between student and teacher is similar to that of a parent and an adult child; the teacher is a master of the art. and the student may now be an instructor to the others.

Ri is the stage at which the student, now a kodansha (high ranking black belt), separates from the instructor having absorbed all that he or she can learn from them. This is not to say that the student and teacher are no longer associated. Actually, quite the opposite should be true; they should now have a stronger bond than ever before, much as a grandparent does with their son or daughter who is now also a parent. Although the student is now fully independent, he treasures the wisdom and patient counsel of the teacher and there is a richness to their relationship that comes through their shared experiences. But the student is now learning and progressing more through self-discovery than by instruction and can give outlet to his or her own creative impulses. The student's techniques will bear the imprint of his or her own personality and character. Ri, too, has a dual meaning, the second part of which is "to set free" As much as the student now seeks independence from the teacher, the instructor likewise must set the student free.

Shu Ha Ri is not a linear progression. It is more akin to concentric circles, so that there is Shu within Ha and both Shu and Ha within Ri. Thus, the fundamentals remain constant; only the application of them and the subtleties of their execution change as the student progresses and his or her own personality begins to flavor the techniques performed. Similarly, the student and teacher are always bound together by their close relationship and the knowledge, experience, culture, and tradition shared between them. Ultimately, Shu Ha Ri should result in the student surpassing the master, both in knowledge and skill. This is the source of improvement for the art as a whole. If the student never surpasses his master, then the art will stagnate, at best. If the student never achieves the master's ability, the art will deteriorate. But, if the student can assimilate all that the master can impart and then progress to even higher levels of advancement, the art will continually improve and flourish. 

I have often introduced this concept to the teams by explaining it shortly

• Shu - Follow the rule
• Ha - Break the rule
• Ri - Be the rule

I want to introduce this concept to the teams to make them realize that in the beginning of their journey, when they don't know so much and they don't have experience in Agile ways of working, it is better to follow the rules so that they learn how to do things "by the book". I know there is no way to do everything by the book or it doesn't make any sense trying to fit all teams into one way of doing things. My role as a Scrum Master or an Agile Coach is to teach. 

As the team grows and matures we start breaking the rules. It usually happens quickly. We might stay in state or Shu in some areas and in some other areas we step into Ha. That is when I move more into coaching mode. I don't anymore teach and tell what to do but I help teams to find their adoption of the rules. Teaching has had its place but the longer I stay in teaching mode the longer teams rely on me. But as said I might in some areas stay in teaching mode -  e.g. when I think team benefits from me introducing some new practices. 

And finally teams reach level of Ri. They create their own rules. 

All teams go through these stages whether they realize it or not. But it is not only teams who have these stages. Scrum Masters and Agile Coaches can see themselves going through similarly these stages. All of us start from scratch. We start learning and in the beginning our only option is to follow the rule: what ever we read or learn - we follow that. After a while we realize that not everything can fit into these rule. We start bending the rules and experimenting. Only the real gurus - in my honest opinion - can say they have reached Ri. 

I myself have seen this happening with myself. When I started I didn't know anything about Agile or how to coach teams. But I have learned throughout the way. In some areas I am more matured and in some others I am in the beginning of my learning path. 

When I first time read Lyssa's book I draw one pagers for each part of the book and in third part "Getting more for yourself" I draw the actions in my journey becoming an Agile Coach. I love this book and I am getting back to it time to time. I have a look these one pagers and if needed, I open the book and refresh my memory. 

I sometimes have seen how team or organization get stuck in Shu. They keep repeating "we have to follow the rule" and are afraid to take the next step and start adjusting. I have been wondering what might be the reason for that kind of habit. One thing which come to my mind is the maturity of the leaders. It can be Scrum Master who is afraid to let the team to take next steps. It can be the competence level or insecurity of  Scrum Master, Agile Coach or leader. If they are not confident themselves they don't know how to reach the next level. 

I have also heard when a person in higher position in an organization said "we have to follow the book or otherwise we are doomed". I couldn't help myself thinking if that person have any trust on the people doing the actual work. If we don't have trust on people we don't have anything. Even in that case teams and most of people were ready to take next steps but as they were forced to follow the guidance they kept doing things by the book and lost the opportunity to grow and mature even more. 

Staying too long in this "by the book" mode we restrict ourselves getting more for ourselves, teams and organizations. 

Communities

I am strong believer of communities. Whether you call it Community of Practice or Competence Network or Learning Network - there are elements of learning from each other, sharing with each other and social networking. 

I am a social person. I like to be close to my colleagues. I like to share my experiences and thoughts with others and likewise I love to hear from others about their experiences and their thoughts. What are the things to try, what are the learnings, what are my challenges, what are their challenges. Good long discussions in matters where we don't all agree and share our viewpoints and opinions. Place where it is okay to disagree and have tough discussions. 

While working as Agile Coach I utilized Scrum Master CoP for coaching sessions. Especially I remember our sessions where we discussed Scrum Values. All Scrum Masters had their first ever position and all teams had just started their Agile Journey. Personally I believe we need to understand principles and values in order to be able to be really Agile. Otherwise we just blindly repeat instructions given for us. 

The Scrum Guide lists five values that all Scrum teams share: commitment, courage, focus, openness, and respect. While discussing I learned so much about each individual. I saw how some of them struggled with these values. We worked in environment where they were not used to be open. Openness instead of hiding problems and issues until the very last moment to be told. That was maybe the most difficult journey they had to take. For me it was important to have these discussions with them

In my Scrum Master positions throughout the years I have participated many Scrum Master communities. When I am there as Scrum Master I feel much more comfortable as then I am one of them. I don't have to be anything else than myself - not a coach or a trainer who knows more. I can ask all the stupid questions or share all my concerns knowing that others are as curious as I am, that they want learn and share. Sharing is caring!

But it is not only learning aspect which make me want to be part of these communities. The social aspect, building relationships, sharing your feelings, getting peer support - all that is very important for me. I don't wanna be alone. I want colleagues around me. 

Today I had meeting with my current colleagues who are soon to be my ex-colleagues. I leave my current position and soon, after a short break, I start new adventure in totally different environment BUT all alone. I don't have any Scrum Master colleagues. Or I do kind of have. Those two guys who I am replacing as they concentrate on their other roles in their teams. I for sure will miss my colleagues and today they really surprised me by sharing their "one words" with me. This kind of community is one of the best. Not because they obviously appreciate me but because we care for each other. 

Reminder for me today is showing your appreciation. Not only when someone is leaving but in your daily life. Even when life is hard you can still find something good in everyone and boost others just by saying "well done". At least for me that brings some joy to myself also. 

Communities are not only for learning and sharing - there are also for caring.  

Talk, don't report!

English is not my native language. Even though I think I am pretty good in English I have my weak points. One of them is my ability to handle numbers. For some odd reason it takes time for me to translate in my head numbers from English to Finnish. And other way around - when I talk, I always think numbers in Finnish and translate them in my head into English. 

But at the same time when this is my weak point I can utilize it. Quite often when I have started to work with new Scrum Team I have noticed in Daily meetings team members are not talking what they are working. 

Instead of telling "I have started building database connection. I discussed with system team and we found out that ..." I hear "I continue with JIRA-123". 

Instead of "I have deployed code to test environment. All unit tests passed and this change can be tested further as soon as we have a connection to external test environment" I hear "JIRA-223 is now ready to be tested."

Every time when I ask them to start talking instead of reporting I hear WHY. Quite often team members have been totally fine with this approach and don't understand why they should be telling anything more than JIRA issue id. So, I have learned - I don't ask them talk or stop to report. I just ask them to stop using numbers and explain them why it is difficult for me to understand what it is going on. In the beginning they change they way of talking in daily to make me, their Scrum Master, happier but in the long run they have noticed and mentioned sometime later during Retrospective that actually Daily meetings give more value to them with this habit. Amazing! Specifically I remember how I struggled with teamV and how quickly they learned not to use numbers and if I ever referred something with JIRA issue id team reminded me all together "NO NUMBERS!"

Another antipattern I have seen with teams is to utilize JIRA board during meeting in the way that only those team members talk who have issues assigned to them. When Daily meeting starts team member who is assigned to top issue In Progress tells what he has been doing. In that way they have run through In Progress issues - only persons talking are the ones to whom issues are assigned. 

This happened also when I joined teamG. After a few Daily meetings I realized that there are many team members who don't ever say anything during the meeting. JIRA as tool allows issues to be assigned only one person at the time. Especially our business experts and qa specialist worked in pairs and also often issues were assigned to developers. They got totally surprised when I one morning said:

"Today we do this differently. I have this ball here. I now throw the ball and the one who catch it start talking. When you are ready you throw the ball the next one."

Silence. Then the person with ball said "I don't anything assigned to me in the board." 

"BINGO! Exactly. You don't have anything assigned to you but we are interested to hear what you have been doing, what you plan to do and is there anything preventing you to do so."

This was beginning for something amazing. This team started to talk and we started to get things done quicker, we found out impediments faster and team members started to support each other much more than earlier.  The impact was even bigger I ever imagined when introducing this practice to the team. 

Daily meeting is not a status meeting. Team members are not reporting anything to me. Daily meeting is the possibility to share and learn. When I hear any team member saying "I don't have anything to report" I put note to myself in my notebook. Next time I have 1:1 meeting with that team member I take this up and explain what is the purpose of the meeting and why they should never consider to be obligated report anything to me. 

 

 

How you fulfill your days?

Most of my friends don't work in IT. Therefor it is some time difficult explain what I do as a Scrum Master. And when tell about my daily work some of them say "so you are kind of a project manager".  What can you say?

Usually we don't talk so much work when I am with friends. We all have so different jobs and free time is not for talking about job. 

But some time ago I met a new person and we started discuss what it is we do beside having dogs of same breed. And when I told that I am a Scrum Master she suddenly said "so am I". For a short moment I was happy: finally someone who knows what I do. But then she continued "What else do you do?"

"What do you mean? I am full time Scrum Master." She looked, honestly, surprised and told that she has double role and in her company there is no full time Scrum Masters. 

Of course, I reflected after that discussion what it is that makes it possible for me work full time Scrum Master. What are my days like? How do I fulfill my days? What is my daily agenda?

First of all, I am perhaps little bit over-organized. I like to-do lists, I keep notes, I write down things. I feel more confident when having my notes with me. I always have my note book and pen with me. I feel naked without them. I am almost like addicted.

When I start planning next PI (Program Increment), 

first thing I do is write down Iterations time line. 

That helps me in planning coming 12-14 weeks. 

If SAFe terminology is not familiar to you, visit Scaled Agile Framework home page. 

Before each meeting I check what we have in agenda, is there anything I need prepare or any other action I should take. All my meetings have clear agenda and goal. I ask people to read my invitations. I want them to be ready as well. Efficient meetings in planned timebox are another addiction of mine.

I follow our team progress in JIRA by using different dashboards. At the same time I love and hate metrics. I am always careful what do I show to the teams. Not all metrics are our friends and almost everything can be misused or misread. So I don't spend so much time daily basis with metrics but I am on the top of them. From time to time I evaluate whether I should change something and try out different ways to show data. Data is our friend when used correctly.

I follow what is going on and if needed, I intervene. I participate meetings team members have and try to get on the top of the discussions and issues we face. I want people outside the team get to know me so that they more willingly contact me. 

I talk and chat with team members. I am currently in team where all team members are distributed in five different countries. Even without Covid-19 I wouldn't see them during work days. I try to be available for their questions. I have bi-weekly 15 minute one-on-one discussions with all team members. I build trust, I share, I care. 

I discuss or char with my Scrum Master colleagues. I currently have three Scrum Master colleagues and even I do not daily basis discuss with all of them I am in contact at least with one of them daily. That is even more important in this set-up when it is not possible to meet face-to-face. I am always available if they have anything to ask or discuss. I always reach them if I have something. I believe sharing is caring and this way we can support each other and learn while doing that. 

I have daily focus topics in my calendar. If there is any free time - like there is slot or two in normal days - I focus on one specific topic. There are different topics. For example days when we have Backlog Refinement meetings I focus on refinement. I might look for ideas how to split stories. There is always something to learn and things to try out with team. Extremely important for me as Scrum Master put focus both on my own development and team's improvement. 

I want team to have fun. People do matter and I want them to enjoy their work days. I spend some time to figure out something fun to do with them. Not daily, but quite often. It is not a big job to find out some funny pictures, funny stories to share or similar. Using music in meetings and showing videos. Little bit more challenging in remote context but achievable. I just need to be more creative than when team is colocated.

For me being Scrum Master means that I do not do anything team members themselves can do. My job is mostly invisible for them and also for others around the team. And I honestly believe that is how it should be. I am suppose to be the non-visible person behind the team. 

Do we need Scrum Masters?

I trained Scrum Master course with 2 colleagues. In the course we had people who worked as Scrum Masters, wannabe Scrum Masters, and people who were there because their managers told them to participate. 

In the very beginning of the course one trainee asked a question. "Do we need Scrum Masters? I have been in teams where we have been having different Scrum Masters over the time and sometimes we have been without Scrum Master as no replacement yet found. I haven't seen any difference in teams deliveries whether we had Scrum Master or not. So why do we need Scrum Masters? Isn't that kind of redundant role in this organization?"

I can only guess what our wannabe Scrum Masters were thinking when someone is saying out loud that this role is not needed in our organization. Maybe they saw scissors which will cut the role of. Maybe they thought that this question was absurd. Maybe someone thought person asking that question is here because her manager forced. 

None of trainees already having this role said anything. Maybe their just wanted to hear what we trainers reply. 

This wasn't first time I saw this kind of thinking. 

There was a need to cut off people in one organization and Scrum Masters were as a group suggested as they don't deliver any value like developers do. In that case managers who had this attitude were asked have they considered what will happen if there is no one guiding the team, and making sure collaboration between teams happens. Who support Product Owners? Are ýou sure teams can deliver more without Scrum Masters? In the end no Scrum Masters were kicked out. 

Another case from different point of view was a Scrum Master who said she doesn't understand the noise we have about finding right people to be Scrum Masters. And why we say persons taking the role should used at least 50 % of  her working time for Scrum Master work. I asked why she thought so. "Because I don't use so much time. It is 15 minute Daily every morning and then Review, Retrospective and Planning every third week. I might spend some time planning the Retrospective but otherwise I don't have to spend any more time than what is needed to facilitate these meetings." 

Even after taking Scrum Master course she didn't change her view for the role. Luckily she didn't have to continue for long time until we found better fitting person for the team to be a Scrum Master.
Definitely she was clever and hard working lady but she wasn't a fit for the role. 

Getting back to the question. Me and my co-trainer said that we will get back to her concern throughout the course and we hope that she and others in training learn why we see Scrum Master to be important in Agile teams. Teams for sure can survive without the Scrum Master but if the job is well done it is beneficial and teams deliver more value but also this role can be done so that it doesn't make any difference. So, in the end, it is Scrum Master herself who makes it valuable. It is up to you do you make the difference or not.  

One reason for me to be happy Scrum Master is to be able to make the difference, help the team to make the difference. In the end, it is not about me, it is about the team. 

People do matter

Long time without blog posts. Covid-19 gave me more free time but I did use it to do something else than writing this blog. I have gathering long list of topics and promised to myself now start again this blog. So I consider this blog had a extra long Covid-19 break and now it is time to go live again. 

One thing which has been on mind is the simple truth that people do matter. In these days we should ask from our colleagues and friends "are you safe", "is your family safe", "how are you". Small questions which can make the big difference. It shows that you care. 

For me people do matter. I like to consider myself as people person. I also have been told to be a people person. I believe that is the biggest reason why I enjoy being Scrum Master. I always have a team which I can serve. People who I can support. People who I work with. People around me, working with me, having fun with me. 

Maybe I am little bit naive when believing Agile is anthropocentric framework. Agile manifesto states "we value individuals and interactions over processes and tools". It is people who who respond to business needs and drive the development process. I have too many times witnessed how focus have been put on processes and tools and people are considered resources. It should be the other way around. We should have focus on individuals and even processes and tools are important I consider them being resources we need to do our job. 

Source: Van Haren Publishing

There are 12 principles behind these values. People, individuals are also mentioned in these principles. One of them is specifically about motivated individuals.  

Build projects around motivated individuals.

Give them the environment and support they need,

and trust them to get the job done.

Motivated people, motivated teams are more likely to deliver their best. We need to support, trust and motivate our people. People have deserved that. I trust my team members to give their ultimate best.  For me the most important thing is that people in my team feel appreciated. I love to give feedback for work well done. I am not afraid to have difficult discussions with my team member. I also believe that people have deserved to have possibility to improve if something isn't going so well. I do understand that we all have better days and bad days. Our contribution may vary from day to day. We are humans, we are not resources. 

I have myself learned during these years that fear is not good motivator. No one get motivation from public humiliation. Unfortunately I have seen during my career so many managers who think they can do what ever they like - just because they are managers. I had a manager long time ago who had "Friday Afternoon coffee" with his team and he always announced who has done the biggest mistake during that week. Really! Friday afternoon - just before people start their weekend. It was so odd. 

Likewise I have had managers who have shouted and even made people cry. What does that kind of behavior tell about the manager? Can't help myself thinking Peter Principle - a concept in management developed by Laurence J. Peter, which observes that people in a hierarchy tend to rise to their “level of incompetence”: an employee is promoted based on their success in previous jobs until they reach a level at which they are no longer competent, as skills in one job do not necessarily translate to another.

Source: https://www.lanredahunsi.com/the-peter-principle/ 

Scrum Master rotation

Stable teams - that is the guideline. Is Scrum Master part of the stable team? Can you rotate Scrum Masters from one team to another? Or can you rotate Scrum Master inside the team?

Interesting questions. Personally I believe teams need to have dedicated Scrum Masters and it is not a good idea to rotate Scrum Master inside the team so that team members in turns act as Scrum Master. If team is mature and don't actually even need dedicated Scrum Master - maybe. But for sure for teams which are struggling with daily practices - not a good option.

On the other hand I have met many Scrum Masters who don't even want to consider option to leave the team. Some of them are in their comfort zone. They have said to me something like

"I have finally got this team functioning well and I don't want to start from the beginning with some other team."

"I have so much fun with this team. I don't want to leave them."

The last is true with me also. I had so much fun with team SP that I almost broke my heart when I decided to leave them.  But I knew it was time move forward. I needed to find another team who I could coach and teach new tricks. Team SP had matured a lot and they were ready to have new Scrum Master with new ideas.

I actually believe that from time to time it is good to rotate Scrum Masters. Each and every Scrum Master is his/her own personality. All of us have read the same Scrum Guide but each and everyone of us have our own way to do things. Even if we do everything by the book we are still different. Some teams might feel irritated if their Scrum Master is switch. They might thing that their team is so well-functioning that they don't want anyone else to come and mess up their work.

But for sure something has to change. Otherwise the whole idea of rotating Scrum Masters is pointless. Even the most well-functioning teams could learn something new. And the most well-functioning teams can actually teach something to new Scrum Master as well. Rotating Scrum Masters is, in the best case, win-win situation for both teams and Scrum Masters.

Why do I take this up now? Well, our RTE (Release Train Engineer) announced this week that from the beginning of next PI (Program Increment) there is Scrum Master rotation for almost all teams. "Musical chairs" as one team don't get (note: I consider them to loser team) new Scrum Master. Even I feel I would have so much to work with team V I am also extremely excited to have possibility to start working with new team G and new Product Owner. Time to look back to Scrum Guide and consider What is a Scrum Master. Have a new start. Wau!

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.