These random words had entered the public space of not only each technology-based firm, but simply the public space. Do we understand them? Do we know how they work? In today’s article I’d like to explore more into the practical application of these words and what I believe is required to make them work for your organization.
Back in 2001, when the original Agile Manifesto was made official, the authors probably never expected the impact it will will have on the software world. It probably does not help that few people read the subpages on that site, which explain the thinking behind the word agile and good engineering practices. Also the compromise that a much bigger group of early people-first technical individuals achieved.
Before we’ll get further, it is worth looking a bit into the past and a bit into the future. The first thing I wanted to look at is lean. The word itself, as explained in an online dictionary means to incline or bend. In the large corporate lingo it means ‘can it be a bit less costly and delivered faster?’. The term lean or with its extension lean manufacturing intended to mean: precisely specify value by specific product, identify the value stream for each product, make value flow without interruptions, let customer pull value from the producer, and pursue perfection. It also comes at times with the famous waste-reducing efforts, which help to achieve more in less time.
Lean itself had influenced agile thinking a lot. But it wasn’t until a group of sysadmins, fed up with systems they had to maintain manually, came up with the term DevOps, that full application of lean into software was unleashed. It is the youngest movement in the family, having officially started around 2008. It basically says any delivered software is worthless if the delivery is not easily repeatable and you don’t have sufficient tooling to run the software smoothly in production. Aka software not working in production at scale – FAIL! It might be seen as conflicting with parts of the original Agile Manifesto, as it does press a point on significance of processes and tools, documentation and contracts.
Agile was created as a response to the booming dot-com and web-based services. One of the main challenges to solve for responding to change faster, while also delivering higher quality products. It is still unfortunately understood as being flexible and delivering faster. Most of the engineers, including testers and sysadmins (using fancy Site Reliability Engineer name or SRE; an evolution from DevOps) will tell you there isn’t an easy way to craft long-term reliability and quality vs a fast delivery. Each corner cut from the agreed process and a roadmap will hurt in the long term. I have seen this quite a few times in smaller start-ups, that try to be lean and agile, and devops at once. After a couple of years they wake up with unmaintainable code and inability to scale. Proper application of agile, lean and devops requires skill and patience.
First step to a working agile-lean-devops
The first thing that usually suffers – communication – is the backbone of all of the lean-agile-devops movements. I have heard and I am still hearing a lot of complaints from engineers, that business won’t listen. Then, being in a managerial role, I hear the same from the business, that engineers don’t listen. No methodology selection will help, up until both sides don’t start talking to each other. Regularly. This also means that engineering has no other choice but to learn business (and soft skills), while business has no other choice but to learn engineering (and technical skills).
This process might be seen similarly to a person learning a new language. Second Language Acquisition Theory teaches us of many ways how this could be achieved. Nevertheless creating a communication culture in your company requires an effort. Sometimes making sure the managers will prescribe people to do something. It also means that technology culture must be present in the business culture (any behaviours stating – that’s engineering, I don’t want to get involved, must be corrected; as well as on the other side – that’s business, aka not my problem).
It is also worth remembering about communication patterns and paths. We as managers must continuously bring our communication skills and understanding of communication to a higher level. This is to understand which behaviours in the group and the developing company culture require a correction and which an amplification.
Only after this two-way communication culture is built, we have achieved the people-matter or simply Peopleware cultural spot. At which point further methodology parts can be deployed.
From a start-up to a mid-sized company
This is where we can start discussing things like Kanban vs SCRUM vs Extreme Programming vs Pure Lean. This is where we can start introducing standards based on the true business needs. Hell! We can even start re-building our business to match the bottleneck needs (and whether you like it or not, most companies dependent on technology will find, that technology-producing departments are their main bottlenecks; following lean – they release the goods to the end customers).
It is also worth to take a deep breath here and understand one thing about technology. It takes time to build reliable, scalable and good-value-for-money systems. Never stop investing in them (this is how Toyota got great). The image below shows what you get, depending on time invested (from a ‘lean’ solution to a scalable tool, optimized for cost, usage, etc, etc).
Notice that getting to a car takes more or less the same amount of time in both examples. The main difference in agile is optimizing for having a high-quality product ready for end customer from step 1.
And when you reach the enterprise scale
This is where things become slightly more complicated. The amount of communication paths in your company had grown exponentially. Your systems are most likely not built to deal with the scale of operations you are running now. The simple Agile Manifesto sometimes works, sometimes does not. This is where DevOps Culture comes to the rescue. You might get surprised how reintroducing processes and tools, documentation and contracts helps. As long as you are still able to maintain the right communication culture.
This is why multiple modern enterprise-scale companies started applying the Product team model (albeit I won’t be writing about it here; this article mainly focuses on technology side).
So this stage of development means a massive investment in automation, observability tools and standards. This may also mean at the start all of your software projects might appear to be slowing down. As long as the slow-down is related to the right changes happening in what I call the technology bottleneck. Team topologies is one of the great tools I’d recommend in panning out what needs to change. This is along side of the DORA metrics, which I have described on this blog before.
Above anything – as a manager – stay consistent and make sure you hold the steering wheel firmly.
Programmers don’t burn out on hard work, they burn out on change-with-the-wind directives and not ‘shipping’.
Mark Berry
To summarize the todays episode:
- Agile does not mean cheaper and cheaper,
it responding to changes faster and delivering higher quality products (while maintaining communication-first culture) - Lean does not mean cheaper and faster,
it means precisely specify value by specific product, identify the value stream for each product, make value flow without interruptions, let customer pull value from the producer, and pursue perfection (while maintaining communication-first culture) - DevOps does not mean hiring DevOps engineers,
it means keeping your software running smoothly in production at scale (while maintaining communication-first culture) - If applied correctly, the 3 above may result in your company producing software faster and cheaper though (as a side-result, not a goal itself)
- You can use Team topologies to draft what needs to change in your technology department (and to map communication complexity of your organization)
- You can use DORA metrics to measure how big of a bottleneck your technology department is (or to reverse – how big of a communication problem you have in your company)
- And last but not least, continue to develop your understanding of communication as a manager. It is absolutely vital.
Gustaw Fit 