Work agile or be agile
Table of Contents
It happened at that time, almost 18 years ago, when the commandments ran out that all software worlds would be improved. And so seventeen experienced and prominent software engineers set out to improve the world of software development. They gave us the agile manifesto with twelve golden principles. To create customer-focused software of higher quality. Doing the right and not doing the wrong thing. Many software developers gratefully accepted some of the points. The scope for interpretation certainly allowed the assumption of having a methodology that relieved developers of some annoying things, such as documentation for instance.
A lot has happened since then. The use of agile techniques has progressed in a way after the first hype had died down, which prompted many company managers to use agility as a marketing instrument: “We are agile” only as a unique selling factor and in times of broad adoption today as “We are too”.
So the world has finally become a lot better when it comes to software products. You’d think so. In fact, the rumor persists that working according to agile principles would be synonymous with being agile. No, it isn’t. It is not a question of being or not being. It’s about the internalisation of mindsets that are anchored in more or less heads or not. In fact, for good reason, there is no definition of any measurable kind of agility that would allow a company to call itself agile. It wouldn’t work either, because that’s what evolution is all about.
The Evolution
In the last 18 years, the software world has made great progress. The complexity of software and surrounding ecosystems has increased dramatically. The demands on software and its interfaces have grown. We no longer only develop web shops with database and frontend, we develop complex embedded systems in aviation, medicine or automotive with connection to backends, cloud, distributed UIs and let them communicate with other systems. As a result, the number of stakeholders explodes and numerous projects come into contact with some kind of legal regulation and countless regulatory requirements. Safety, Security, GDPR etc.
Software is now everywhere and takes over tasks that were previously solved electronically and mechanically. Many software products depend on parallel hardware development. You know this, the fun only really starts when the software tries to integrate itself on a hardware that is still in the prototype stage and you have to explain to the management why the software developers are not available for the next project, although they should actually be finished. However, the integration is only completed in three months. Probably. Hopefully. Perhaps.
The real, agile life
And at this point we find that agility is by no means that simple. At its start, agile development was based on a model that was still up to date in 2001: software development is a self-contained process that ultimately delivers one thing: software.
In the course of evolution, the whole thing has watered down. Today we see teams that have adopted agile principles: Test Driven Development, Daily Standups, Retrospectives and more. However, these form their own islands of blissful agility in a sea of conservative structures and processes within their corporate eco-system. At those points where external traditionally structured influences slosh inwards, conflicts arise and the structure collapses. Even if a completely agile mindset prevailed within the teams.
Agility needs a clear framework whose boundaries and interfaces must be clearly drawn to the outside world. And then Scrum Master and Product Owner together have the thankless task of representing this framework internally and externally. The teams (rightly) want story points, the management (rightly) time and costs. The customer does not want to come for a sprint review every two weeks, the test infrastructure is complicated and expensive, and QA is therefore not designed for short cycles. Regulatory wants to be served and deliverables at each sprint end are extensive if you follow the premise that runnable software can include more than just code. Actually a complete package should be available after every sprint. Half a day for retrospective? “Who pays from which budget?” – asks the controlling department and the former project manager is already missing his Gantt charts, in which everything was arranged so neatly and sequentially.
The whole situation is ultimately reinforced by the idea that the agile transformation could be implemented through a simple role mapping. All of a sudden the product manager, who has been named Product Owner, has an even fuller schedule than before because he has to talk to the team and everyone else. Communication is generally the A&O, but for some it seems to be a rather new construct, because teams and team members suddenly ask questions and even expect quick answers. Outrageous. These impudent punks. In the past, you just let them work and got the result after three months.
The agile life can be quite exhausting!
The agility in the heads
The agile idea, as true as it is, as meaningful as it was conceived, is about to lose its good reputation because the original payoff does not add up. This is not due to the idea itself, but to the large number of weak to faulty implementations and the failure to take account of the increased complexity.
Only a few companies have managed to carry out the analysis in a holistic manner. To place adoption on a broad level so that the payoff actually comes. And from top to bottom. To bring the mindset into the heads of the employees and, very importantly, to keep it there. And this is a constant process of coaching and readjustment. That’s one of the key insights I’ve gained over the last 25 years. To recognise at an early stage where it doesn’t fit. To involve employees and colleagues. To allow the view from outside and, above all, not to rely on one’s own insight, to do everything right.
Complex challenges require complex and original solutions. Even if teams organise themselves, integration into a larger agile ecosystem gives them the opportunity to get out of their isolation and become part of the whole again, while the company benefits from being able to act leaner and more efficiently on many levels. The fact that companies can never be agile is not bad news. On the contrary, they can benefit on a large scale from the use of agile principles – tailored to their company – by developing a uniform agile culture, creating more interdisciplinary cohesion through stakeholder management and strengthening identification with the products.
To tackle this and bring the agile principles into this decade will pay off for the companies if we implement the mindset where it should go: In the minds of everyone involved.
Notes:
Oliver Fels has published another article in the t2informatik Blog:
Do you believe in agility?
