How Not To Be Agile (With Scrum)

I’m one of those rare software developers who have had the opportunity to work in a relatively smoothly functioning Scrum. It’s true. Everyone thinks they know what it is, and almost everyone is trying to do it. But almost everyone I have ever discussed the matter with has never seen it really working.

Well you know what? I have about 600 words for you.

You’re doing it wrong

It’s a wonderful idea, to create stable conditions and let people do what they do best. But it’s hard, and even in 2018, seems to require counter intuitive things from experienced professionals.

Stable conditions require constant effort. Stability is not doing the same thing over and over, unless you are dealing with toddlers. It’s minimising the impact of inevitable disruptions, anticipating change instead of reacting to it.

For instance, retrospectives and methodological backlog grooming are not waste. Unless you’re capable of both reading and projecting thoughts. And even in that case, it might be useful to give the impression that you are listening. (Although, as a genuine psychic, you are totally in the wrong business…)

I know there isn’t one right way to implement Scrum. But if you omit key elements, however trivial they seem, it’s not healthy to think you’re getting any benefits from the methodology. But there might be another reason why all the small rituals feel wrong.

You shouldn’t even try Scrum

When a team is too small, a key concept breaks down.

Scrum, as a way of forecasting what features will be in the next release, is probabilistic. How do you figure if the sprint plan is sensible? Look at the historical performance (velocity) of the team, and select the set of things to do, so that they will probably be finished by the time you want to make a release. Simple.

But individuals are not probabilistic. Each team member has a tendency to work in a certain way. The problem is that an individual’s behaviour is much more difficult to model than a team.

When there are too few members, a sprint will not be a self organising process. Individuals will be the unit, not the team. It will in practice be a micro-waterfall with pre-assigned tasks.

Speaking about probability…

Speaking about probability, did you ever wonder what is the average age (say, in sprints) of a scrum team? Let’s make some simple assumptions and do some math.

• We have an ideal team with 7 members: 5 developers, scrum master and product owner.
• There are 15 sprints in a year.
• A person gets promoted, reassigned, or just changes jobs every 2 years.

That makes 1 – (1 career change/30 sprints) probability (97%) per team member to be there for the next sprint. 79% of teams survive a single sprint unchanged. Already after 3 sprints we’re at about 50%. So, the average age of an ideal scrum team is three sprints? Tell me what I’m missing, because there must be something.

The idea of course is that Scrum is robust enough to not care about team changes. It’s not like we’re a band and splitting up due to musical differences. Still, it makes you wonder. How much can you trust a measured velocity from only two prior sprints with the same team?

Well, what then?

A slight variation, or maybe a typical instance, of the Too Small Team is when only one member is responsible for some specific activity. (Yes, I mean that single QA guy. And no, I don’t mean your company’s team specifically, I’ve been in a situation like that many times.) The team’s velocity becomes that guy’s velocity.

One serious point to note is that all start-ups begin like this. Many don’t get out of this phase for a long time, if ever.

Fortunately, there are ways of doing it right, or at least much better, even when you’re not ready for the whole package. We’ll get to that later in another post.

But let me make an educated guess. Scrum is not for you.