[This blog was inspired by a question in Quora]

V model is a conceptual model between design/requirements/needs and confirmation of those needs in the system. In waterfall, it is interpreted, unfortunately, as a staged model, where each stage is completed before the next step. For example, we want to consider user needs and business requirements as a whole before going into smaller details. On the other side of the V we have the verification/validation steps to confirm that the system meets the identified capabilities. First we go down the left arm of the V, and then climb back up the right arm.

This is a logical model - think of the bigger picture before smaller details, and consider how to confirm the system works accordingly at the different stages. But in the way the waterfall approach uses it, there is a huuuuge assumption behind the staged model - that the identified requirements at each level DO NOT CHANGE during the deeper V stages. A lot of people using waterfall approaches do not seem to understand how critical that assumption is, and how huge the impact is to the successful use of the model.

Automation. If we look at the “economics” of testing, the value of testing is in the number of test cycles that can be run and the speed of how quickly they can be run after a modification. If we can run the tests very often and really fast, essentially after every modification, the cost of creating the tests (and test automation) becomes largely irrelevant.

The reverse is true in “traditional testing”. Because that testing, unfortunately, relies on significant amounts of human labor, it is very expensive to run. Any test comprehensive test run will take countless of hours of human work, and will take significant amounts of calendar time. As a consequence, it makes economic sense to collect a larger set of modifications to test at the same time. Because of time constraints, the actual tests executed will be optimised to most likely areas of failure, resulting in increased risk of regression errors going undetected in areas of lower scrutiny. It also, obviously, means that for many features the testing comes much after the actual development, and therefore decreases the value gained. And, I won’t even go into how bad humans are in repetitive testing. I was a test manager at one point doing exactly this, because I didn’t know anything better.

So, because of high costs of test execution, the focus is on the cost of testing, and that consideration trumps most other concerns. But the focus should instead be in the value seek to deliver through testing, and optimising that (as is the Agile credo in general).

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.