Starting a Scrum Team - Part 2

Introduction

This article is Part 2. You might want to start with Part 1, here.

In Part 1, I explained that these are guesses about the best things to do at the start. It really depends on the situation—your specific situation—and situations vary quite a lot. Don't expect to prioritize the same things the same way for your next Team.

Question: Does the Team have to be a Scrum Team?

Ans: No, of course not. I like Scrum, and I think it is usually what they should be moving toward. But: "People are remarkably good at doing what they want to do." (My quote) So, for God's sake, do not force them to do Scrum. Forcing Knowledge Workers is I think a recipe for...well, a definitely sub-par team at best. Cf. Daniel Mezick and his work on Open Space Agility.

I do think most of the suggestions remain the same (or similar), whether you have a Scrum Team or a Team using somewhat different rules, at least in my opinion. At least if you are going to use a real Team (and not just a work group). (Cf. The Wisdom of Teams by Katzenbach and Smith if you don't know about real teams vs. work groups.)

Question: Are your suggestions (going to be) complete? That is to say, reduce my risk completely, or as much as possible?

Ans: No, not complete. NOT complete. That was a main point in saying "the suggestions depend on your situation". Also, Scrum itself is only a bare framework. In addition to doing Scrum well, your Team (or your company) must add some additional things. Lots of debate what those additional things might be. If you are doing software, immediately I recommend adding a lot of XP stuff. (XP is shorthand for EXtreme Programming, another agile method.)

One key idea is this: whatever you start with, you still and always must be observing and thinking and anticipating what's going to get mucked up next. Or, to put it a different way, how do I help my Futball team win the World Cup? (Imagine you're the manager.) What's going to cause Argentina to beat France (or vice versa) is not going to be something that can be easily listed out. Some vague things, such as "better execution" might be on a short list. Or possibly: "our players just had one of their best days."

Question: You did not say everything about suggestion X. Please explain more.

Ans: Yes, me too, I agree. There was so much more I could have explained about that suggestion. And I will sooner or later. One suggestion is often closely aligned with another, so that I feel one cannot talk of one independently of the other.

This is a key idea with the 94 patterns suggested in A Scrum Book (Sutherland, Coplien et al). That patterns work together, as a set of patterns.

But that's the truth of life. And that's the way with Scrum. In ways impossible to describe well, everything is connected to everything else. You cannot meaningfully (except for first year medical students) separate the arm from the body, or the leg from the body, of a Futball player. The player plays as a whole person (whatever that is) and the Team plays as a whole Team (an even less understood thing).

But one method to understand is to break things down into pieces and parts. I am trusting you will internalize all this, and re-assemble these things on the battlefield of life. Where there is so much confusion, always.

Now, a look back, and a look forward:

The 3 Suggestions in Part 1.

1. How important is this project? Find out.
2. Get the best Team you can. That includes Business Stakeholders (chickens).
3. A Team that wants to be successful, together.

The 3 Suggestions to discuss in Part 2.

1. A Team and Managers that agree to be more transparent.
2. A Team that agrees to improve (or at least try to improve).
3. Get the Team Scrum some training (the whole Team), and ask the Team to agree to try real Scrum for X months. As an experiment.

Transparency

Why is "transparency" so important?

Simple: You cannot see what the real problems are unless things are reasonably transparent.

Of course, to be fair, life is not transparent. Life beguiles us. And we must struggle to release ourselves from our (let's be kind) misperceptions. And biases.

But my suggestion focused on the people.

Do people always tell the truth, the whole truth, and nothing but the truth, so help them God? A wit might say: Apparently God is not helping enough. Fleetwood Mac said: "Tell me lies, tell me sweet little lies."

Still, at work at least, we can explain the value of transparency. Most people accept it as a good thing (until you ask them to be more transparent). And I think a decent ScrumMaster can actually get most teams to become a little bit more transparent every day, on average.

Actions:

• Ask each team member if they are willing to be more transparent. Assuming they agree, ask them to live up to that a bit more each day. (Never expect complete transparency, although it will get better.)

Part of the truth is they will be more and more transparent if they trust the team more. At the beginning, each team member often does not really know some of the other team members. So, discuss this.

Ultimately, you may find you have a person who is notably non-transparent. Maybe good for a James Bond type. Not good for your Team. Evaluate. And decide, as best you can. And you must act. Sooner or later.

• Ask the managers to be more transparent.

Managers are used to keeping things "close to their vest" or on a "need to know" basis. I am not saying that from this time forward the manager never has a good reason to do that. But the manager, for the company, must exemplify transparency. Or at least more transparency. And the feeling that it is ok not to be perfect.

Tell the managers that you (the agile advocate, possibly the SM) will be coming to them to discuss specific things to be more transparent about.

Sometimes you can intuit that a manager or set of managers is going to basically disable transparency. If so, I think you have to call it out. I can imagine a case where I'd say: "Nevermind. We are not going to have enough transparency. We're not doing this project or product."

But usually, I am hopeful that the basic transparency of Scrum will show people that more transparency is helpful. And that, with that greater transparency (however imperfect), we can be more successful.

Reminder: Transparency enables inspection (seeing what needs to be fixed next), and inspection enables adaptation (doing something to get better).

Improving

Can anyone reject the idea of improving?

I think most reasonable people will not reject it. Perhaps a few will. Directly or by "quiet quitting" (recent jargon).

Most will agree that improving is good. The next hurdle: what are they prepared to do about it?

You (the agile advocate or ScrumMaster) must explain.

A famous quote from Ken Schwaber is "You suck and that makes me sad." So, I recommend 4 truths:

• I suck
• We suck
• They suck
• It sucks

I hope a few people chuckle, because it is no surprise, and yet saying it out loud seems hard, commonly.

Nothing is perfect. And everything and everyone can improve. Can they agree to that?

And ask them to commit to becoming measurably better.

This is one great reason that Scrum is a game.

At the end of every game, we can see the score and see if we won. No one expects the game to be totally fair ("life is not fair"). But if you lose the game, there is probably some meaningful way we can improve. Losing teaches us we need to get better.

So, define winning and define success. Make some of it measureable. (I think of measuring Velocity. Yes, some of you don't like it. A discussion for a later post.)

Set a goal. (Mine might be increasing Velocity 25% within 3 months after the baseline is set. I'd set the baseline as the average Velocity across sprints 4, 5, and 6.)

Important to have a goal. Important to measure progress toward the goal. Important to not take any goal too seriously. It is there to help us. Sometimes other things need more attention.

Change one thing at a time. Change the most important thing first. Make the impediments small enough so that you can implement a (meaningful partial) solution in 2 weeks or less.

In terms of improving we have Michael Jordan's quote: “I can accept failure, everyone fails at something. But I can't accept not trying.”

Scrum Training and Buy-In

It is very common that any team you build now will NOT have a common understanding of Scrum. (Well, again, I am assuming you will start with Scrum. I think a good place to start.)

Some will know it, or their own version of it. Some will not know it at all, or a very different version of it.

Hence: I recommend you get the whole Team trained again.

I might use the Team Level Up workshop approach (review and choose from about 200 cards that describe the ideas and practices of agile-scrum).

One of the best things with the Team Level Up workshop is they get 24 training hours to CHOOSE what they will do and what they will NOT do. And the top 10 things they want to improve on as a Team. That CHOOSING is essential.

I also recommend a 1-day Real-World Scrum workshop, where they work through what agile-scrum will be for them now. See how they can apply it in a practical way now. And solve some key issues up-front.

The next key thing is their buy-in.

You may remember my quote: "People are remarkably good at doing what they want to do." Even more so for Knowledge Workers, which is what you have.

Are your people cynical? Have they maybe tried agile-scrum, and it did not seem to help much, or at least the change was annoying?

So, the best you can do, often, is ask if they are willing to try this new approach for X months. Maybe 3 months or 6 months. And see if we (the new Team) can get it to work. If not, we will stop it.

It's an experiment. Who can resist an experiment to try to become better?

And then the Team with one or two managers must work hard to tweak things so that it works (we hope). A "tweak" might mean some fairly substantial changes.

REMINDER: Nothing guarantees success. There are many ways to fail. And many surprising things happen in life. Work together to make it happen.

Three more things.

Motivation. Over time, keep on the Team only those who are motivated. By the product and/or the customers. Or, possibly, because they like the Team.

Fun. Try to make sure they are having fun doing agile. Ok, call it serious fun if you find "fun" challenging in your culture.

Success. Set things up so that the Team is mostly successful. I like to think of each Sprint as a game. The Team sets the bar (eg, the 8 stories we committed to). We want to land 50%+ (of the Sprints) where we get all the stories done-done.

And celebrate our success. (And it must be mainly successful in regard to all the other obvious factors. Ex: Success per sprint is leading toward a successful release, and that is leading toward a successful product long-term.)

Conclusion

If you can quickly build motivation, fun, and success in the early Sprints, then it seems probable you will have started the Team well.