How to lead self-managing teams – Book review

To my surprise, there are a lot of parallels between leading self-managing teams and managing beehives.

I recently read a great book called “How To Lead Self-Managing Teams?: A business novel on changing leadership from sheepherding to beekeeping” (affiliate link) by Rini van Solingen. In this novel, the author tells a story about the IT manager Mark, who wants to introduce self-managing teams in his organization to make his life easier. 

During a vacation, the grandfather of Mark tells him how he switched careers from being a shepherd to a beekeeper and what he learned during this journey. Mark realizes that he manages his teams mostly like a shepherd, but he must think and act more like a beekeeper in order to develop self-managing teams.

Let´s outline the most crucial takeaways from this book.

Sheepherding

If you want to develop self-managing teams, then you need to stop treating your people like sheep.

Command and Control

A shepherd tells the sheep exactly in which direction they have to go, where they eat, what they eat and so on. Then he regularly checks on them to make sure everything is the way he expects it to be.

Similarly, traditional managers often tell their people exactly what to do and maybe even how to do it. Then they ask for constant status updates and results.

So they follow a command and control pattern. They tell their “sheep” what to do and check up on them regularly.

Dogs bark

When there are too many sheep then the shepherd gets himself a dog to help. He trains the dog to listen to his commands and then bark to the sheep accordingly in order to steer them in the right direction. 

A manager higher up in the hierarchy often has more sheep than he can manage by himself. For instance, the manager of the department has multiple team leaders reporting to him, while every team leader manages their own team. The department manager trains the team leaders to think and act exactly like himself. And if necessary the team leaders bark to their team if the department manager demands it.

Beekeeping

Beekeeping is fundamentally different from sheepherding. Bees manage themselves. Bees just want to do their work and they do it as good as possible. 

The better the environment and the surroundings, the better the taste of the honey and the more honey they produce. For instance, when there are a lot of flowers they can produce more honey. If the flowers are far away, then the bees have to fly a long distance and therefore it takes longer to produce a certain amount of honey.

Trust your team

The key to develop self-managing teams is to trust your team that they do their work as efficient and effective as possible. They are all experts in their role and know what is best. And even when they don’t know, it provides a learning opportunity so they will know it the next time.

The important thing the self-managing team needs is a defined goal and transparent results. That´s what the manager of the team is responsible for. He needs to define a clear goal and make the ongoing results transparent to the team. Then the team by itself will fill in the details on how to get there.

Blame the process, not the team

When the bees don’t produce the expected honey, then the beekeeper does not blame the bees. In such situations, there is something wrong with the environment. Maybe the location of the beehive needs to be moved to a better place or there is something else wrong with the setup.

When your team does not deliver the expected results, then don’t blame the team. This is a problem with the environment or the process. You need to look into what is wrong there and fix it.

This is easier said than done. Because if there is a f*ckup then it is way easier to identify one of the people as the reason for the problem. But we need to look a level deeper and find the root cause of the issue. Most of the time the people tried to do their job as good as possible and the root cause of the issue is the environment or the process.

Change yourself first

In order to develop self-managing teams we as managers need to start with ourselves. We have to unlearn the old habits of managing people like a shepherd manages his sheep. We need to think and act more like a beekeeper.

I urge you to read the whole story of Mark and his grandfather. There are a lot more lessons in there for leading self-managing teams. It is a worthwhile read and the 140 pages take only a few hours to get some inspiration about leadership. You can get the book here (affiliate link). 

That´s it for today. Stay tuned and HabbediEhre!

Nexus – the scaling Scrum framework

Nexus is a framework, which builds on top of the scrum framework and is designed for scaling. It focuses on solving cross-team dependencies and integration issues.

What is Nexus?

The Nexus framework has been created by Ken Schwaber, co-creator of the Scrum framework.

Similar to the scrum guide, there is also the Nexus guide, which contains the body of knowledge for the framework.

It has been released by scrum.org in August 2015.

You can find the definition of Nexus in the Nexus guide as follows:

Nexus is a framework consisting of roles, events, artifacts, and techniques that bind and weave together the work of approximately three to nine Scrum Teams working on a single Product Backlog to build an Integrated Increment that meets a goal.

The Nexus framework is a foundation to plan, launch, scale and manage large product and software development initiatives.

It is for organizations to use when multiple Scrum Teams are working on one product as it allows the teams to unify as one larger unit, a Nexus.

Scrum vs Nexus

Nexus is an exoskeleton that rests on top of multiple Scrum Teams when they are combined to create an Integrated Increment.

Nexus is consistent with Scrum and its parts will be familiar to those who have worked on Scrum projects.

The difference is that more attention is paid to dependencies and interoperation between Scrum Teams.

It delivers one “Done” Integrated Increment at least every Sprint.

New Role “Nexus integration team”

The guide defines a new role, the nexus integration team.

It is a Scrum team, which takes ownership of any integration issues.

The Nexus integration team is accountable for an integrated increment that is produced at least every Sprint.

If necessary, members of the nexus integration team may also work on other Scrum Teams in that Nexus, but priority must be given to the work for the Nexus integration team.

Event “Refinement”

In Nexus the refinement meeting is formalized as a separate scrum event.

In the cross-team refinement event Product Backlog items are decomposed into enough detail in order to understand which teams might deliver them.

After that dependencies are identified and visualized across teams and Sprints.

The Scrum teams use this information to order their work to minimize cross-team dependencies.

Event “Nexus Sprint Planning”

The purpose of nexus Sprint Planning is to coordinate the activities of all Scrum Teams in a Nexus for a single Sprint.

Appropriate representatives from each Scrum team participate and make adjustments to the ordering of the work as created during Refinement events.

Then a Nexus Sprint Goal is defined, an objective that all Scrum Teams in the Nexus work on to achieve during the Sprint.

After that the representatives join their individual Scrum teams to do their individual team Sprint Planning.

Event “Nexus Daily Scrum”

The Nexus Daily Scrum is an event for appropriate representatives from individal Scrum Teams to inspect the current state of the Integrated increment.

During the Nexus Daily Scrum the Nexus Sprint Backlog should be used to visualize and manage current dependencies.

The work identified during that event is then taken back to individual Teams for planning inside their Daily Scrum events.

Wrap up

This is a very highlevel overview about Nexus, you can find more information in the Nexus guide or in this nice introduction.

I am practicing Scrum for quite a while now, but I have never heard about Nexus before. Only last week I stumpled upon it on the Internet.

Therefore I also don’t know anybody who is actively using the Nexus framework in their daily work.

But from this point of view it looks like Ken Schwaber did a very good job again when defining this framework.

I hope that I will have the chance some time to work with Nexus in real life. Of course, for that you need to have the environment where it would make sense to give the Nexus framework a try.

Ok, that’s it for this week. Have a good day and HabbediEhre!

Scrum values – new section in scrum guide

The scrum guide, the official description of the scrum working methodology, has been recently extended with a new section: the scrum values.

Before we dive deeper in what the scrum values are about and what they mean, I want to give you a quick overview on the history of scrum, and especially about the history of the scrum guide.

Then it should be easier to understand the big picture, when and why the scrum guide has been created and updated over the years.

History of scrum

Scrum is now about 21 years old.

Jeff Sutherland and Ken Schwaber, the fathers of scrum, presented their paper “SCRUM Software Development Process” the first time in 1995 at the Oopsla conference in Austin, Texas.

But the name scrum was not their invention. They inherited the name from the paper The New New Product Development Game published by Takeuchi and Nonaka a few years earlier.

Scrum is used to solve complex problems. It uses an empirical approach and solves problems based on experience and facts.

Until today scrum has been adopted by a vast amount of software development companies around the world. But scrum has also been successfully applied in other domains, for instance manufacturing, marketing, operations and education.

History of scrum guide

Jeff and Ken published the first version of the scrum guide in 2010, which is 15! years after their first presentation of scrum at the conference. I don’t know why it took them so long nor what has been used by the community before that.

Jeff and Ken made some incremental updates to the scrum guide in 2011 and 2013. Together they established the globally recognized body of knowledge of scrum, as we know it today.

Recently, in July 2016, a new section has been added to the scrum guide: the scrum values.

The scrum values

Successful use of Scrum depends on people becoming more proficient in living following five values: commitment, courage, focus, openness, respect.

Let’s have a look at each of those values including the one sentence of description from the scrum guide.

Commitment

People personally commit to achieving the goals of the Scrum Team.

I am personally very happy that this value has been added to the scrum guide and is now officially recognized as an important value for a scrum team.

It is a challenge to get the team to commit to the goal of a sprint, but it is a cruicial part in making the team successful.

Courage

The Scrum Team members have courage to do the right thing and work on tough problems.

People should stand up for their beliefs and for what they think is important to put the team to the next level.

People in a scrum team should not be afraid of though problems. They face even the thoughest problems and try to solve them together.

Focus

Everyone focuses on the work of the Sprint and the goals of the Scrum Team.

People are not picking up work outside of the committed sprint. They focus on the work, which has been agreed upon in the sprint planning.

Everybody works on what is good for the team, not what is good for themselves. The goals of the team have a higher priority than the personal goals.

Openness

The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work.

There is no hiding of facts or not telling the whole truth about what is going on. There are no political games played.

Everybody is honest about the problems they face and for instance explains why things are delayed to give the stakeholder insights of what is happening within the team.

Openness in the team as well as openness to the stakeholders builds trust and a better working environment.

Respect

Scrum Team members respect each other to be capable, independent people.

Respect is one of the key elements of building a good culture within the team and in the whole organization.

Treat people as you want to be treated!

Why has the scrum guide been extended?

How were those changes in the scrum guide implemented?

Ken and Jeff built a community around the scrum guide and they are running an online platform, called users voice, where people can make suggestions for changes in the scrum guide.

Other people can vote for those suggestions, but the final decision for making changes in the scrum guide is still taken by Ken and Jeff.

Wrap up

Today scrum is recognized as the most applied framework for agile software development.

The scrum guide plays a very big role in the success of scrum, because it is the first reference point for people wanting to learn more about it.

The newly added section containing the scrum values are a very welcome idea to improve the scrum framework even further.

I will definitely present those scrum values to my team to make them think about this topic and get a discussion rolling. Let me know, if you did the same and share your experience in a comment.

That’s it for this week. Stay tuned and HabbediEhre!

Definition of story points

Story points are all about effort and only about effort. A story point has nothing to do with complexity or uncertainty of a user story.

The definition of story points is not obvious.

Many scrum teams use story points in their daily job, because they are better for estimations than hourly estimations for many reasons.

But it is not clear how a story point is defined.

If you ask google, then you get a couple of different definitions.

Continue reading “Definition of story points”

Core Scrum CHECKLIST – Doing real scrum?

The core scrum checklist is a great and easy way to determine whether you are doing real scrum.

The core scrum checklist is an easy way to find out, whether you are really doing scrum.

When I started in my new team we had all the scrum events in place – sprint planning, daily standup, demo session, retrospective meeting.

But it turned out we were still missing some important elements for really doing scrum.

How about your team? Is your scrum process really ok?

Verify with the following simple checklist!

Continue reading “Core Scrum CHECKLIST – Doing real scrum?”

Traditional vs empirical process

What are the differences when you implement a project using the traditional approach vs an empirical way of working? During a scrum workshop, which I attended recently, this question has been answered in a very descriptive and visualized way, which I want to share with you.

Continue reading “Traditional vs empirical process”

How to choose a reference task

A reference task is a certain task, which has a fixed amount of story points assigned, and which is used as a reference point to estimate other tasks. But how do you choose such a reference task? This post should give you a method and some ideas, how you can find a good reference task.

Continue reading “How to choose a reference task”

Why agile? – The Stacey complexity model

Reading Time: 4 minutes

The stacey complexity model categorizes tasks in four different categories: simple, complicated, complex and anarachy. Then the model explains for each category what is the best approach to solve those tasks.

Did you ever hear the question “What is agile?” and you didn´t have a proper answer right from the top of your head. Or did somebody tell you, that agile is something from the software development world. Then I guess it is not so easy to explain to those people, that agile is a working methodology, which does apply to more than only software development departments. I think I have quite a good diagram to explain, for which type of tasks the agile way of working is the best.

A few weeks ago I attended a great scrum master training in my company at LeaseWeb. One of the first items on the agenda was the Stacey complexity model, which helps you to understand uncertainty in a project.

Continue reading “Why agile? – The Stacey complexity model”