I signed the Agile Manifesto 12 years ago, as a Software Developer back then. Because ever since I developed software products and later teams, I followed the same mindset.
I did so in a lot of different ways, because people, technologies, budgets, and products were always different. In most cases, the collaboration evolved over time. There was never a situation, where I could just have taken a standard process, a rulebook, and tool and let it like that. My working experience was a continuous, common reflection about “am i / are we doing good?” or “should i/we improve or get rid of something”? I just thought it would be a good idea for everybody participating in product development not to strive for perfection but for continuous improvement.
That approach was making all team members over time reflecting about their output, their individual and team experience. And how its all connected. There was always an adoption curve in every team, spanning months and sometimes years. And it was always noticeable when the effect kicked in. Being part of a team, where all are committed to build a great product and how to do it, establishes a strong bond of trust. That’s where and how I wanted to invest myself in. That was my personal intrinsic motivation.
But equally often, my approach failed and I struggled. Because the people involved did not want to establish Agile at all and prefer to stick with Project Management / Waterfall / RUP / you name it, mostly because it felt safer. Or they wanted to have that cool Agile thing, but not what was coming with it. The trust invests, servant leadership or track down & solving failure instead of maintaining a blame culture is a huge demand for many and often an impossible change of a companies mind.
Nowadays Agile is mainstream, but – for the reasons mentioned before – not every company altered its DNA accordingly. We already see a huge and growing number of companies, struggling with faux-agile, as Martin Fowler describes in his post “The State of Agile Software in 2018“. Or Ron Jeffries, describing it in Dark Scrum. And it didn’t took long, to see movements against Agile. “Programming, Motherfucker!” or the Manifesto for half-arsed Agile Software Development are indicating that people are already getting bothered from what started as a code of conduct to collaboratively deliver quality and perverted into another annoying product of the consulting industry.
How did that happen?
Trauma #1: Agile as a product
Like with any other good movements in the past, with the agile movement, an industrial complex came up, which is putting process and tools over people in order to make it a sellable product. The illusion that people just have to learn a certain process and then they’re as fast and cool as the smart internet companies became a profitable business. It looks to be more simple to sell, than the actual exercise.
In the case of Agile, this is actually very damaging, since it is completely missing the central and essential idea.
The agile movement is about people, organized around a product, agreeing on how they want to work together to create a steady, high-quality result. Then making decisions on what routines and tools can support them. And question that continuously. It is about making a team ultimately responsible for its outcome – a convincing, accurate and always relevant product.
It’s not a simple challenge, but neither is it an academic one. And it’s nothing, a company could not achieve basically out of itself.
But more important – all of that can (and should) not be bought from the shelf, which is unfortunately common sense about bringing Agile in today – hire a scrum master, visit some conferences and you are done. Transformation complete, back to normal.
That approach leads to a lot of bad agile ventures, causing more headaches than staying with traditional, already established methodologies.
Trauma #2: Agile in hostile environments
Agile Principles are meant for business models where a software product or service is frequently reshaped in small steps to always ensure market fit or even to develop a market. It came from and for companies who want an always accurate product, responding fast to market changes or opportunities.
To achieve that, they managed to establish and maintain a culture of continuous review and adjust everything. The product, the tools, the technology stack, the team routines, rules – to always have a better and more successful product tomorrow than yesterday.
This culture results in a generative company, which is the precise opposite of one which is just administrating its business. And while that difference looks small, it is setting the stage for the success of applying agile principles.
Those organizations, which are protective and just change a thing when the old is not working anymore, might have been generative in the early days but developed a pathological or bureaucratic culture over time.
That’s nothing that can be healed with agile methodologies in the first step. Even worse, trying to establish Agile in such an environment is either creating a terrible mess or will increase resistance and lethargy.
But the consulting industry is still selling Agile as a product so well, that everybody now wants it. Software engineers want it to not fall behind and get rid of that plan-overpromise-underdeliver circle. And Managers because – well, that’s just how to do things now, because everybody is talking about it.
That old wine in new bottles
As already mentioned, Agile Principles are existential for companies, which have been designed to be generative. They are acting pro-active, not reactive.
Thus, the business model and how it’s delivered is the first where to look at when deciding for agile. How will the business model, the services, the communication, delivery, the funding, profit from an agile approach? How should it be adjusted to leverage the full effect of being agile?
If the consulting industry could focus on the real challenge for the enterprise – how to adapt an existing business model to this fundamentally different way of collaboration – that could break a lot of barriers and show real impacts. What does agile development mean for the delivery of products or services? How should revenue streams, forecasts, agreements with clients or surrounding processes aligned with it? What is the new code of conduct within the company for delivering a product to the market, regarding trust, failure, growth and common beliefs?
Trauma #3: Not moving to an agile architecture
I mentioned before, that Agile will never come to its full effect in reactive business models. Same goes for the architecture of a software platform.
If a business facing software is constructed as one monolithic application, the only thing being agile is making decisions. Implementing and deploying changes will still be sluggish.
Fragile software which needs to be carefully changed, the need for specialists, hard to handle complexity, infrequent releases – that’s all not enabling Agile.
Agile, at the core, is about decoupling. It is about being able to take and execute little decisions frequently and directly, long before they assemble to heavy challenges. It is about modeling the domain, agree on the interaction styles between the contexts and establish autonomous teams to build and develop them. All that has been established to achieve maximum independency between individuals and teams working on a product. The result is a software platform which can respond to change and opportunities significantly faster, precise and less error-prone.
So, a software platform might have been separated in services, but if they are so tightly coupled that they are not independent of each other, from a coding, technology, and delivery perspective, it’s still a monolith. A distributed monolith, but a monolith.
Trauma #4: Not letting go Project Management
I’ve seen agile teams, reporting to a central Project Management Office.
Well, that’s not too bad for a company which already has all routines and reporting lines to the C-Level installed in this format. As long as Project Management doesn’t interfere with the actual product development.
Why?
A project sets the wrong stage for engineering heavy work. The truth sounds like a paradox: Software development was and never will produce an economically valuable and sustainable outcome when power holders just want to finish it. Impeccable, within the planned schedule and budget, and as quick and cheap as possible.
It just doesn’t work for Software Development. Successful Software Development is about starting compact and simple and improve from there continuously. Instead of planning the ostensibly perfect solution over months and then code it down.
Trauma #5: Not scaling Teams
One of the biggest hidden and uncomfortable truths in failed “Agile Transformations Projects” I was involved after, was the misbelief, that you can just take a team and make it agile.
It’s uncomfortable to communicate because it points down, that becoming agile and actually make use of it almost always means raising the budget for resources and even tooling.
Unused agility is a wasted effort and brings much more complexity to your team, which turns out to be not very effective. And it’s the actual source for a lot of blaming out there about Agile.
Agility is also coming at a cost of complexity. Being able to react and move faster as a company also means to have the resources to do so.
Summary – Check your Agile Readiness
If you are considering to establish an agile culture in your company, or if you tried, but still have the feeling, that the promises of Agile are not getting visible in your organization, it always helps to ask yourself this one question first:
Why are we not Agile?
Some answers might then be found by looking at the following aspects
- Purpose – Are we having a commonly understood purpose on a company and product level?
- People – Do we trust each other’s intentions to build a strong and good product or service?
- Business Model – Is our business model demanding or disturbing our agility? Is it generative or reactive?
- Leadership – Do we live a servant leadership culture?
- Technology – Do we have the technological capabilities in place to be agile in our delivery chain?
- Procedures – Are all agile teams supporting and practicing the continuous planning and improvement routines?
Becoming better over time in all of these aspects is the real adventure behind getting Agile. And it’s not all covered by the SCRUM Master Certificate.
