Get them Climbing again

It is typical for a Scrum team to start Scrum, get some improvement, and then plateau. That is, find some comfortable level of productivity, and just flatline there.

Which I guess is fine, if that level were as good as that Team could do. But the level isn’t, and as they say, anyone can see that. Everyone can see that the Team and everything around the Team are not perfect yet.

Here’s a checklist of 10 things to do.

1.    Is the Team working on an important product (or project)?

If they don’t think the work is important, then there is no motivation to improve.  Sometimes it is important, but the PO has not explained it well.

Or sometimes, what the PO has explained is not motivating to X person, but if you explained other things, person X would become inspired.

2.    Have we eliminated clear demotivators for the Team?

One example: Maybe the work itself is motivating, but the Team has a boss who is the Dementor from hell.

Or there could be any of a long list of possible demotivators.

Another example: the mushroom treatment.  The Team feels they are kept in the dark and fed schtuff (sic).

3.    Does the Team want to win?  And win together?

Ask them.

This question might reveal a variety of issues.

Sometimes they want to win, individually, but they don’t really want to win with these other people (or, specifically, one or two of them).

Sometimes people are afraid of winning.  Sometimes they don’t believe that winning is possible.

4.    Do we have a “capable” Team?

Does the Team have the skill sets and knowledge to win?  Or most of it.  Or could learn it quickly enough.

Sometimes you need to ask the Team and ask an independent person who knows the Team.  You might get different answers.

The Team never, in my opinion, has 100%.

5.    Does the Team have “chickens” that will support enough?

Some of you know the chicken and pig story.  If not, let’s explain.

The core team members we call committed. Ideally, 100% committed or very close to that.  The “extended Team members” we call involved.  Often they are 5% or 10% or 20% “allocated” to the product or project.  Those extended team members are essential to the core team’s success.

If they do not perform well, we’re cooked. The Team cannot be successful, or that is often the case.

So, check that the situation with the chickens is good enough.  And the core team knows that.

6.    Is the Team the right size?

A total of 5-7 people in one Team is strongly recommended. (By Jeff Sutherland, by me, lots of others.)  A full-time PO, a full-time SM, and 5 Doers.

A bigger team makes communication harder across all team members.  Smaller typically means we are missing critical skillsets within the Team (aka, we are too reliant on extended team members).

So, if you have 14 people, divide them into two Teams.  And have the two Teams work on the same product or project.  But, we are starting to “scale” now, and that’s hard. A subject for another article.

7.    Are we aggressively attacking the impediments?

The answer, virtually always, is no.  Or, not enough or not as aggressively as we could.

Maybe that’s a little harsh.  Most teams fix the small “blockers” to the stories.  But fixing the small ones is not going to increase our Velocity a lot.

What would that look like?  You have a list of the Top 20 Impediments.  The impediments are of several different categories, e.g., not just “blockers.” For example, “culture” is in there in some way or another.

And the list of impediments should reflect opportunities for improvement that, together, could double the Team’s Velocity without anyone working any harder.

Everyone, led by the ScrumMaster, is helping at least a bit to fix one impediment at a time.  The SM does some work, the Team does some work, the Manager does some work, and others outside the Team do some work.  And over time, we fix or mitigate a lot of impediments.  And we can see the positive results of that.  For example, the Velocity is increasing.  And that the Team is NOT working any extra hours.

8.    Do we have the three key agreements?

To get real improvement, you must have three key agreements with the Team.

1. We will only work 40 hours per week. Yes, it is not a major offense if someone works one extra hour on the last day of the Sprint. We are working smarter, not harder. “Smarter” (in simple terms) is how we’ll get the Velocity up.
2. We must be having more fun, higher happiness. I like the happiness metric, but you can track it a different way if you want.
3. Quality will improve. We are not getting higher (fake) Velocity by reducing quality.  Because the bad news doesn’t get better with age, we are getting higher Velocity by getting to higher quality sooner.  As the book title says: Quality is Free.

The result of these three is that the Team does not fear the Velocity metric but instead takes pride in it.  This is often a notable culture shift.

9.    Are the stories ready-ready before they go into the Sprint?

We want the “requirements” to be finally, mostly, clear (the requirements for stories in the Sprint).  We have enough details to be successful.

Many Scrum teams have not heard of the DOR (Definition of Ready).  If not, you must introduce the concept.

It is key that the PO works on the DOR process.  Thus, “all the questions are answered before the Sprint starts.” Specifically, all the questions about the 8-plus small stories going into the next 2-week Sprint that is about to start.

We (finally!) have clear requirements!  (Ok, a lot clearer than before.)  The Implementers can vote “off the island” any stories where the details are insufficient.

My saying: “If they know what they’re doing, they get more done.  If they don’t know what they are doing, they get less done.” Another saying: Garbage in, garbage out.

The PO is responsible for improving the people and the process so that the details (for those 8-plus stories) are much clearer.  And for answering the questions (during the Sprint) more quickly.

Let’s use the feedback loop to improve the communication, iteratively and incrementally.

10. They help each other.

We use fancy words like self-organizing and collaboration.  No one understands them well.  Keep it stupid simple.  Help each other, like you’re on one Team, like you’re friends.

If you know American football, you can imagine the offensive tackle helping the offensive guard (on the same side of the ball, for now).  Very easy to say. Obvious even. Except there are tons of details about what that means for each play. And questions about how to do it, given the talent on the defensive side this week.  Lots of film to watch for little things.  Some of you can well imagine what I mean.

Similarly, your Team must learn all the details around helping each other.

Let’s mention three to start.

1. Ask for help and offer help. Yes, some people do not ask for help when they should.  It wastes a lot of time.  Small tasks and better transparency in the Daily Scrum will help.  Ask and offer all the time (no need to wait for the Daily Scrum).
2. The Rubber Ducky (aka the Sounding Board). Every team member must be willing to be the sounding board.  And listen to a teammate when that person is stuck.  Relatively quickly (after the request for help).  And often, as the person is talking, he or she will say, suddenly, “oh! I’ve got it. I forget that little thing”.  Hence, some people say, “You’d have done just as well talking to the rubber ducky. I surely did not help.” And yet, you did.
3. Everyone can help everyone. We do not all have the same skill sets. But we are all smart. And if a teammate is stuck, whoever is halfway available has to be willing to help.  Further: we each must be willing to teach our colleagues how to help us.  And, on the other side, be willing to learn new things so that we can help.

We can improve the collaboration every second, every minute, every hour, every day. It’s about the Team’s success, not our personal success.

 

 

 

 

« « Agile Carolinas: Dec 17: The Holiday Episode || Some tools for Agile » »