The Management Scrum Team

This is an important idea that more and more people are talking about.

One aspect: Managers can only learn what Scrum is and what agile is by being in a ‘real’ Scrum team.

More important aspect: Managers can be more effective in a multi-functional Scrum team. (Often.)

***

STOP!  Why am I writing this post?  Well, it is not because I or we have this idea totally figured out.  In fact, my main purpose is to get others who have tried this idea or something similar to give me (and you) feedback on their experiences, and what they have learned.

Now, knowing our situation better, I hope you and others will provide feedback.

***

What do I mean?  Well, below I will make my comments specific and practical, in case you want to try them.  Also, ideas expressed in a practical way are less likely, I find, to be mis-understood.  I will explain some of the underlying principles, maybe less than others.

Reminder: Other people with a similar idea … have an idea that is also somewhat different.  Thus, they will disagree with me on certain particulars.  USE WITH CAUTION.

Also, I am making a number of simplifying assumptions, and have not expressed all of them.  Again, caution. Also, I am not suggesting that the ideas below will work or even should work in all situations.

***

A Team. Again, we want to call is a Management Scrum Team or MST.

Get a bunch of managers at almost any reasonable level.  They of course need to be similar in some way.

We need about 7 people.  A team too large does not work well, and a team too small is ineffective usually.

***

Now we need to distinguish ‘leaders’ from ‘managers’.   Sadly, this really needs to be a long conversation. Let us say that these people need to at least have real leadership qualities, including setting a compelling vision for the people they work with, being decisive, and having the ability to inspire.  In the managing area, they are not ‘command-and-control’ at least, and hopefully well-skilled at being ‘servant leaders’.  Short version of a long topic.

Some people think ‘management’ is a bad term.  I still like Peter Drucker, and I think the word management is abused and needs to be clarified, but can be useful.  As can similar words, such as manager.  I agree that when an organization tends to always say ‘management’ and seldom ‘leadership’, it is smell…it causes me concern.

***

OK. Maybe we have the CEO and 6 key managers (leaders, gurus, coaches, call-them-what-you-will).

The next thing is to think of them as a Scrum of Scrums.  If at all possible.  To me the key idea now is, they are not doing ‘real work’ (as they always say) but rather are reporting back what their ‘home’ team has done. (The home team may or may not be a Scrum Team.)  It is probably OK if one or two of them is reporting into the MST directly.  That is, they are doing real work themselves.

What’s next?

Notice that I have not (yet) used the word scaling. Partly because few people agree on what the word means.

And because, I am not assuming that the org has or has not already done ‘team-level scrum’, sometimes phrased as ‘scrum with real people’.  To me, we can start doing scrum first with the MST.

Next?

Back to the composition of the MST.  Well, obviously one is a PO (product owner).  Maybe that is the CEO.  One is a SM (ScrumMaster, the key impediment removal driver for the MST itself).  The rest are the ‘doers’ (well, they represent the Doers in each home team).

We have a Product Backlog.  It is prioritized mainly by business value.

It includes…what it ought to include, obviously.  That is, the most important work for the firm.  It might include anything.  It depends on many factors, including the nature of the firm’s business.

It includes ‘real work’, innovation (if you think of that as different than real work), impediments from the Scrum Teams or the departments/divisions, agile adoption issues, cultural change, etc.  Whatever work needs to be done.  Maybe some of the work is easy and some of the work is hard.  Maybe some work is ‘always there’ (in some sense) and some work is ‘temporary’.

Again, the work is prioritized mainly by business value (or, more accurately, bang for the buck, as best they can understand ).  Other factors intrude too.

Perhaps I need to say again…. the people in the MST may not do the work with their own bare hands. They may ‘represent’ other people or teams that are actually doing the work.  In fact, that is much more likely the case.

Sprints.  The MST has sprints.  The shorter the sprint, the better.

With managers, you know, they don’t need any feedback, so maybe the sprints are 3 months long.  Oh, sorry, I was being sarcastic.  With manager work, getting good feedback and fast feedback is even more necessary than with other work.  “The bad news does not get better with age.”  So, seriously, try to get the sprints to be every 2 weeks, or maybe every month.

Agile Release Planning.  This team must do something like this periodically.  Maybe every 3 months, looking forward for the next 6-12 months.  It is complicated, because this team, at a practical level, is often managing multiple ‘releases’ of product.  And they are managing BAU as well (business as usual), which is often a zillion widgets or tickets of CSRs or whatevers.  But, more generically, they define goals and metrics to achieve in some relatively short time frame (in software dev, we used to call this a release or two) and then the basic work items (stories or smallish epics) to ‘get there’.

This has to be some combination of top down and bottom up.  That is, one would expect ‘new ideas’ to have ‘gone to the top’ (no matter where the new idea originated), to be considered and prioritized.  And one would expect lots of basic ‘necessary’ and continuing work to have been identified (or re-estimated) at a lower level and submitted to the top for ‘overall’ consideration.  The CEO often has little choice on the ‘necessary’ or ‘previously approved’ work, but at least in terms of allocating people and resources, the ‘management team’ needs to put it in the picture.

Obviously, this is adaptive planning.  Enough said for now.

Sprint Planning. The MST needs to set a Sprint Goal.  At least a somewhat coherent Sprint Goal.  Always remember what Yogi Berra said: “You have to be very careful if you don’t know where you’re going, because you might not get there.”  In other words, a typical failing is to ‘focus on everything’, which is the same as saying ‘focus on nothing’.  Which means that nothing gets done.

This is a classic problem.  It affects individuals.  It affects Scrum Teams.  And it is probably even harder for the MST.  So, get some focus each sprint.  Maybe another way of saying this is: ‘Try to do less, and you will accomplish more.”  In agile we also have a similar phrase: “Stop starting, and start finishing.”  Or, put fewer things in motion.  Or minimize WIP.  Say it whichever way you want to….Do it!

Now, the work of the sprint needs to be defined in small ‘stories’.  To me, for two weeks, 8 stories for a team of 7 is reasonably small enough, and maybe 16 stories in a month.

Did I mention that this is and should be a cross-functional and multi-functional team?  The ‘people’ within the MS Team are all about the Team accomplishing the Team goal(s)!  So, we are expecting the people in (parts of) the MST to help each other.  We expect multiple people (parts) to typically work on each story.

We also expect the stories in the sprint (the work of the MST) to be ‘completed’ by the end of the Sprint.  To be ‘working product’ that can at least be ‘inspected’ by someone independent (eg, some independent business stakeholders).  The BSHs could look at it and say ‘this is good; customers are really gonna want this stuff’.  Or, at least, this is the feedback we want at the end of the sprint, on each and every story.

So, each story must be demoed at the end of the Sprint.

Writing small stories that can be demoed is a new art for the MST people.  Well, they can write stories that will never be demoed (Sorry! I mean stories that can be demoed after they have left the company…. Sorry!  I meant stories that can be demoed in 5 years).  But, seriously, writing stories that can be completed and demoed in 2 or 4 weeks is hard for them, because they have never done it before.  If you have never done something, in fact it usually feels impossible!  It is not impossible at all, but they probably will feel like it is.  These are tough guys to coach.

Remember that ‘completed’ means having a good ‘definition of done‘ always includes some ‘verification and validation’ by a competent and independent V&V person (in software, we call this well-tested by a good QA person). This also is trouble for them, since they have never done this before.

Daily Scrums.  Daily.  Any questions?  I mean, seriously, can there be any question?

You will start to hear some really lame excuses.  ‘I have another meeting at that time.’  ‘A customer called.’  ‘The President of the US wants to see me in 5 minutes.’  You can’t make this stuff up.  Honestly, some of these ‘distractions’ are important.  But the key root cause is: They do not think the Team is important and they have forgotten how to work as a Team.  And they do not see how the Team is going to help their career.

Jon Defriese thinks this is because the Leader (in our case, the CEO) has not established the right culture.  Often because the Leader himself has not dealt well enough with these issues in his or her own head.

In any case: Daily Scrum.  Daily.  Answering the 3 questions.  Slightly rephrased.

• What did I (or my home team) do yesterday that helped the MS Team meet the Sprint Goal?
• What will I (or my home team) do today to help the MS Team meet the Sprint Goal?
• Do I (or my home team) see any impediment(s) that prevents me or the home team from meeting the Sprint Goal (of the MS Team)?

No impediments is almost never a reasonable answer.  (We focus on the most important impediment, of course.)

Also, we want them to tell each other the truth at the Daily Scrums.  (Stop that laughing! We are serious here.)  And not make ‘political’ statements.  And then to help each other.  (Stop laughing!)

Seriously, it can be tough to coach this team at first.  Often they have totally forgotten how to work together with any team, and especially each other.  Some of you have a better culture, so if you have that case, be mindful that when a new person joins the MST, often he or she comes from a company with a very different culture.  Give that person some time and some coaching to adjust.

Sprint Review.  Alright then!  First, the MST has to ‘review’ things over this Sprint.  Blah, blah, blah.  Keep this part short!  These guys are all good talkers.  The BS meters are running high at this point. Watch out.

Quickly, they have to demo the working stories.  Whoa!  (Neither demo nor ‘working’ imply that product must be released every sprint.)

We need good independent ‘business stakeholders’ (BSHs) to be there to give good, independent feedback in what has been accomplished.  We need to know if we have made real progress.  Or, have we just been ‘working hard’ and accomplished nothing?!  Hence, independent feedback.  Feedback that represents the ‘customer’ for each story.  Some stories are ‘product’ for external customers and some stories are ‘product’ for internal customers. And ‘external customers’ much too often these days means ‘the regulators’.

We need people at the demo who can quickly give us feedback that these different customers will like what the MST has finished this sprint. And I call these people (BSHs).  Note: your firm may call them lots of things.  Examples: customers, managers, dept heads, SMEs, gurus, wise old heads, customer relationship managers, product managers, etc, etc, etc.

Also, often the word ‘business stakeholder’ already has a meaning in your firm different than my meaning.  Watch out for that.

And we need the BSHs to give complete, detailed feedback now.  So, you will not ever get perfect BSHs, but do the best you can.  “The bad news does not get better with age.”

For the MST people, receiving honest feedback can be tough.  They have often not heard that in a good while. All kinds of ‘acting out’ can happen. Some want to ‘shoot the messenger’.  This can be tough on the CEO in at least 3 ways: (a) he or she is getting way more negative feedback than in the past, (b) the direct reports are complaining loudly about the negative feedback they are getting, and (c) the CEO can see that the ‘team’ culture that had been ‘talked about’ for ages does not really exist in they way they had hoped.  This can be tough to swallow.

If there is not much negative feedback, there are two possible reasons.  (a) Everyone is Steve Jobs (or pick another business icon).  Unlikely. (b) People are lying or don’t know how to give feedback.  Often because we picked patsies as the BSHs (and deep-down knew they would give only ‘sweet’ feedback).

Get good and honest BSHs. Insist on the truth.  Remind people that the bad news is the good news.  Because “the bad news doesn’t get better with age.”  Meaning: now that we know it, we’re gonna fix it now, before it becomes more expensive to fix.

Be patient.  “Little things are big.”  And step by step they can all accept that they are imperfect, and improve. Be firm. Be kind. Be honest. Be patient.

Well, a bit more honestly, at some point the CEO is very likely to see that someone ‘needs a promotion to another company’.  The CEO again needs to have been patient. These people are good people in various ways.  And the company’s culture (or someone’s culture) has miss-trained them for many years now.  So, it will take more than 2 sprints for all the dysfunctions to come out and for all the re-training to occur.  So, give people a reasonable chance to adjust.  At some point, someone is likely to be ‘at the far end of the scale’ and you have to give them a ‘promotion to another company’.  (Often we say “It’s not you; it’s me.”  I say this only partly to add a bit of levity.)  And it is tough, but it is also the best thing for that person at that point.

Retrospective.  Again, telling the truth here can be difficult.

We discuss the good and the bad.  We identify the biggest impediment for the MST itself.  And we start to fix it.  As examples, the MST might:

1. devise a solution together
2. plan the execution of the solution
3. build a business case (is it clear that benefits are much higher than the costs)

The business case might go to the CEO or even the Board for a decision.  Often it simply enables the team to work through the information and convince themselves of the best solution.  Often, also, the MST starts the business case, and someone else (the SM?) refines it, improves it, fleshes it out, completes it later.

Who ‘fixes’ the impediments?  Well, it depends.  The SM, the MS Team, or people outside the MS Team.  Depends on several factors.

The key thing is that the Retrospective enables them to get better each Sprint. And in a bigger way than the SM working in isolation, or from identifying the (usually smaller) day-to-day impediments in the Daily Scrum meetings.

***

How much difference could an MST make?

Hard to say.  We do not have enough experience in enough situations to know well.

My experience suggests that in about 2 sprints, the MST is working at ‘normal’ level.  Maybe 3 sprints.  Typically.  But the problem is you had no ‘before’ metrics on the ‘velocity’ of the MST.  So, there is nothing to compare the new Scrum velocity to.

The good news is you now have a metric for the productivity of the MS Team.  They may not estimate the ‘story points’ well yet.  But they are learning.

Usually you find that ‘the velocity is lower than we wanted’.  Is that really a surprise?  (CEO, you did know that already.)

Now you have an approach to getting better as a Team.  And for voiding your weaknesses and for drawing on your strengths.

The difference can be huge.  If people engage, if you allow yourselves to see the truth, if you have the courage to take reasonable actions.

***

One key issue.  I think it is typical to find that the people you have in the ‘management team’ arenot the right balance of people in the MST.  The MST must be balanced against the vision and the items in the PB.  Often you see an imbalance.

Thus, you often need to move some of these people outside the MST, and probably add some other ‘skill-sets’ to the MST (new people).

This is a feature, not a bug.  Meaning: seeing what kinds of people you really need in the MST is a big help.

***

Those are my simplified and initial ideas on an MST.

I hope my humor about the problems of life and the problems we often have being managers was taken the right way. Manager work is hard, and being a manager is hard.  I do have sympathy, despite my sometimes sarcastic tone.

One could cry about the situation, cry at the measureless waste in the lives of the managers and the people they manage, and the impact on the customers.  Or one could laugh. I choose to laugh.

This problem of measureless waste and ‘not good enough yet’ is true for all of us.  And it is sad and we can be sarcastic.  Just to be sarcastic is not good enough.  We must act to improve things, as best we know how.

In this vein, one must have sympathy for managers.  In my opinion, they are usually not trained well to be managers. In fact, they are generally miss-trained (trained wrongly).  In the Peter Principle (they rise to their level of incompetence) is too true.  And their ‘boss’ is too…hmmm….lacks the courage to fix it when the Peter Principle occurs. These are good people, some of our best usually, but badly trained and often badly positioned.  To the degree we can fix this (and I think we can, at least some) it can make for a big improvement.

***

Please give me and us your feedback and suggestions.

Getting the right people in the Team - Richard Branson

For useful innovation, truly good and fast innovation, we think a Team is essential.  They must do knowledge creation in a Team. As Takeuchi and Nonaka have explained pretty darn well.

A real team, not a group of individuals.

As a friend just reminded me, probably the most important thing in getting a Team started is to bring a good Team together. Get the right people.  Frankly, with a great team, you probably could use almost any process, and succeed (although I have a strong bias and experience that suggests that Scrum is the better 'process framework' for them -- if they will do it decently).

And each Team is different.

Here is a post by Richard Branson in LinkedIn that I thought was really good.  He talks about focusing on 'personality'.  Well, at least do not put too much emphasis on the skill sets (aka knowledge domains currently mastered).

And he talks about introverts.

Full disclosure: I am rated an extrovert by Myers-Briggs. Not sure I believe it. I feel a lot like an introvert these days.  In any case, I love introverts (people more introverted than I)... and I learn more about other kinds of people each day.  Every type has something to offer. Fascinating.

Some of you may actually know an introvert or two. ;-)

Anyway, Branson gives some good advice about how to judge introverts. And how to work with people more generally.  For example, your Team may need a 'maverick.'

Enjoy the post.

Scrum 201: Team

We want all Scrum teams to become hyper-productive.

Why?

Well, so they can enjoy life and be satisfied.  And feel like they accomplished something.  So, in part, this requires that they reach hyperproductivity without working any extra hours.

Second, we assume that hyperproductivity also means much greater business value delivered.  This of course will not always be the case. But it should be.

What level is considered hyperproductive?  5x-10x greater than average waterfall productivity.  But we will settle for 5x-10x the teams initial baseline.  Which is usually about what they are doing the 3rd sprint.

So all teams do this? No.

Can all teams do this? No.  Although we expect all teams to try, and to make serious progress.  Meaning: We expect each team to change its firms substantially.

***

Where do we start?

I think the first thing is: Is this Scrum team a real Team?

Far too often the answer is no.

They don't think of themselves as a Team. They don't work as a Team. And they don't measure Team productivity.

So, we often have to start by convincing them they are a Team.

***

Lots of the work is talk. Repeating basic ideas about Teams. Sometimes we must remove non-team players. We must add Team metrics. We must ask managers and customers to view them as a Team.  And we must show them the small successes of good teamwork. And build on that.

It is not what they say, it is how they feel and act.  First, how they feel.

Each team has its own team chemistry.  This must be built.

Once they feel like a Team, then it is easier to coach the specific actions that a Team takes to support each and be successful as a Team.

Often, many people in the Scrum team have never been on a good sports team.  Or on a good team at work. So, often, you don't have much tacit understanding to work with.  Makes it harder.

And lots of the talk and work is on people outside the Team, who are inadvertently destroying the team, through all kinds of words and actions. You, as maybe the ScrumMaster, must change the immediate 'culture' to foster the Team.

Not easy. But a good place to start.

I suppose you can play Scrum without really being a Team, a real Team. But Scrum is meant to be played as a strong Team sport.  This is when you will see the real productivity, the real value.

We want a Stable Team

I think our (your) business is about knowledge creation.  (Well, I think it is for almost all the people who come to my courses and workshops.)  About innovation, creativity, inventiveness. About cool solutions to hard business-technology problems.  It is about some sort of intersection between people and technology. So, coming up with a great product requires something special.

And I believe the ‘special thing’ these days is far more likely to come out of a good Team.

So, from a business management viewpoint (and it is the managers we most need to convince about this) — we need a stable Team.

And it needs to include virtually all the functions (or far more so than we ever did before).  And that also means it needs to include business people and technology people.  Just for amusement, I like to call them suits and geeks. To me it suggests that it just might be ‘interesting’ to put them together.

We must mention two things.

It should be FUN to work in a real Team.  And in fact, in Scrum with all but dysfunctional teams, it is fun. (But maybe could be more fun, if you had a good ScrumMaster helping the fun along.)

It should be more satisfying working in a Team. It is my belief that the human animal has been selected to enjoy life in a small Team.  Like a family, but a bit different.  A small ‘pack’.  Maybe within a larger pack.

So, how long should a Team be stable?

To answer this question, we need to identify basically three situations.

1. Mediocre Team. This team improves 20-50% with Scrum.  Give them 6 months.  If they don’t become better by then, then try putting the individuals in different Teams.

2. Good Team.  This team improves in the 100-200% range.  Wow. Leave them alone. They are doing pretty darn well.

3. Great Team. This team improves in the 5x-10x range. Wow!  Don’t mess with them.  This is the goose that laid the golden egg.  You would be crazy to bother them unless and until they want to be bothered (want to change).  And, if you continue to give them good satisfying work to do, they may never need to change. But, of course, something will eventually happen…one of the usual human things (birth, marriage, death, move, etc, etc).

(There is also the situation of the occasional dysfunctional team. Usually that can be identified in a few Sprints. As soon as you are sure it is not just ‘storming’, then you must change the team composition or totally bust up the team.)

***

This idea of stable teams leads to a major shift in orientation. (The change can happen over time.) We no longer start with projects, and find people to do them.  We now start with a Team, and find good work for it to do.  Who knew that people were important?

The PO - The Team - Daily Scrum

I have some different views on this, and wanted to share them.

Your comments are of course welcome.

I am NOT asking what is or should be in the Scrum Guide. Or whichever 'scrum bible' you use.

I am just saying what my thoughts and experiences have, together, taught me.  I want to discover just what is most effective for 'pretty good' Scrum teams.  (Maybe not best for super teams or for beginner teams.)  So, I am trying to have a conversation -- maybe about what to add to Scrum -- not a religious war.

OK.  My views expressed too quickly:

1. The PO is very important to success.
2. Understanding business value and understanding detailed 'requirements' is very important to success. Both these 'activities' are extremely difficult.  Both for the PO and for the Team.
3. Knowledge creation as a full team is very important. In multiple domains. All domains impinge on all other domains. (Key example: cost-benefit analysis.)
4. The full Scrum team delivers the product. Each provides his unique skills and ideas and creativity.
5. The PO is definitely a member of the Team.  Given real life, often 100% of his time is not enough (see also #7 below).
6. The only team that matters is the full Scrum Team.  It is this team that self-orgs, most importantly. (Yes, every person, pair, teamlet self-orgs....not the most important aspect of self-org though.)
7. I do not think it is useful to talk about a team within the team. (I hardly ever say 'Dev Team'.)  Talking about a team within the team  creates an us-them attitude. And anyway is not useful. And at first at least, a bit confusing.
8. The PO must spend a lot of time with 'people outside the team'.  I will call them, at times, customers. managers, business stakeholders, etc etc.
9. Still, the PO should attend the Daily Scrum as often as possible (by phone if not in person).  And should answer the 3 questions. His work affects the output of the Team.
10. The simplest example is: On Day 1, a question is asked by the coder. On Day 2, the PO can give the answer (or at least say 'I got the answer') in the Daily Scrum.
11. If the PO does not do the Daily Scrum (ever), I think most team members start to think or feel (sub-consciously): "who is that guy; he is not part of the real team".

OK.  This is my experience.  Maybe limited experience.   Maybe just bad thinking.

Imagine that you disagree.

Where we differ, I expect my main reaction or push-back would be: "Well, I can see that happening, and it has happened to me, but I think we should coach them to be better, and often, if we coach them to be better, they actually will be."  Meaning for example: They can do the things above, and it will make them at least a bit better.

Certainly some of you have done different things and been successful.  But could you have been more successful doing it this way?  Or might 'my' teams be more successful doing it your way?  This, to me, is the question.

Again, I am not sure I would coach all beginning teams do it this way.  I am sure some super teams might be more successful another way.  My inquiry is: For most 'good' (but not super) teams, which is the best way to do these things? (PO, Team, Daily Scrum)

Of course, there are many other things in life and in Scrum than just the 3 things I discuss above.

BTW, while what I am saying above is not exactly how it is described in the current Scrum Guide, I do not think it is contrary to what the authors would want.  But it may be more than 'the bare Scrum framework'.  The minimum that they want.

No man is an island, entire of itself

In summers past, I have gone whale-fishing from Nantucket island. Well, not I, although I did go to beautiful Nantucket, as Ishmael did in that novel. But they never called me Ishmael.

But I have set out from Nantucket, as they did of former days, intent to catch me a whale. Albeit mine was a metaphorical whale.

So, you see why I choose Nantucket as the island. I think maybe John Donne, in his very famous Meditation XVII (a much recommended long tweet), maybe was in part thinking of the small island of England, Scotland and Wales.

And thinking of how we are all connected, one to another.

There is something very mystical, magical and special about any team that achieves success. They are indeed connected. And, no doubt it is or will be painful at times, but mostly such a wonderful feeling.

And the great paradox, by losing ourselves we become ourselves, becomes true.

If your collection of individuals would become a great team, they must not just gush with emotions, but act in their beating heart, and strike it with their muscles. Together. The paradox is cut through not in meditation, but in fierce sword-like sharpness in the real world. A game for the courageous.

This team part of the game we try to ignore, quite often. The head bobs at "we are a team" but the body does not follow through, as we might say. Each of us has our issues about this: our old patterns, our egos, our introversion, etc, etc.

People are "Created half to rise and half to fall" as Alexander Pope wrote, so, yes, it can take a lot to deal with them. And it is not just the logical and the emotional. We must deal with all the 18 (and counting) sides of the people in the team with us. (Yes, Virginia, we need more than IQ and EQ. These are whole people in the team. Dang.)

But if we would have any success or satisfaction in life, 'deal' most of us must. And the simple framework of Scrum sets in motion a basic interaction pattern. Which we can build on.

A real person in a good team

Some people take the view that they will be lost in a team. And, to be fair, this can happen. There are bosses and there are teammates who want you to conform, to submit, to lose your identity. To a meaningful degree.

But in a real and good team, the opposite occurs. We each become able to become more of who we are.

We each can learn faster. We can be more honest. We can make mistakes and admit to them. We can learn faster from these mistakes. We can enjoy our colleagues, whom we come to know as more complete people.

Yes, there can be dysfunctions in a team. Some teams can learn their way from those dysfunctions. Some cannot.

So, we and Scrum are not in favor of collectivism, of people losing their identify. We are in favor of each person using his or her unique abilities to be creative. And struggling to find themselves within the context of the team. (Yes, one must face and deal with some compromises, which to the inexperienced or immature can seem really tough. May indeed be really tough sometimes. But unavoidable in our life as humans. 'No man is an island' it was once said.)

So, we are not talking about dysfunctional teams mainly. We are talking about good to great teams.

Perhaps most importantly, I get to contribute to the team making a great product that real customers will like (more). This is very satisfying.

So, it is funny how life can be more satisfying when you give to others. You get more for yourself when you are thinking mainly of others.

Now how are things for the so-called top performer?

Umm. Well, the good team should be able to recognize fairly the talents of all it's members. (But it won't happen every time.)

So, again, we cannot promise nirvana, but we think in good to great teams, even the top performer(s) can have a better life.

Some of this seems paradoxical to those who have been in bad situations. My sympathy to you. But do not lose the faith that some day you will see, in a good team, that it is true.

In my opinion, one of our deepest desires as humans is to be known for that person that we truly are, neither hiding nor boasting, both the good and the bad. It is a deep desire, and a good team can enable you to experience that in a far greater degree than we may have up to now. And it even happens while we are going real work. (ie, Not from some fluffy exercise from a consultant, not in some artificial way.)

The importance of teams

As I teach scrum and lean-agile classes, I often meet people who don't understand teams. Often this is true for some of the smartest, most capable people.

Why?
I think there are many answers.

One is that they have been taught the single-leader team discipline. (This is the phrase that Katzenbach and Smith use for it.) So they assume there is no real team discipline. Ie, they have not been taught it.

So, what is the real team discipline? Many people have talked about it, but Katzenbach and Smith have done a good job of defining it in The Wisdom of Teams.

• Small number
• Complementary skills
• Common purpose, common set of specific performance goals
• Commonly agreed work approach
• Mutually accountable

Another, simpler way of talking about this is to say that the team is smarter than any individual.

This is a little dangerous to say. Yes, teams can be stupider than a single individual, if they let themselves. But Katzenbach and Smith show a number of cases where the team, a real team, was smarter than one individual. Not really surprising to me, since we know the old saying, two heads are better than one.

Why is this so true in our work?

Well....
- we need innovation; generally via basic brainstorming, a small team can be more creative
- our business domains are typically bigger than they used to be
- our technical domains are typically more complex than they used to be
- the speed of change (in all these areas and more) is greater

So a team is better able to keep up. If they are a real team.

More soon....

See The Wisdom of Teams here:
http://bit.ly/9BixGz

Small teams

I was just looking at The Discipline of Teams by Katzenbach and Smith. These are the same gentlemen who wrote The Wisdom of Teams.



First, my strong bias (which I find is reinforced in many places, including this book) is that all "real work" these days takes place in teams. (Yes, Virginia, I need to add some caveats, but it's still basically true. IMHO.)

Chapter Five of their book is titled: Applying the Team Discipline: Number & Skill. Subhead: "A small number -- ideally less than 10..."

They then give 6 long reasons why large groups are not teams (or, at least, don't have the discipline of a winning team, as they [and I] see it). I will summarize:

1. Large groups cannot easily or frequently meet together.
2. Large groups are biased toward efficient meetings. [Why is this a bad thing?!?! Well, efficiency is not creative, for one.]
   
3. Large groups are biased toward hierarchical leadership.
4. Large groups are biased toward stable roles.
5. Large groups usually fail to build common understanding and commitment.
6. Large groups often subdivide ...[and] create smaller teams [sub-teams].

If your culture does not immediately know that a team is 9 or less, you need to study in this area. [IMHO] Get all the help you can to knock down this impediment.

What's a team?

Let's review what a team is in Agile.

A small group: 7 plus or minus two.
Motivated by the vision of one person.
Dedicated (ideally 100% but certainly a lot).
With almost all the skills needed to realize the vision.
The team works together daily.

A team is not:
* Lots more people than that (that's a collection of people).
* Motivated by multiple visions (if there is some similarity in the work, that might be a department).
* Following multiple people (that would be confusion).
* Some folks who work together from time to time.

We give a Team a mission, and we expect them to figure out how to deliver it.

For an interesting discussion about how small teams work in warfare, see Maneuver warfare.

Why are teams important?

This may seem obvious to many of you. But even for those, it may be useful to review.

1. No simple problems. We now need a team to figure out almost any problem. We need the knowledge from multiple people.

2. Creating knowledge. The team is the unit that creates the knowledge. The convert tacit knowledge to explicit knowledge. They brainstorm. They convert ideas to something more real, and examine whether they are achieving the vision.

3. Has "it". We can't describe everything that makes a winning team. One day knowledge. One day skill. One day motivation. Every day something different. But they get it done.

4. Motivation. Creating something brand new is hard work. The team members need to motivate each other to get past all the problems and issues. The team has to find its heart. Once it has it, you can let it run.

5. Clarity. If we have a real team, then when we examine what it produces each Sprint, we have clarity about that. The problems are much more obvious. There is much less confusion. The best actions to make further progress are clearer.

6. Fundamental to make Scrum work. Scrum is built upon a team concept. To get the real value from Scrum, you should start with a team. (I have not thought about it as much, but I think this would apply to all or almost all of Agile.)

* * *

Is your team reaching its potential now?

The concept of "Ba"

Ba can be thought of as a shared space for emerging relationships.

This is a quote from Nonaka's paper called (surprise): The concept of "Ba".

Why is this important?

Takeuchi and Nonaka work at a famous business school in Japan, and have been working on New Product Development, and trying to understand how and why some firms have such market success with new products. One of their lines of thinking, after much research in the real world, is that new products are developed by the creation of new knowledge. This is related to the conversion of someone's tacit knowledge (eg, the tacit knowledge that a customer has of his or her own needs) into the explicit knowledge of a small team. And this small team is then able to convert that created knowledge into the creation of a new product.

Takeuchi and Nonaka (and their associates) have then said that Ba is the place (context) in which (a) the tacit knowledge is converted, and (b) the place (context) that invests the team with the ability to make creative discoveries of new products.

So, software development is about creativity.

I urge you to read about and understand "Ba", and to try to create multiple Ba's for your teams. It is a simple concept, like love, but also a most intricate one as well (not unlike real love). (Or, if you have "love your enemies" completely figured out, please write and explain it to me.)

Here are some places to look:

The Concept of "Ba" by Ikujiro Nonaka and Noboru Konno (an article from the California Management Review).

A good review on the web. In the context of knowledge management (which Takeuchi and Nonaka say should be more focused on knowledge creation).

Building Ba to Enhance Knowledge Creation and Innovation at Large Firms by Nonaka, Toyama and Scharmer.

Your must (in my opinion) also read Takeuchi and Nonaka's HBR paper called The New New Product Development Game. It is directly from this paper that Scrum was created, and it is because of the mention of Scrum in this paper that Scrum got its name. I think you can see the concept of Ba start to germinate in their minds in this paper.

Lastly, I show the picture of a book I think you must read (again, in my opinion of course). It has an ungainly title. The book is group of articles, a couple of which are directly about the concept of "Ba". You must read it because you want to create "Ba" (places) to help your teams to greater success for your firm, and for your customers.

Agile is not like golf

We have to be careful with similes (or metaphors).

If you have played golf, you know that any fool can hit the golf ball a few yards with any of the clubs. It is getting that tiny ball in that tinier cup that's the problem. It is scoring near par that is hard. And mastery comes after lots and lots of practice. After only a few rounds and a few lessons, one can well appreciate the skill of the pros, and how much work it must have taken to get there.

But golf is an individual sport. Agile is a team sport. So, for that reason Agile is more like baseball or basketball or football or soccer. Or rugby (from whence Scrum takes its name). And there's probably a useful comparison to doubles tennis.

How much does one need to believe in the team or in teams to play Agile well? A question for another day.