Self-organization does mean anarchy

From the “I don’t think that word means what you think it does” department.

<rant>
Ever so often I hear people argue that self organization does not mean anarchy. (Especially if the team wants to use non-corporate software, hardware, tool, etc.)

To me this seems quite strange because the opposite is clearly true.

Anarchy does mean without (an) rulers (archos) - or so wikipedia and my history books tell me.

Of course Anarchy (with a capital A) has so many connotations nowadays that most of them are not appropriate for self-organizing teams and I would strongly advise all self organizing teams not to take on the negative traits that have nowadays become associated with anarchy.

But stretch the boundaries – if the team is self organized, who is to tell that they have to work from their assigned workstations? Why shouldn't they put graffiti – sorry, architectural diagrams – on the walls?

We all live in a social system where we can only flourish to our fullest potential if we do not harm other people, but we have to question our rules relentlessly.

In my opinion it is a contradictio in adjecto if you tell a team to “... be self organized, but follow corporate policy to the letter ...”.

</rant>

till next time
  Michael Mahlberg

Saving the product - will you row or bail?

I recently wrote about the widespread phenomenon of the evergrowing pseudo-committed backlog. In which case a backlog really becomes a backlog in the original meaning of the word: Unfinished stuff.

But having such a huge “accumulation of tasks unperformed” (as the Merriam-Webster online dictionary defines ‘backlog’) also often leads to another problem. Housekeeping gets postponed until later. Way later.

What’s the big problem?

Look at it this way - you’re sitting in an eight (the 8 person rowing boat with nine people in it) and your boat is taking on water. Slowly but constantly.
Actually the rate at which the boat is taking on water will lead to the sinking of the vessel about 500 feet before the finish-line. In the world of projects that would be the moment your product becomes unmaintainable.

What are the options?

There are some options to deal with the situation. Let’s look at a couple of them.

1. You could just all stop rowing, start bailing and wait for a SAR-Team to pick you up.
2. Part your team could continue rowing, while the rest starts bailing.
3. You could designate one “bail person” and still try to reach the finish-line with the rest of you still rowing at maximum power
4. ... [lots of other options]

Replace rowing with “creating new features” and bailing by “doing maintenance” and you have a pretty good analogy to the situation we sometimes find ourselves in with the zombie-backlog.

To decide what to do, you might also want to add some more ‘real-life’ rowing challenges. For example the boat might stay afloat long enough to reach the finish-line if only one person is rowing and the rest is bailing, but that person would not last the whole distance. So a rotating system has to be put into place. (see any applicability to your product's situation yet?)

Or take a thunderstorm (and the competition) coming up behind you. Depending on whether the rowers are also able swimmers you might put more people on the oars and risk the boat going under just behind the finish line to still win the race. If none of them are swimmers reaching the shore becomes more important.
Or you might invest more people at the bailing buckets and therefore not be able to outrun the competition, wich will cost you the race, but still get the boat out of the water before the thunderstorm which might otherwise cost you the season. (Depending on your funding and the availability of new boats)

The non-option

There is just one thing that you can’t reasonably do – keep on rowing like there’s no tomorrow. Because if you do, then –someday soon– there won’t be a tomorrow for the product.

Next time you look at the product and the backlog you might want to consider what to tackle – the oars or the bailers.

till next time
  Michael Mahlberg

Legacy code can be made 'easy' - legacy requirements are hard. Welcome to the Zombie-Zone...

In several companies where I supported process improvement initiatives (often by setting up Kanban systems) I saw the same effect: hundreds – or even thousands – of tickets in the (pre-existing) system.

Everybody knows that most of these tickets can't be addressed. Especially with new tickets arriving in the system at a rate exceeding the speed with which tickets can be handled.

Is there a problem at all? After all we can't work faster than we already do, can we?

IMHO this question is really besides the point. Most of the time the answer is ‘yes’ by the way. Most teams with a high workload could go way faster than they do if the took the time to ‘sharpen the blade‘ which they think they can’t do because it seems more important to cut trees. But that is not point I‘m trying to make. Much more important is the question “What is the harm those requirements do, even if nobody is working on them?”

What’s the harm? Enter the Zombies

Comparing those old requirements to Zombies is closer to the truth than one should think. To my knowledge Zombies have never been proven to exist, but Zombie requirements seem to be a fact of life!

So how do they compare? Let’s see:

• # One: They eat Brains!
  Whether you like it or not, these old requirements still consume brainpower.

  • Ever so often someone has to go through them and check if one of them is more important than a new one.
  • Each time a new requirement arrives someone has to check if it is not already in the system

• # Two: They come back!
  Unfortunately people don't realize that those are dead, because they look so alive from afar.

  • Customers enquire on the current state and have to be answered. This usually takes time.
  • Service level agreements and maintenance plans (which your company sold to your clients) kick in and create a huge debt. (Think “fixed in the next major release”)

• # Three You can not trust them

  • There is almost always at least one person who thinks someone else is working on ‘that’ (long dead) requirement and accordingly they rely on it being implemented ‘soon.’ Little do the know.
  • On the other hand there almost always one person who didn't get the memo and thinks it is a good idea to optimize for ‘that’ feature - which never comes.

• # Four They grow, especially because they are dead
  Even though it may seem counterintuitive for people from outside the software-industry, software tends to rot and decay.

  • That requirement you priced at 2 days of effort two years ago – perhaps even in a binding offer – now might costs you three weeks because the software has evolved and the database-schema now includes another dimension that wasn't there when you wrote the offer.
  • That other requirement, which was a “excitement factor” when your sales representative first mentioned it to a customer has become a “dissatisfyer” in the meantime.

Kill your Zombies! Now! Just think Triage. And do it!

till next time
  Michael Mahlberg