Toyota Retrospectives

The retrospective is to me the heartbeat of Scrum. If you get that right everything else will work out fine over time. Because the retro is based on the idea of Kaizen as part of the Toyota Production System and the principle of continuous improvement, I believe it is helpful to look at some of the other ideas laid out in The Toyota Way, and how those ideas can (and should) be brought to bear in Scrum, and how Kaizen embodies all of them under one umbrella term.

Hansei is an aspect of Kaizen which is critical to success. Hansei means “self-reflection,” and in Japanese culture it means to acknowledge your own mistake and pledge improvement. Without the idea of Hansei, a retrospective can become focused on all the things outside of the control of the team and team members to address. There are substantial gains to be made by the practice of Hansei. Most spiritual and religious practices have something similar to this form of self-examination, and it is a wise practice even in the secular world to examine oneself critically and determine where things could be improved.

This is one reason why the Scrum retrospective should be the one absolutely protected ceremony in Scrum. No one but the team should be allowed to participate because it should be a very safe space for Hansei. Especially no managers (who should not even be on the team in the first place).

The retrospective would actually be called Hansei-kai or “reflection meeting,” and it happens every sprint at the end. Even when things have gone very well, maybe even seemingly perfect, there should always be problems to address, or as a Toyota manager would put it, “No problem is a problem!” Because if you objectively and critically evaluate the work, you will either find problems to be dealt with, or it means that you did not stretch to meet or exceed your expected ability.

One of the fourteen main principles of the Toyota Way is to “become a learning organization through relentless reflection (Hansei) and continuous improvement (Kaizen),” and from this perspective, the Scrum retrospective should help drive organizational learning at a team level, and hopefully, the team will also share their findings with other teams to increase their learnings as well.

It is very educational to understand the roots of where the Agile Manifesto and Scrum come from, and the study of the Toyota Way is crucial to that understanding. In fact, there are many more lessons there than are contained in most Agile frameworks and practices today. In other words, I believe we still have a long way to go to catch up with what made Toyota the number one car manufacturer in the history of the world. 

Happy learning!

Standup Status Reports

If your daily standup feels like a status report by each team member to the Scrum Master, the Product Owner or both, there is a very successful technique which I have deployed time and again which quickly solves this. 

The standup really is a planning meeting for the team. It should be a chance for them to focus on what they are going to do, and how they are going to spend their time during the day ahead. Too often it becomes stale when the three questions suggested in the Scrum Guide (What did you do since the last standup? What are you going to do until the next standup? What if anything is getting in your way?) become rote and robotic responses aimed at keeping the Scrum Master or Product Owner off one’s back, with no valuable information being imparted and no plan for the day being developed.

The fix for this is simple and easy to achieve. Let the delivery team run the standup themselves.

By putting this into effect, you will see an immediate change in behavior as the team learns to share useful information with each other. The format of the standup is very likely to change to one where the team is talking about each story which is underway and who is doing what to complete it along with any questions or problems they may have. This is all great behavior and it leads to a valuable standup. 

Here is my technique for making this happen. First off, I make sure that the team gets the message that the standup is their ceremony! It is for them and no one else. The Product Owner is there to listen and answer questions if asked (not to drive their own agenda on stories). The Scrum Master is there to ensure the tight 15 minute time box; that the standup starts on time and ends on time. They are also listening for any impediments that may need action. It is the delivery team who is the primary audience and participant in the standup. It is a planning meeting for them and them only. Once this is known, I set up a speaker rotation schedule, starting with the quietest person on the team as this helps set the tone for the conversation. The quietest is least likely to dominate the conversation and most likely to support actual conversation happening between team members. The most dominant person on the team is last on the list so that by the time it gets to them to facilitate the standup, the culture has been set already. The same team member facilitates the standup for an entire sprint, and then it rotates to the next member and so on. The Product Owner is instructed to speak only if spoken to, and the Scrum Master is instructed to ensure the meeting starts on time (including tracking anyone down who is late or hasn’t shown up) and to call the time once the standup is completed (of course allowing the team to continue any discussion afterwards), and that is it. 

There is more than one reason to try this technique as I am sure you will notice; it can solve a number of problems with standups but the status report problem is the most common one. 

Happy standups! 

Regards, 

Armistral

Naming Teams

It has become a best practice of mine over the years to encourage teams to name themselves. I believe the benefits are many even if they are “soft benefits.” I thought I would list a few of them here for your consideration along with a couple of additional best practices I use when naming teams.

The first and most obvious benefit is esprit de corps (a feeling of pride, fellowship and common loyalty shared by the members of a particular group). When a team has a name, they begin to have an identity, and when a team has control over their own identity, they own it. When a team owns their identity, they create ideals to go along with it; they imbue that collective identity with the values they consider most important, more important than any one member of the group. There is then a built in motivational lever to use to pull the team together or correct a direction taken. They start to feel like a team rather than just a collection of individuals and begin to consider everyone’s welfare and the common outcome of the work rather than just their own.

Another benefit of having a team name is that it helps to persist the team. Teams thrive the longer they stay together. They learn to work better together, more effectively utilizing individual strengths and compensating for weaknesses. Having a team name that is independent of the actual work the team does helps create that sense of identity outside of the work and keeps that identity whole when they move on to new and different kinds of work (which they hopefully do to keep things fresh and challenging, to keep growing). It helps the organization think of them as an independent group that can get things done, many things rather than just one or a few kinds of things. 

Having a team name is humanizing. Think of the difference between the name “Data Access Team” and “Team Zizou” (real life examples) one is almost robotic, the other is interesting and engaging and human. Even if you do not know what it means, it catches your attention; it is fun and the team can get behind it. This also helps the team to build a reputation just like a person gains one through hard work so too can a team, and having a short fun name can encourage those outside of the team to be curious about what the team can do, what challenges they have overcome, what have they accomplished, i.e. what is their track record.

A few simple rules I follow when encouraging a team to name themselves:

* No sports names. This can foster rivalries or challenging feelings for those who may not be interested in sports. 

* Short and sweet, one word names are better just because they roll of the tongue easier (even for people outside the team) and it will be easier to find t-shirts or some kind of swag for the team if you choose to.

* Get the team some swag! Design or find t-shirts or hoodies or mugs, something team members can have with your team name on that nobody else has. It won’t cost much and will be worth it to see that the name is being taken seriously. It will establish the name as something real. 

I hope you are convinced that naming teams is a great idea, and even more so, I hope you try it out!

Regards, 

Armistral

What Is Scrum?

I have been working with Scrum for a long time. I love it for its simple power and its awesome challenges. Before I would ever attempt to explain any of those ideas, I would always start with the most basic idea; what is a scrum team?

After many years, I finally understood that these roles can be explained very succinctly, defined in a way that anyone can understand instantly.

There are only three roles in Scrum and none of them are in charge of the others:

• Product Owner: Responsible for the WHAT, WHY, WHO and some of the WHEN

• Delivery Team Member: Responsible for the HOW and the rest of the WHEN

• Scrum Master: Responsible for the HOW WELL

As with all powerful things, I find that this most basic definition helps people understand the purpose of each of the roles and how they relate, not only to each other, but to the customer and the entire organization around the team.

As to the remaining questions of what does a Scrum Team do and how do they do it, I would simply say:

They are a team of peers. They are partners who collaborate to craft what is most valuable to their customers.

Could it really be any more complex that this? I think not. I have never found anything they do outside of these responsibilities or any purpose beyond what is stated here.

Fear Is The Scrum Killer

After more than a decade now working with Scrum teams in companies from small startups to some of the larger corporations on the planet, I have found that there is one fundamental challenge to Scrum being successfully adopted/implemented, as well as having the truly transformative effects it is capable of for the organization as a whole. That fundamental challenge is fear of change and the fear of being wrong.

If there is one thing that is certain in my experience, Scrum will change your organization. It will change how the people within it view themselves and the work they do, not just how they go about doing it. In many companies I have worked with, there is very good reason to fear Scrum. The best reason is that if it is well executed/adopted, it is going to reveal your organizational problems very quickly and make them visible to everyone who is brave enough to look at them.

Being willing to admit that something is wrong and not working the way it should or could, even if you were the one behind that something, takes guts. 

The heart of Scrum is a change engine. The organizations who embrace this face the idea of continual self-examination and improvement at every level. Inevitably, challenges to changing the status quo, to facing bad decisions or policy or process come up when individuals and teams begin to make real progress. This means it takes real courage to look at what is really going on with you personally and the organization you are a part of. It takes even greater courage to attempt to change the challenging aspects you find without fearing for your reputation, your social standing or even your job security.

Those fears are not unwarranted. I have definitely felt the consequences of even gently, but directly, addressing challenges from workers, managers and executive leaders. Yet in my experience, this is the most necessary work for any Scrum Master to engage in, and by extension, the organization to which they belong thrives and flourishes to the extent Scrum Masters are supported in doing so.

Tobias Mayer recently put it well, “Historically, there has been no role in an organisation quite like this one. And this goes some way to explain why so few can enact the ScrumMaster role in this way. Those that do don't last long. But without those courageous few, brimming with faith for a more humane workplace nothing will ultimately change. And so the few keep trying, looking for cracks in the facade through which to enter, operating in stealth mode as necessary, creating change from the grass roots of an organisation, influencing through compassionate confrontation, leaving no stone unturned.”

Facing these fears whether as a Scrum Master myself, or when teaching new Scrum Masters that “A dead sheepdog is a useless sheepdog,” as Ken Schwaber himself put it, I have been “put down” in more ways than one in my career for speaking truth to power. I am careful to counsel new Scrum Masters that if they do their job to its fullest they will face the same dilemmas sooner or later. When they do, they will have to make their own choices about how to deal with the challenges the teams they love face. I can only encourage them to consider the consequences for themselves and for their organizations, for addressing or avoiding those challenges, those impediments to Scrum’s and more importantly the team’s success. In the end, I would simply say that I would rather be a sheepdog who takes on solving real problems for the team vs. one who stands by while they are ravaged by wolves, and I hope you are too.