Agile has become one of the most misused buzzwords in recent years. Everything seems to become agile and everyone claims to be agile. Have you ever heard someone say, “No, we are not agile”? But what do we actually mean when talking about agility?
The Wikipedia article on agile software development defines agile practices as follows:
“In software development, agile practices approach discovering requirements and developing solutions through the collaborative effort of self-organising and cross-functional teams and their customer(s)/end user(s). It advocates adaptive planning, evolutionary development, early delivery, and continual improvement, and it encourages flexible responses to change. It was popularised by the Manifesto for Agile Software Development. The values and principles espoused in this manifesto were derived from and underpin a broad range of software development frameworks, including Scrum and Kanban.”
The underlying principles of agile software development were already published in 2001 as part of the “Manifesto for Agile Software Development”.
It is an iterative approach to project management and software development that helps teams deliver value to their customers faster and with fewer headaches. Instead of betting everything on a “big bang” launch, an agile team delivers work in small, but consumable, increments. Requirements, plans, and results are evaluated continuously so teams have a natural mechanism for responding to changes quickly. Short iterative cycles (sprints) and reducing overhead and bureaucracy to a minimum and therefore delivering small parts of usable code with a true business value very quickly, is the essence of agile.
Speed is of the essence to be competitive in today’s business environment and that’s one of the main reasons why agile methods have become so popular. However, often agile is misunderstood by business managers and mostly seen purely as an “IT thing”. They often believe that with their IT teams adopting agile methods, projects are simply delivered faster and cheaper with the same scope. However, this is an illusion.
My personal experience going through an agile transformation as a CIO has taught me that to be able to reap the true benefits of agile methods, the whole company needs to become agile ‒ and this requires far more than just transforming IT. It is not enough to simply implement Scrum in IT, run a few projects the agile way, and believe that the company will then gain speed to market.
After we had used rapid prototyping methods for years and had co-located our IT teams with the business units, we started to introduce agile methods back in 2013. We experienced some benefits very quickly; by being able to deliver smaller chunks of ready-to-use software much faster than when employing the traditional waterfall methods. However, when trying to put the code into production, we got stuck with our own IT-internal ITIL-based processes. Our IT operations colleagues, who were rightfully charged to guard the “holy grail” of stable and secure operation, only allowed code to be promoted based on stringent processes and acceptance criteria at predefined points in time, e.g., when the monthly, or sometimes quarterly release cycles were due. We realised that we would only be able to overcome this bottleneck by including IT operations people in the agile teams (squads) and by making them and their processes part of the agile transformation. This was the advent of DevOps in the organisation.
While I see many companies stopping their agile transformation at this stage, as they consider agile to be an IT methodology, we wanted to take it further because we noticed that some other parts of the company were still slowing us down, inhibiting us from reaping the true benefits of agile methods.
Let me give a few examples of such “agile-inhibitors” in traditional, hierarchically organised companies. Any resemblance with actual people or organisation units of any company I worked for are purely coincidental:
I could probably go on with such examples of units and functions within the traditional hierarchical silos, but I guess you got the point by now: You cannot limit agile to IT if you want to benefit from the increased speed to market that agile ways of working offer. Instead, you need to drive the transformation all the way through the company.
Traditional planning and project management methodologies served us well in the past but are today as much of a legacy as the hierarchical structures that serve the bureaucratic processes and group functions of most enterprises. These hierarchical structures with their rigid planning and financial processes originating from the industrial age of the last century (Taylorism) are not suited for – nor are they compatible with – the new agile paradigm.
I observed that in traditionally run projects (waterfall method), teams spend a lot of time waiting for others to do something. In many project review meetings, when questioning why the project was behind schedule, one frequent explanation was “We are waiting for unit A to deliver X”. This can be bound to business units to sign off specifications or test cases, to run UATs, etc., or due to IT internal bureaucracy such as Enterprise Architecture to sign off the solution architecture, Cybersecurity to sign off the risks, IT operations to stage a server, etc., but also due to external factors, like a supplier of an outsourced component not delivering on time.
Why are we spending so much time waiting for others involved in the project?
Simply put, because of the clear task and role separation of the industrialisation approach, leading to multiple handovers and overhead.
A fellow CIO of a European bank and one of the strong promoters of agile ways of working told me a few years ago: “Agile is all about removing handovers. Handovers slow down processes and are the source of mistakes.”
In the novel “The Phoenix Project”, agile is accurately described as being about focussing on simplicity, the art of maximizing the amount of work not done. Similar to lean methods in manufacturing, it is about minimising “work in progress” and avoiding bottlenecks.
In his book “The Delicate Art of Bureaucracy”, Mark Schwartz describes how important it is to remove unnecessary bureaucracy to enhance agility.
In my view, agile is less about diligently following yet another methodology (Scrum, Kanban, SAFe, Holocracy, etc.) and again introducing bureaucracy as about a mindset, focussing on a few principles across the company and not only in IT:
As agile methods already have some tradition in IT, the CIO is well placed to drive the agile transformation across the company and to help the business colleagues become agile, by adopting these principles and by helping them to change the mindset within their organisations. This is an important part of the role of modern CIOs, who wants to add value to their companies and make a positive impact. Today’s CIOs are expected to get out of the back office, relinquish the traditional role of IT as a support unit and to move into the driver’s seat of the agile transformation across the business.
The eleventh part “Reversing the outsourcing madness => back-sourcing, or ‘How much IT to keep in-house?’”, will appear shortly. Questions, feedback and comments are highly appreciated:
Resources:
Fragen, Feedback und Kommentare zu diesem Beitrag senden Sie bitte an p.naef@acent.de
Patrick Naef | 14.01.2021
