Showing posts with label Teams. Show all posts
Showing posts with label Teams. Show all posts

Thursday, October 16, 2008

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.

Sunday, June 8, 2008

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?

Tuesday, January 8, 2008

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.

Tuesday, April 10, 2007

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.