Factory floor mentality – part II

Creating software is not like manufacturing. It is not like building houses or designing engines. It has nothing to do with either. It is closer to craftsmanship, cooking and creating art… yet it is neither. Creating software is something of its own. People who create software do not work in the manufacturing industry and yet..

Waterfall

Winston W. Royce coined the term Waterfall, and it goes like this “The waterfall model is a breakdown of development activities into linear sequential phases, meaning they are passed down onto each other, where each phase depends on the deliverables of the previous one and corresponds to a specialization of tasks”

This is how the Waterfall process looks like:

Looks familiar? This is a high level description of almost every manufacturing process. All the methodologies and frameworks from the Agile “family” included. There’s no going around those phases. There never was. Why Waterfall has bad reputation then? Because people with factory floor mentality tried to implement it, as it is, outside the factory. They ensured to treat software development as making TVs. Difference is that you can’t sell half a TV (two halves since they don’t make a whole). However you can sell half a software (to certain extent). What those naughty people did? Instead of approaching software development as creative and iterative process they did it as a manufacturing one. Either the TV set is whole and it works or it doesn’t. Instead of having feature teams they decided to keep people separate, like in a factory. You do this, you that and no talkie-talkie. The end result was not pretty. Missed deadlines, terrible quality, lost revenue and last but not least the monstrosity called Agile.

Agile

There is no Agile “process”. There is the Agile Manifesto and Agile Principles (behind it). Neither describes a process nor a methodology. Both share what people thought was right. We can sum up the Manifesto and Principles as: “Trust the builders, enable and unblock them. Give them the freedom to decide and the responsibility to live up to their promises, make and learn from mistakes. Hold them accountable, respect them and don’t interrupt with bullshit. Work closely with the customers and facilitate environment in which people can freely communicate and get the job done.“

The problem was that neither the Manifesto nor the Principles had any specific prescriptions. Just that some things are better than others and have higher value. As a result a whole industry of “Agile” frameworks and methodologies came to be. The biggest difference between them and the twisted implementation of Waterfall? Working on smaller chunks that bring value to the customers, release more often, have the people united under feature teams. Basically purified Waterfall. The rest? The rest of the bullshit remained and even got worse.

What’s your status?

Each of the “Agile” frameworks and methodologies came with a bunch of anything but agile rituals, ordeals and gatherings. Let’s call them regular and meaningless meetings. The standup being one of them. Wait, what’s bad of having a standup? Nothing, except the lost time, interrupting the actual work, having people who never know when to STFU and what that standup is for and worst of all – information loss. Information loss? But isn’t the standup meant for the exact opposite? Yet, it is, but have you ever tried to ask the last person to repeat what all others just shared? Have you asked the first one? Did you do that 30 minutes later? End line is that people need not to be forced to talk. They should be able and required to do it on their own. Sharing status is great, but why not make it a daily activity in… an email thread? 10 minutes (best case scenario) a day with 8 people = 80 minutes a day = 400 minutes a week, which is almost 7 hours. Add up few more syncs and see what happens. The standups are just the tip of the iceberg.

Let’s discuss it on the Retrospective!

Retrospectives, Introspective, Inspect & Adapt. Seems great, right? To have everyone together, every now and then (every Q) and do the blah blah so we don’t have to do the cha cha. Waste! During those pointless sessions few dare to speak their own minds and even they become silent because all the feedback almost never leads to meaningful, valuable changes. Why share then? Feedback, if legit, is worth only if one takes action on it. Otherwise it is just noise, a simulation of interest and banner to wave with corporate preaching “We make sure that everyone’s voice can be heard”. Nooo, really? What place would not make sure for that?! Guantanamo Bay?

Die hard

The factory floor mentality dies hard. In a factory, one organizes people around the work. In software development one must organize work around the people. Going the ‘one size fits all’ approach disregards people. It implies one does not understand what software development is, what it requires and takes, how it works and how it differs from everything else.

People are different. Not that different but different enough. As consequence – teams are different. Some are better than others, some are okay with one process while others with another. Some need “rituals” others despise them. Some love them, others hate them. Processes are two edged swords. Following a process because an “authority” (a.k.a “Agile methodology”) said so – is moronic. But understandable. Why? Because of your “leader” that’s why.

Submit to the leader

There’s factory floor hierarchy. In a factory one group of people is responsible for organizing the work, another group is responsible for carrying it out. Those who do the work are neither in position nor allowed to make decision of how it is organized. That question is quite delicate and reserved for the leadership. In a factory there are some good reasons for that, but is this so for software development? Not really. What happens is that your manager (or whatever is called), more often than not, is there not for the benefit of you, the business or the customer, but his own benefit. Sometimes there are exceptions (thank all the gods) but the norm is pretty simple and can be summarized with the classical > self-serving. I’m here to serve myself first and fuck the rest. You may wonder why this is allowed to happen? Because the “leader” of your “leader” is pretty much the same. That’s why one rarely gets to self-organizing teams.

Self-organizing teams

Don’t you love this mantra? Hey, we are doing “Agile” and we have “self-organizing” teams! Sure. If one wants self-organizing teams one must enable them to make their own choices and decisions. То organize in a way that works for both the team and the business. One can’t have “half self-organized” teams. Strangely most companies try to do exactly that and the results are always the same – lack of predictability, poor quality, missed dead lines, stressed up people and subpar outcomes. So perhaps we should do another dumb ass thing, right? Report and measure!

Report and measure

Reports are good when used adequately. They usually provide human readable summary about something. How many tests failed, how often the teams managed to release on time, how many times they needed more time & etc. Reports are good until… one becomes obsessed with them and starts using those as wipe paper. It is said the more the paper the cleaner the ass ( obviously by people who have never considered washing it ). Combine this with the self-serving morons and here you have it. Hey, what about measurements?

Love that part. How much of the code is covered by tests (yeah, just “tests”)? How much bugs have been logged? How many lines of code have you written? How many times there was a successful build as opposed to a failed one?

Measurements are great. Having data is awesome. Knowing about the limitations of both is vital. Have seen this over and over again – morons trying to measure something that cannot be measured (like Quality) and then waving it around as their accomplishment. Until somebody gets on an angry customer call…

Finale

Start thinking about software development as software development. Creative activity that has nothing to do with manufacturing. Do set dead lines, do care if they will be met but do so realistically. Don’t act like spoiled brats who want to be accepted in Kappa-My-Anus-Delta-Unclefather. Or do. Up you. At the end the results speak of themselves.

Leave a Reply

Your email address will not be published. Required fields are marked *