My personal writing project - Agile in it.

 I have a personal project. I am writing a book. One evening I discussed with a colleague and suddenly I realized that I am utilizing Agile development practices in my writing. 

Continuous improvement. I am not a professional writer. I write as best I can. While writing I am improving all the time. In one writer training I participated we did read out lout what we had written and we gave feedback for each other. That is our Retrospective meeting. Our teacher gives us improvement ideas and some of us rewrite our stories. 

T-shape competencies. Self-development has always been important for me personally. I have tried to find writer trainings to participate and I haven't restricted myself for trainings for novelists. I am also interested in poetry. Writing prose is hopefully some day my main competence but I do hope to have some competence in other area of literature.

Incremental development. When I started my writer training last Autumn I had couple of ideas for books. I have written small chapters for each of them and based on both feedback and my own judgement I have either continued or decided to leave that chapter out. Each chapter is a minimum viable product, an incremental part of possible book. Readable as it own but hopefully some day part of my book. 

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.