The Whole Scrum Team

November 21, 2017

Note: This is one in a continuing series of posts re Scrum Intro. The preceding post is here.

The team needs to be considered on its own. The team is the whole Scrum Team. Normally that would be about seven people, including the PO and the SM, and normally the team will be full-time, a real team and stable.

Why?

First, we assume you are working on one of the top “things” for the organization or at least your department. Why work on anything less important? We also assume that top priority needs to be done quickly — both for the company’s sake and for the customers. Then, the ratios of PO to Implementers and SM to Implementers are better if the whole team is seven people. Also, we have enough people to cover more of the required skill sets. Lastly, seven is about as big as you can get and still have good communication throughout the team, so that everyone knows what each team member is doing.

Next, a team has a separate identity. Hence, we must consider it as a separate thing.

Now let’s consider a few topics about the team. Historically, the Chicken and Pig story was part of the Scrum Guide. The main point of the story was to distinguish between the committed and those “only” involved. This is an important and useful distinction. The Scrum Team members are the committed, and they are responsible, as adults, for full and complete success in all the dimensions that real success requires. They should have all the right stuff to be successful.

OK, but who forms the team?

Scrum does not say, just as it does not answer many important questions. Scrum depends on the people and the organization to have common sense, but let us make a suggestion. First, there is you, or who you should be — that is, you should be the best Scrum person in your company, or at least your area. You may have some power or authority or rank, or maybe not.

Usually it happens that the team members are chosen by the managers. We recommend at least three managers, because this is a hard and important task and three heads are better than one. We also recommend you advise those managers, who typically are not Scrum experts. Advise them how a team works, how a Scrum Team works, that the team should be set up for success, that the team will be responsible for full and complete success, what a PO does, what a SM does, what the Implementers do, etc. You must help them see the importance of team chemistry if they do not.

So, hopefully they then select a good team.

One good thing about Scrum — You find out quickly how good the team is. Usually within three Sprints you have a fairly good idea if they are a decent team or not.

Once a team is formed, they should evaluate each other and the team as a whole. Can they be successful together? Do they have everything they need to be successful? Have they been set up, in some way, for failure? Do they need anything? They must be adult enough to insist on getting the things they will need for success. Those things needed could be the assistance of other people, books, training, knowledge, tools, etc., etc.

Now, we must talk about the “involved,” or what might be called the extended team. We find that every Scrum Team always needs the assistance of others — always — and that that assistance is critical to success.

The assistance could come from individuals, from departments, from other Scrum Teams, from vendors, etc., etc. It is very important that everyone recognize the importance of the “involved,” and also the related risks.

First, the Scrum Team must identify the chickens and prioritize them. (Others can help with this too, such as managers.) The Scrum Team must do their best to manage the involved, and if further management is needed, the organization or organizations involved must provide that so success is more assured, more likely.

The involved are generally not very reliable vis-a-vis the mission of our Scrum Team. This trait arises from the fact that they are just not committed to our mission. To the involved, the work of our Scrum Team is not their main thing, and normally, those who are “only involved” regarding the work of our Scrum Team have other work that is their own “top priority” (in some sense or another).

Typically some of the involved will in fact prove more reliable than others. The team must monitor them, and do what they can to help assure that the involved deliver on a timely basis and with high quality.

What do the involved deliver to our Scrum Team?

That too can vary quite a lot. Perhaps the involved provide knowledge or advice. Perhaps they write some code. Perhaps they do some work. Perhaps they build (and test) some (small) component of the bigger product that this Scrum Team will deliver. So, the involved can be involved in a variety of different ways.

Among the involved we want to call out a sub-set that we call the Business Stakeholders (BSHs). Among the key tasks of the BSHs is to come to the Sprint Review every time and give useful and complete feedback. The bad news does not get better with age.

We recommend that you have about four BSHs. That number gives you many hands on the elephant, and the PO and the BSHs are more likely to give a quick and complete view of what the customer wants and what the business wants. This understanding is hard and important, and we do not normally recommend fewer than five (and not more than seven in total either). That is, in the combination of BSHs and PO.

When I say BSH I probably mean someone notably different than what your company may mean. I mean people who can give high level feedback about the Business Value of each story, as well as low-level specific feedback about every detail of each feature, or people who can bring people who can, and a BSH must come to every Sprint Review (as much as anyone does anything every time). This is rare and hard to find, but essential to high success.

It bears repeating that Scrum is a team sport. It is all about the team. So, that chemistry wherein they work together and also wherein they work with the involved is quite important. It’s also important that as a team they rise to the occasion and take on the responsibility of delivering a wonderful product. One might call this the character of the team.

Who leads the Team?

Scrum defines this a bit, but perhaps mostly relies on emergent leadership. (This is a phrase that Jeff Sutherland uses.) Note we call it leadership, not “boss-ship.”

The PO is a leader in the sense that he or she is the final decider on the order the Product Backlog. The SM is a leader in terms of servant leadership and regarding what Scrum is. Servant leadership might be simplified into helping the team get one impediment fixed at a time.

In general, we recommend a team of strong players who are all adults.

With emergent leadership, it is possible that any one person could (briefly) be a leader of the team in one area or another, or from one hour to the next, or that, in the heat of battle, any person could rise up and lead the team in its moment of crisis.

It is this type of team, with aggressive play and risk taking along with emergent leadership, that tends to be more successful in our kind of knowledge work.

Note: The next post in this series is here.