How to start a Great Team

Do we want to have a great Team?

I think we definitely want that.  To be fair, though, do we ask ourselves that question?

I think not.  So, ask yourself that question, and resolve that you WANT to create a great team.

OK, yes, you have to define what a great team is, to some degree.  And maybe you feel “I have a beginning team, and I have no idea if it can become GREAT.”  Ok, fine.  But resolve to help them become the best Team they can be.

Why?

Yes, so….why?

In our business, managers often have the idea that people are equally talented or teams are equally talented or productive.

But forget about how talented you THINK they are.  Or how good you THINK they might become.  People can surprise you.

Would it be nice, for you, for the Team, for the Company and for the Customers — if your Team became a Great Team?  I cannot help but think “yes”.

So, let’s TRY.  You could call it an experiment.

And why?  Or, in which dimensions should we become better?  More fun, higher quality, more BV, more $ of profit, lower cost per widget, more customer satisfaction, more pride in delivering a great product to others.  Those kinds of reasons (lots of ways to put them).

Situation

Let’s assume: we have a BIG product to work on or a big project to do.

So, in those circumstances, it would be wonderful to have one Great team rather than having 3 average teams that should (we hope) work together.  Seven people or 21 people?   Which is easier to manage?  Well, obviously.

So, yet another reason, if you have that situation.

Situation 2

A lot of the things we will say (in this post and later) will apply in many situations.  But I recommend thinking within a simple case.

Imagine this situation: We do not even have a product or project yet.

And that, at least for this case, we might get all the basic things.  Not too far into the fantasy world, but imagine that if you asked (and you made the good case), the managers might fulfill some of your more fervent requests.

Initial Steps

This is a series of steps, indicated by the bullet points.

• Get an important product or project

Something that people want to do.  Something where managers might change the rules for you.

But for now and later:

a. People (eg, team members) will be more motivated for an important product or project

b. Managers will fix impediments (more) for a more important project or product.

• Do a quick initial evaluation

I am thinking maybe 2 hours.  There are 2 or maybe 4 of you, and you discuss the situation and try to see (a) what is it, and (b) can it be done successfully.

At this point one question is: Is this thing so crazy and impossible that we should not start it?

This background logic is: It is hard to be successful if you attempt what is truly impossible.

Of course, the quick answer at this stage usually is: it is not obvious yet that it is impossible.

So, what you have gained is something of a consolidated list of issues and concerns.  You can later do several things: (a) evaluate how real they are, (b) mitigate or avoid them, or (c) watch them carefully.

• Pull together the Team

My typical situation is: I want 3 managers who know the people, and typically do not know agile-scrum well yet.

So, I (the agile advocate) explain agile-scrum to them, and the needs we have from different team members.

And I try to influence the managers to pick good people who will form as a Team, and build themselves up to become a Great Team.

Chemistry is a key concept.  Do we think we have a Team that will gel, and maybe become Great?

The other key concept is skill-sets, or at least that is the usual word for it.  This typically means a wide variety of skills and aptitudes. And also existing knowledge, eg, of the industry or the customers.

Again, I assume the managers give you 7 people (assuming you are not “in” the Team): a Product Owner, 5 implementers, and 1 SM.  Right?

• Team gut-check

This is a quick initial gut check.  Do we want to help each other and work together to win?  Do we want to win together?

No should be an acceptable answer.   And that person should be totally allowed to “un-volunteer”.  Better to know now than later.

A “yes” from everyone is of course what we’d like.

A more reasonable answer at this point is: “I’m willing to give it a shot”.  Which is fair.  Often they do not know each other well, sometimes not at all.  Lots of uncertainties.  So, quite fair to say “I’m willing to give it a try.”

This should also include a quick preliminary list of impediments.  What do they see now as the bigger and somewhat smaller “barriers to success”?  This becomes the start of an evolving list.  They might even talk about attacking one or two of the bigger ones.  BTW, these might also be thought of as “opportunities for improvement.”

• Initial quick “Agile Release Planning”

This could vary a fair amount.  But here’s what I’d typically recommend.

Get the Team and 4 business stakeholders (the ones who will come to every Sprint Review).

Have them work for one day (really less than) and put together the Product Backlog, do some story pointing and BV pointing, and layout the stories / features into Sprints.  And start to visualize the initial MVP release or two.

All of a sudden the whole product or project is much more tangible and real.

This quick planning up-front is not final, nor even very good.  One of the big advantages is that it lets them see what they know (as a group) and what they don’t know.  And they can prioritize their stupidity.

Maybe at the end of this day another gut check.  Do they still want to do something “killer” this “season” together?   (Maybe a football team metaphor there — You have to use the right words and metaphors that fit your team.)

***

We had an Agile Carolinas meeting last night and discussed many of these ideas and more.

I put together a Mural (Mural.co) with some quick thoughts.  We discussed some of these, especially the “ideas”, in one of the sessions.

The people in the meeting said “could you send me the Mural?”  I said yes.  It is attached below.

Mural-Thoughts

Please give me your feedback; add to the conversation. Sent that to:  jhlittle@leanagiletraining.com

***

More to come. Another blog post soon.

« « Webinar: A Real Team + A better Sprint Planning Meeting || Webinar: Using the Impediment List » »