Scrum is abstract

Over the last decade or so I found that more and more sotware developers struggle with scrum.

Especially since so many people treat agile the way it is described in the half-arsed agile software development manifesto or the dark agile manifesto.

So if I change Scrum (my process) - is it still Scrum (the approach)?

One thing that puzzles a lot of people is the fact that Scrum has to be amended past the 16 pages of it's official definition. The definition itself says so.
Yet on the other hand the battle cry of a huge body of people who call themselves agile professionals is "You are doing Scrum-But."
So where does that leave the teams? Torn between "Inspect and Adapt" "Responding to Change" and "Don't do Scrum-But."

Is it Scrum-But, Scrum-And or something completely different?

Of course it is possible to philosophize about this question a lot, but for the experienced software developer it should be easy to grasp. If you have a background in "clean-code" (as Uncle Bob calls it) or are familiar with the SOLID principles for other reasons the following picture says "it all": (metaphorically speaking)

If you look at it as a programming construct Scrum is an abstract class – it defines behavior, data, interactions etc. but some parts are just defined via template methods and stuff has to specified for the concrete implementation.

And for the concrete implementation it makes sense to apply the same rules that make sense when designing object oriented software.

So your subclass should only interact at the designated points without meddling with the innards of the superclass (OCP Open Close Principle). And your implementation should be usable wherever the super-type is usable (LSP Liskov Substitution Principle)

I'm not sure about the other aspects of SOLID, but transferring this thinking for the LSP and the OCP to Scrum implementation – together with the idea that Scrum is an AbstractSuperClass – helps to answer the question whether we're facing a scrum-but or not.

TTFN Michael

DevOps – Karl Marx to the rescue?

Karl Marx made a very distinct point on the fact that in certain societies the means of production are not in the hands of the workers.

Whether the means of production should be in the hand of the society (or the state) is a question beyond the realms of this blog, but one thing I have come to experience over and over - not having the means of software production (i.e. computers and operating systems) in the hands of the developers is a surefire way to extremely inflated development costs.

In software development the means of production need to be in the hands of the workforce

What is so special about computers and software developers?

Who “owns” the computers in software development?

In my work I have come across numerous organizations of all the different sizes, but one thing most of them have in common – even a lot of the smaller ones – is some specific department responsible for the supply of hardware. Especially computing hardware. In a lot of cases these departments are also responsible to ensure that the computers work.
What could be wrong with that? A dedicated department of highly specialized people taking care of the computers for the rest of us. Well... the problem is in the details of course. Developers are unlike normal, “average” workers. While the biggest part of the workforce uses software, the developers create the software. While the biggest part of the workforce is using the computers as tools, the developers are using them as material (well, and also as tools, but there is a fundamental difference in the approach).
Now the problem is that – more often than not – the department supplying the hardware is treating software developers just the same way they are treating the rest of the workforce. And that in turn leads to dire problems.

So what's the problem?

• A software developer, developing software that will be installed eventually has to install that software on his own computer numerous times. It is bad when they have to wait for someone for the “IT-Department“ to enter the password each time they try to do that. (real story)
• A software developer will have to stop running programs on servers from time to time. Is is bad if they have to create tickets in the customer service system to have the "IT-Department" issue a command to stop a process (true story)
• A software developer has to explore new tools from time to time. It is bad if he has to go through a lengthy clearance process to get the permission to install a trial version. (true story)
• and so on...

DevOps to the rescue?

What I noticed about the DevOps movement in the first couple of years, DevOps tried to bring exactly this (or rather: the cure to this) to the development teams – the capability to really own their machines and employ their means to the full extent of their education. (After all they are highly trained professionals in terms of computer usage)

I wonder if that is still the focus of the current DevOps movement. I am skeptical, but I strongly hope so.

So... do you own your means of production? Do you want to? What can you do to get there?

till next time
  Michael Mahlberg