Today’s Best Band Ever™ Man Or Astro-Man? Surf-rock. Sci-fi samples and themes. Energy.
This week in the news.
In another Leopards Ate My Face moment, yet another part of the crypto scam unexpectedly happened to be exactly that.
One entrepreneurial genius has inadvertently given us the funniest version of twitter ever. And is ready to step down already.
2022. The year big egos screw up real big, real quick?
Kherson is liberated from the russian nazis (I’m still being suggested to capitalise both these words and I don’t think they deserve that). Fascinatingly the west-hating ruZZia timed the “retreat” with the not-really-a-landslide elections in the US of A.
The war goes on. There are more than 80’000 dead and another ~240’000 wounded russian soldiers so far. There are countries with fewer people.
In the meantime 2 rizzian rockets have flown into Poland and killed people.
Okay. This one’s heavy, here’s the TL;DR
Agility is about speed and control.
You can measure agility (and speed) in money. Any other measurement that cannot be translated into money (time can) is useless.
Doing agile but not improving speed and control is not doing agile.
Technical debt costs money, but should be addressed only when not addressing it will start being more expensive than otherwise.
Work in short iterations. Review. Repeat.
Stable rhythm, async work and no interruptions are key to success.
Teams must be self-sufficient.
100% responsibility for a feature’s delivery must be within one single team.
Agile has become a cargo cult and people have all the right to hate it.
Do, review and adjust. This is the way.
On agility, rhythmic cadence and self-sufficiency
Since the Agile Manifesto the software engineering world … largely stayed the same. Thanks to an army of agile consultants, many companies adopted “agile” which mostly resulted in the myriad of disappointed blog posts. People hate agile and reasonably so. So much that an obviously agile Shape Up framework never uses the cursed word.
My best guess of why people hate how their “agile” is implemented would be - they hate the overly bureaucratic, disempowering, meaningless and rigid process they’re made to follow.
Which is ironic, because the very first point of agile manifesto is this
Individuals and interactions over processes and tools
I would say, that massive majority of companies and people doing agile, have very little understanding of what that actually is. Heck, I’ve seen an “Agile SOP”. An ultimate antithesis of agile already in the name.
Intermission
If you really have to have an agile SOP. here’s one:
Work in short iterations.
At the end of each iteration
Discuss the product so far with the customer and based on that decide what to do in the next iteration.
Analyse what needs to be adjusted in the process and apply it during the next iteration.
There you go. Anything else will make your SOP anti-agile.
And before we get into the how, let’s see at the why and what.
Why agile?
Let’s start with an analogy.
A person is driving a car. They need to adjust speed and direction, depending on what is happening on the road. At the moment when it’s happening.
This is it.
Agility is doing what’s needed, when needed.
Quite simple, actually.
So why are we talking about agile in software engineering? It all started, believe it or not, by Edsger Dijkstra & co in 1968
The major cause of the software crisis is that the machines have become several orders of magnitude more powerful! To put it quite bluntly: as long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem.
Remember when companies were telling people that they would need 24 hours to process the request? This was the norm and this was considered fast. Of course, the reason behind the 24 hours was that they had a computer system (khm, khm, SAP? IBM Mainframe?) that would run a something once a day.
The business agility was a hot topic pretty much since the industrial revolution: Gantt chart, Kaizen, etc. The longer is the delay between a business demand and the availability of the corresponding product, the less value is brought. You have to be a unique vendor to expect your customers to wait, say, a year, before they can get their order.
Agility correlates to reduction of time to delivery. Every company will have their own meaning of what is exactly delivered, but what’s important is that this is a numeric metric. One can look back some time and tell that their time to delivery was this and now is that.
In other words, one can measure their agility.
Ideally, you would measure that in money. Time is also fine. Normally one can translate time directly into money - if running the company (salaries, rent etc) costs - X, this is the price you’re paying for waiting for the product.
This is one of the reasons behind
Working software over comprehensive documentation
The moment you have something working, you can start selling it.
I’ve seen companies of any size and reputation selling products or features that didn’t exist. It’s amusing. But also very annoying.
“Sellable features are amazing, but what about technical debt?”, one might ask.
Technical debt is borrowing time from yourself in the future. You can do something faster today at the cost of being slower later. Time. The formula is the same. At some point it will be more expensive to keep the debt than paying it.
One sign of the good time to address the technical debt is when most (actually quite late if it’s most) of the work done is in firefighting mode - aka drop everything and fix something broken.
What is agile?
With agility being measurable, agility’s definition becomes rather simple - anything you systematically do to speed up the delivery is your agile process.
Conversely, one can be platinum certified in sAFeScrUMfAll and practice all the ceremonies, but if that doesn’t positively affect the speed - it’s not agile.
I suspect this is the main reason agile got its bad reputation - when it’s a process for the sake of the process, it’s soul crushing. There are more ways of doing agile wrong, very few, right.
And of course many things can be slowing one down - choosing the one that is most important at a particular moment, is also crucial for being agile.
This also means that if the organisation is doing their work tracking (ticketing) right across the entire org, they can have a simple overview of what’s going on and what contributes how to the current objectives.
Again, one might argue “what about non-functional objectives like creating an employee-friendly culture?” Even in this case, the objective is not just altruism, but also talent retention and increased productivity. These things are measurable, just not as immediate.
How to agile?
Let’s get back to our person, driving a car. In essence, what they do every moment, is analyse the situation, make a decision and implement it. Wrong decision or a late one and one gets (at best) this:
Translated to software engineering (actually any business activity) this becomes:
Work in short iterations.
At the end of each iteration
Discuss the product so far with the customer and, based on that, decide what to do in the next iteration.
Analyse what needs to be adjusted in the process and apply it during the next iteration.
The main trick about the duration of the iteration is that if it’s too short, people don’t get time to concentrate or even work, if it’s too long, one potentially gets off course. And this could be both ways - misunderstanding of the requirements and change of the business need.
Being able to concentrate on work for extended periods of time is crucial. This means fewer meetings, all ideally concentrated in one block. Same for answering emails, chats, reviewing pull requests, etc. Work must be as asynchronous as possible - one should not have to answer anything immediately (unless it’s an actual disaster). Focus mode in the phones, aggressive notification disabling.
Firefighting is another enemy of concentration and another reason why fixing the technical debt can be postponed but very carefully and not indefinitely.
Another critical factor to a successful iteration is lack of external dependencies. Many companies define teams by the HR structure and this leads to ticket hell. Let’s say we have a unit of work that requires one hour each from 3 people from 3 different departments. If each department is doing scrum in 2-week iterations, this would mean that the 3-hour unit of work will take an astonishing 6 weeks to complete. That is if you could convince the latter 2 teams to prioritise the work into their next iteration.
Intermission
In 1913, Ford’s introduction of the assembly conveyor belt, was based on two assumptions:
Each worker is effectively an automaton, performing one simple task.
The work flow is perfectly defined and requires no ad-hoc decisions.
The automotive industry has moved ever since to use robots, because those two points are a cry for automation.
Even so, it’s amazing to see how more than a hundred years later, this is still being implemented for “simple IT tasks”.
Amazing, because it’s apparently still financially viable to use humans as mindless automotons.
Even more amazing is that writing an instruction than has to be followed to the letter is pretty much the definition of programming.
But even if one pretends that creating a virtual machine is a simple atomic operation, the whole thing crumbles when one attempts to integrate such an operations department into an agile workflow.
In our example of driving a car, this would translate to the driver deciding to outsource, for instance, breaking, because it’s a simple task. “We’re approaching a pedestrian crossing. Let’s create a ticket to the breaking department… Oh, they’re in a different time zone… Oh, their average response time is 24 hours… I guess we should’ve started breaking already yesterday…”
Thus, agile teams cannot be permanently fixed and must include everybody required to do the work they’re currently doing.
This is why DevOps has also become another joke. DevOps was meant that engineers are taking care of the operations/infrastructure (infrastructure as code, anyone?), not “let’s rename our Operations department to DevOps and be cool again“.
If one decides to have a dedicated Kubernetes(Kafka, ElasticSearch) administrator, it’s totally fine, as long as their work is completely transparent to the engineering teams and the deployments are 100% driven by the engineers.
And because it’s hard moving people from team to team, one should structure units of work in such a way that it could be done during one iteration (working product by the end of iteration) and during the iteration the team must have all needed expertise and resources inside the team.
As much as I’m upset with AWS’ approach to (the very vague) integration between products, they’re right in having product teams relatively small and as autonomous as it gets.
Somewhat ironically, AWS’ Cloudformation is its own product and is famous for being always seriously behind the API of what they’re supposed to deploy. This is exactly why several teams cannot be responsible for the delivery of a single product.
To wrap up, allow me copypaste from my last post
Enterprisation
n. A process of taking a progressive idea and turning it into a lucrative but meaningless one.
I believe this is exactly what happened to agile - after early adopters have shown it’s a good idea, it slowly became a hype and the … more careful organisations started hiring agile coaches because everybody else was.
And doing something without an understanding and in the hopes that a ritual will make things better, is a cargo cult.
The way most companies are “adopting” agile reminds me of a joke that goes: night; a couple is in bed; one offers to have sex, the other replies: “Sure, go ahead, just don’t wake me up”.
And after the entire org is actually invested in the change, just like with the zero’s law of robotics, I would’ve added this to the agile manifesto:
If you don’t continuously analyse and adjust your process, it’s not agile.
Take care and stop wars.
PS. This post is 100% GPT-3 free.