Managers: How to have break-out, outstanding Teams. #1
We are not generating enough high-performing 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 do it?
(Yes, understanding some root causes of failure will help us.)
What *is* happening?
In my opinion, the typical thing for most companies is, to my eyes, very modest success.
That is, the typical team is 20% more productive.
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 you should do.
These are my best opinions, based on lots of experiences, and lots of discussions. So, for you, these are suggestions you must evaluate.
We’ll name the first 5. More to come later.
These are from the Manager’s viewpoint. These are the how-to’s. In roughly the right order.
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.
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.”
Here’s my suggested goal set:
- Have team’s of 7 people; 7 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 this 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.”
The company wants to higher Velocity (lower cost) and more BV. In this trade-off, the Team gets more fun, less stress, more satisfaction in their work, and work they are proud of. A very reasonable trade on both sides.
I do not expect you to achieve these metrics each time. Many situations. Sometimes you will do better, sometimes some things will be higher.
Michael Jordan: “I don’t mind failing. I mind not trying.”
These recommendations are for what I think of as the standard situation. I am not explaining them fully. Nor do I have time or space to discuss alternate situations. Please contact me if you would like to discuss the recommendation.
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. 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 from the 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 a while 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.
4. Identify the 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. You want them to “do it” and to set a good example, that the other Teams try to emulate.
If you are lucky, that happens. They set a great example, and everyone says: “I want our [new] Team to be like them.”
So, make a list of the “projects”.
Pick projects for them where you 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
You are asking the Teams to change. You are asking them to identify things outside the Team to change. You 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 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.
And when you become very good as a change agent, you will still fail a lot. In 1927, Babe Ruth hit 60 homes with 89 strikeouts.
You can become a lot better as a change agent.
Some people you are changing:
- the Team
- your department
- the organization
- the culture
Those 5 are a good start. More to come.