Managers: How to have break-out, outstanding Teams. #1

The Agile community is not generating enough high-performing teams.

Managers: I put this to you.  We could put it to the SMs, the POs, the Scrum Teams, the CEO, etc.

So, why so few break-out Teams?

Well, to be honest, I do not care much why we are NOT having this success — what I care about is: How do we get it?

(Yes, understanding some root causes of failure will help us.)

***

What *is* happening?

In my opinion, the typical thing for most companies and teams is very modest success.  That’s what my eyes see.

That is, the typical team is 20% more productive.  And we can tie the 20% mostly to “agile”.

Which, compared to the “investment” (mostly training), is a VERY good ROI.  But, compared to what they could have, very modest success.

***

Let’s start now to describe what I think you could do.

These are my best opinions, based on lots of experiences, and lots of discussions with lots of experienced people.

For you, these are suggestions you must evaluate.  Your situation may be different (than I assume).  You may have done some of these.

We’ll name the first 5.  More to come later.

These are from the Manager’s viewpoint.  (Most could be said, slightly differently, from the SM or other viewpoint.)  These are the how-to’s.  In roughly the right order, we guess.

***

OK, let’s start to define success in a specific context.  (It might be different in another context.)

Context: Let’s assume you have a company that is NOT primarily a software development company.  You are the manager of an innovation group of 51 people. There is a mix of Scrum knowledge and experience in the group.  The group has not “gone” agile yet, although some of the people have been playing agile from time to time.

How to start?

1. Set a goal

You need to set a goal.  A goal for yourself, which is really a goal for your teams.  And a goal each Team can internalize.

A high goal, not an impossible goal.

Yogi Berra: “You have to be very careful if you don’t know where you’re going, because you might not get there.”

Some people call this: “Define success.”

What you include in your “definition of success” is somewhat less important.

Here’s my suggested goal set:

• Have teams of 7 people; 5 developers (coders and testers), 1 PO, 1 SM.
• The SM is mainly responsible, with the help of everyone, to double the Velocity of the team in 6 months.
• The Team will also be happier, having more fun
• The quality will be higher
• The Team will be working fewer hours per week
• Note: These all mean: we must work smarter, not harder.  Similar to IBM’s slogan: Think.
• Each team member will be motivated about their work (project or product)
• The Team will produce more Business Value per story point (of Velocity).
• The Team will have more releases.  If 2 releases before in six months, then at least 3 in six months.  (This can be hard, depending on how big the next Minimum Viable Product must be.)
• At the end the team members will say: “This is the best 6 months of my career; I never want to leave this team.”

Most team members, as soon as you say “higher velocity”, they will assume you want them to work more hours.  And usually, in a real sense, they are working too hard already.  So, you must get them to understand “smarter, not harder”.  And they won’t believe at first.  Fewer hours, more fun or happiness, higher quality, more pride in their work.  All at the same time.

It is very common that, in their mental model, it is a trade-off.  More velocity means lower quality.  More velocity means more hours.  It does not have to be that way, but they think so.  So, you (the manager) and all the change agents must talk with them and assure that it is not a trade-off.  (It typically has been in the team members’ past.)

So, to me, this is a reasonable deal.  The Customers, the Company, the workers all get what they want.  This win-win-win is important.

I do not expect you to achieve these metrics and goals each time.  There are many situations.  Sometimes you will do better, sometimes some things will be higher or lower.

Michael Jordan: “I don’t mind failing.  I mind not trying.”

Note:

These recommendations are for what I think of as the typical situation.  I am not explaining the recommendations fully.  Nor do I have time or space (here and now) to discuss alternate situations.  Please contact me if you would like to discuss the recommendations.

2. Check your financial situation

You need to understand your financial situation.

How much does each Team cost?  Typically, total cost is around $1 million per year for 7 people in North America.  That is about $40,000 per 2 week Sprint.

You also need an estimate of the Business Value delivered in a year.

A reasonable starting estimate is that the NPV of the product built in that year is $3 million – based on the NPV over 3-5 future years of the product, discounted back to the present value today.

Thus, if we only double the BV delivered (on average per Team), that is worth a reasonable investment to obtain that.

For example, investing $200,000 per Team to fix impediments is quite reasonable if that (on average) doubles the velocity of the Team.

Investing in good training and a good agile coach is quite reasonable.

Having a full-time SM and full-time PO per Team is quite reasonable.

3. Resolve that you want lasting, stable Teams

You are not building a “new” Team for each release.

You are building a Team to last years and to get better and better over time.

One key thing: they will learn to “communicate and collaborate” better and better over time.  A lot was said in that sentence.

Again, in your specific situation you may have roadblocks to having stable teams.  Of course I do not assume you can always overcome them.  But you can often, with some effort.

4. Identify the work (good work)

Gather basic information on the work you might give to the beginning Teams.

Let’s say you start with two Teams.

Those two Pilot Teams should be stacked. The work must fit the skill sets of each Team (pretty well).

You want them to “do it” and to set a good example, that the other Teams try to emulate.

If you are clever and lucky, that happens.  They set a great example, and everyone says: “I want our [next] Team to be like them.”

So, make a list of the “projects” (or products).

Pick projects for the Pilot teams where they have a decent chance for success.   Not easy, but also not impossible.

The work must be important.  And work that inspires those two Teams.  They must want to do that work.

5. Resolve that you will change things

“If you don’t change things, nothing’s gonna change.” Joe Little (my quote)

You are asking the Teams to change, in a number of ways.  Commonly, they agree to do/try agile for the first time, or to do it better.   You are asking them to identify other things to change soo that they improve (smarter not harder).  You, as a manager, must be willing to help and support a bunch of these changes.

And the benefits of change must be greater than the risks, the difficulties, the cost.  This is partly why I suggested understanding your financial situation.  If there is no financial payoff to change, then you are likely to be stopped by that.

And, of course, not only do the financial (and other) rewards need to be there. They also need to be understood.  You have to explain them (and others will explain too).

Key: You must become a better change agent.

The truth is: you already are a change agent.  You would not be reading this if you were not.

And you are not very good yet.  At least compared to how good you could become.

And when you become very good as a change agent, you will still fail a lot.  In 1927, Babe Ruth hit 60 home runs with 89 strikeouts.

You can become a lot better as a change agent.

Some people (levels) you are changing:

• yourself
• the Team
• your department
• the organization
• the culture

***

Those 5 are a good start.  More to come.

 

 

« « Managers: Scrum can help you now! || Iterative and Incremental at 3 Levels – #1 “the what” » »