In the previous blogs we looked at what teams really are and what the choice of team vs. workgroup means. Here we’re getting to the very foundations of team formation as a process.

In 1936, Kurt Lewin coined his famous formula:

B = f(P, E)

In the first blog I compared two primary approaches for group coordination – workgroup and team. I also tried to emphasize that the two are both valid approaches (I’m assuming everyone understands that a bad workgroup is not a good approach). So when might we choose one or the other?

We can see the most important difference in the graphs below. On the X-axis we have time. On the Y-axis we have “value generation potential”, which is really a terrible way to say how awesome they can get. 

Pros and Cons of Workgroup

In the first graph, to the right, I have the workgroup. The great thing about a workgroup is that it’s easy to set up and get started. As long as we know who the people are and what they can do, the leader can quickly assign them to tasks and things start getting done. It’s also easy to delegate things further to other people. The main drawback is that the potential of the team is limited to the sum of the members individual abilities (including the leadership ability of the leader).

The word “team” invokes very positive feelings in people. We associate it with working together towards a shared goal, as in sports. But if we look at the way these groups work in most workplaces, we often find that they really don’t match with what the literature means with a real team.

There are two primary ways to coordinate the collaboration inside a group of people working towards a shared product – workgroup and team. It’s a spectrum, to be precise, but we’ll look at the extremes. I’m also including a “bad workgroup” column, to emphasize that I’m trying to compare two good approaches for organizing groups, rather than “team trumps all others”.

Please keep in mind that in the table below I am talking about the same group. In all columns, we have a group with the same external purpose, the same members, and the same externally recognized leader/manager. We will also assume that the group is small, because teamwork does get difficult with group sizes exceeding 9. The only thing that differs is the way the group organizes and operates internally.

There seems to be a perception that a "servant leader" equates closely to the classic image of Jeeves, the british gentleman servant, or something alike.

My perception is quite different.

Servant

I'm going to start with the first word first. This may be a little badly chosen word, at least in English (I don't know about the translations to other languages). A better word might be "service", "serving", or "host" (as suggested by some).

To write perfect user stories, the do this:

Step 1: Ask users what they need from the software and why.

Step 2: Look at the most common answers and try to express them in the form “<someone> can <do something they need>, in order to <main benefit>”. At this point, only write a small number of stories, like 20–50, so that each story is “an epic”, big and unclear, but captures an essential need for some user or group of users. In some way, validate with users that you’ve understood them.

When you start to use Scrum (or any other Agile framework), it will suck. So you try to fix it. Your mindset will define which way you will go – either back to Waterfall or to actual Agile.

To understand what I mean, please imagine a project that seeks to deliver a customer a system they request for. At the end of the project, we find out that the customer doesn’t like the outcome, despite the fact that it matches their original request. 

Why did that happen?

Our brain seeks to understand why things happen around us they way they do. These explanations, for the scenario above, tend to fall into two primary beliefs for the cause:

Agile is a mindset. It is more important how you think than what you do, because your thinking drives your actions and behaviors. Repeating motions without understanding is not very useful, and tends to lead to disappointment.

That said, there are also certain behaviors that support the beliefs we have, so ultimately there should be an alignment between the way we think and the way we behave.

There are different ways in which the mindset (and some of the behaviors) have been captured, in the hopes of making the ideas more easy to understand and express. We do, of course, have the Agile manifesto. We also have Lean Software Development with its principles. Two more recent takes are the Modern Agile and Heart of Agile, both of which try to recapture the essence in four main ideas.

The traditional way to show the hierarchy of a traditional organization is with the CEO at the top and the workgroups/teams at the bottom. The Toyota way (as far as I know) is to reverse it, with the CEO at the bottom. I don’t think either shows the diagram as I’d really like, although the reversed model feels much better to me.

The reason is, the CEO role is a dual role of support and showing direction. In the support role, the role is certainly “at the bottom”, providing support for everyone else in their jobs. In the showing direction role, it is at the tip of the organization.

I have often wondered how I could show that duality effectively, both at the same time. Tonight, as I was going to sleep, an image came to me. I had to get up and do it (and then blog it) so that I don’t forget it.