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.

First of all, welcome to my new website!

Or more precisely, the same website, but with a new appearance. So it just looks new. But anyways, welcome!

Thanks all the people who actually made it happen - you know who you are.

In those times when I have had more time to work with a team to get them started, I have used the following general outline and found it working. By working I mean, it has struck a good balance between effort invested and value delivered. Investing more time could make things even faster, but not proportionally. Investing less time would reduce value and impact disproportionately. You know.

The Plan for Team’s First Sprints

* Pre-game *

1) Kick-off meeting on first day, to get started (this is more
facilitation than training), including

• What are the things we don’t know? How critical are they to know before we start Sprint 1?
• How do we learn together?

2) High level conversations – concept, requirements, UX, design, architecture, technologies, …

To me, there are two things in Agile from which everything else follows. Before moving on, what are those two things in your opinion?

Getting things DONE

The first thing is the potentially shippable product increment, delivered frequently. In Scrum this means that at least at the end of every Sprint, the technical quality of the product meets the criteria of shipping the product (but it doesn’t have to be shipped, for whatever reason, such as not having a shippable feature state). In Kanban flow, this state is reached at the end of every developed item.

This state means, for example: