Scrum 201: Team

Posted on April 23, 2013 by Joe Little

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

Posted on January 27, 2013 by Joe Little

I think our (your) business is about knowledge creation. (Well, knowledge creation is key for almost all the people who come to my courses and workshops.) It is 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?

Who is Scrum for?

Posted on November 27, 2012 by Joe Little

A few months ago someone I know and respect in the Agile community said that they do agile to make the world safe for programmers.

This phrase has stuck with me. I don’t know how seriously the person meant it. I suspect it was partially a joke and partially a stronger statement than one might think. I suspect it is a real driving force for that person.

And it is true that many implementers have had terrible lives, at least often, and making the world better for them is a very good thing.

But I think we should strive for more than that.

We need to make the world better for everyone.

For example, the customers do not want software (usually), they want something useful that will make their lives better. The managers need a better life. The project managers need a better life. The business owners need a better life. The testers need a better life.

Everyone around or affected by Scrum should be getting a noticeably better life. And one easily noticed, in terms of the improvement.

This is happening, although it is not happening as much and for as many people as it should. And when it is happening, it is not being noticed and celebrated as much as it should.

Why?

Well, I think one fairly important reason is that too many of us are being selfish. For example, we are so afraid that the programmer may have to work and be modest and admit failure, that we disable the mechanisms (velocity and demos, for example) that enable the customers and business people to collaborate with the Team.

Anyway: It is an odd request. We want everyone’s life to improve at the same time. No trade offs.

Can it be true every minute? Well, perhaps not. But can it be true every sprint, looking back at the sprint in total? Yes, I think so.

The PO – The Team Daily Scrum

Posted on August 25, 2012 by Joe Little

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:

The PO is very important to success.
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.
Knowledge creation as a full team is very important. In multiple domains. All domains impinge on all other domains. (Key example: cost-benefit analysis.)
The full Scrum team delivers the product. Each provides his unique skills and ideas and creativity.
The PO is definitely a member of the Team. Given real life, often 100% of his time is not enough (see also #7 below).
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.)
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.
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.
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.
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.
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: If the PO comes to the Daily Scrum (usually), then over time it will make them at least a bit better.

Certainly some of you have done different things and been fairly successful. For example, with the PO not coming to the Daily Scrum. But could you have been more successful by having him come? 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 to 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

Posted on November 5, 2010 by Joe Little

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

Posted on October 13, 2010 by Joe Little

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

Posted on October 10, 2010 by Joe Little

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

Posted on October 16, 2008 by Joe Little

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:

Large groups cannot easily or frequently meet together.
Large groups are biased toward efficient meetings. [Why is this a bad thing?!?! Well, efficiency is not creative, for one.]
Large groups are biased toward hierarchical leadership.
Large groups are biased toward stable roles.
Large groups usually fail to build common understanding and commitment.
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?

Posted on June 9, 2008 by Joe Little

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"

Posted on January 8, 2008 by Joe Little

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.