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

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. 

 

 

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!

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.

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.