Is the end of Agile near?

We all knew this day would come. Agile is slowly but surely reaching its end. What started as an enabler for IT to deliver value at speed, is now evolving into its own downfall. In this blog, I take a view on what this means for the IT industry and the way forward.

Agile is defined by the agile manifesto as the combination of four values and twelve principles, underlined by the following:

1. that value is only what is in the hands of the customer,
2. that achieving delivered value should be done in small steps by an autonomous team.

Classical Agile becomes Modern Agile

Primary an agile team consists of three roles: The product owner, the scrum master and the team member. Usually, an agile coach is added to the team dynamic as an outsider to help the team become autonomous and be able to identify the client (end-user) of the team. To combination of values, principles and roles can lead to a non-agile way of working, therefore the US Department of Defense created a flowchart to put all things agile into perspective.

Having said this, it is not easy for an IT organization to become agile. Group dynamics (Modern Agile) and organization redesign are two main factors that come into play. Modern Agile puts the wellbeing of the team and the person central in the group dynamics. Modern Agile is an example of the agile mindset evolving away from Software Development and into Agile enterprises. This also changed the dynamics of delivering value to the end-user.

Existential Questioning

The evolution from agile in IT only to Agile in enterprise leads to the following existential questions: “Who is the real end-user?”, “What is the real value we deliver to the end-user?” and “What is needed for us as a team to deploy to production by ourselves?”. Are we delivering value to the internal end-user? Is the internal end-user not just a means to deliver value to the end-user outside of the company, who pays money for the delivered service? Would that end-user (the consumer) not be the real end-user?

These are easy questions for a pie-shop or a small startup, but these questions are quite complex when you are 4,000 people financial organization or 3,000 people IT Consultancy company. For most large organizations, it is difficult to de-clutter (Marie Kondo) their organization processes to enable autonomous value creation. If the organization is a (kafkaesque) maze of processes, then how can an autonomous team exist? How can you as a team move freely and fast when you are tied and bound by internal clutter?

Organization Redesign (shifting the money)

For IT organizations, it is common to be functionally organized, that is to say, projects are created as small organizations with the objective to change the run-organization. The run-organization within IT is formed to create a robust organization in application teams. The conflict between change organization and a very robust run-organization was one of the drivers for agile.

From Run & change organization into DevOps.

Organization redesign facilitates the merger of the change and run-organization (projects and maintenance). This merger finds its optima forma in DevOps teams of a maximum of 7 people.  Next after the merger of these organizations comes demand of different budgeting of the standing organization and change organization since they are now one (budget).

When the change and run work is organized around the optimization of flow within a team (kanban, scrum), then administration of hours spent on specific tasks per person loses meaning. This means calculating on Time & Materials ceases.

DevOps is also about autonomous L&D

When teams function autonomously, they themselves can decide on which technology stack they need and which skills are missing. This means that a large volume of technical architecture documents and a central Learning & Development strategy also ceases to exist. The new role of Architects and L&D Professionals is to inspire, facilitate and coach.

This change from projects to DevOps costs a company an average of 3 to 4 years and only after that comes from the steps about how to budget forecast, and support autonomous teams on architecture and L&D topics.

Into DevOps is only the beginning of the journey

Autonomous teams evolve. From Agile Dev, Agile DevOps and Agile DevSecOps onto BusDevSecOps (Squads). The ultimate goal of agile is an autonomous team (or group) responsible for the whole lifecycle of a product or service.

Organization Design is not about IT but about Value Creation

When we look at which functions an enterprise should have, we can look at the value chain of Porter or the Business Model Canvas of Osterwalder. HR and Finance are part of the responsibilities of an enterprise. The value created for an end-user is created by the whole of the value chain. Agile teams are responsible for the value provided to the end-user, and thus also responsible for the value creation in their value chain. This is where the dilemma starts.

In IT we usually only focus on the stack (technology and their functioning) but in the end, it is also the responsibility of the autonomous team in which way the value chain is organized. All should be focused on value creation for the end-user.

In a bank, for instance, this also implies being compliant, but in the end, it doesn’t matter if the payment engine is from the bank itself or from a payment service provider that provides the same compliance for the bank.

The Agile dilemma

A team is thus autonomous in all areas of the Value Chain / Business Model Canvas (BMC), which basically makes a team a small enterprise.

Introducing Agile into an enterprise to become more agile, results in a collection of small enterprises that work autonomously. And since a Value chain / BMC is composed of more than only IT development, this small company should be of more than 7 people. Otherwise, every team would only have 1 or 2 developers and would not mature more than a small startup.

This is the dilemma: to become agile you need to create small teams that evolve into bigger teams that evolve into enterprises which evolve into bigger enterprises which evolve into … and around we go.

Agile is not more and not less than a way to break the complex organization design we created and evolved into something different. It brings the conversation back to “why are we doing things?”.

This is also the power of Daniel Pink‘s story about Autonomy Mastery Purpose (2010) and Sineks’ speech on the Power of Why (2010). Other great writers before them already wrote about this, but it is the timing that brought Pink, Sinek and Agile together in these last 10 years.

And now it is time to move on…But to where?

The driving forces for (global) change

To put things in perspective. Agile became a thing because big companies became too big (mammoth oil tanker), providing services that could be provided by a startup of four people.

This resulted in the global startup frenzy, the design to disrupt movement, etc. But it was not all for the gain, it was also for survival. There are not enough programmers, there was an economic crisis (2008) that hit big companies hard, and the world entered and probably will never leave a state of volatility, uncertainty, complexity and ambiguity (VUCA).

VUCA is here to stay

Our world is not kicked into a (r)evolution by a crisis every 8 years, it is kicked non-stop since we live in a VUCA world. This is caused by the following: the internet connects the whole world, the software is eating the world, the world is a web of interconnected complex supply chains, the global financial system is a fragile monolith, and the social media empowered many people across the globe. In other words: The movement of words, money, goods, services, people across the globe has become very easy, cheap and fast. This will not be undone, and therefor VUCA will not be undone.

The original driver for an organization to become agile is not gone, it is here to stay.

In the old days, a robust company was enough. A company with a high credit rating, and not putting all its eggs in one basket was a place you could work until your pension.

Those days are gone. A robust organization is now the same as a fragile organization. An organization should be adaptive to have a future in the current world.

There are still a few good and old big companies, but they are struggling. The new kids like Apple, Facebook, Google, and Amazon are also struggling. Struggling to keep people aboard, to keep innovating. And let’s be real Google and Facebook are the new robust companies here to be disrupted. Both companies have trouble keeping up with regulation (GDPR etc), and that in itself is saying something.

So where to then?

If we are living in a VUCA world of which the velocity will continue to increase, and if we want to be part of a company that can survive the unexpected events,

Then the only way forward is to create companies that are small in functional design and able to move and change along with the events.

A company should be resilient in such a way that the function of the company can change in response to an unexpected event.

Someone of Bol.com (Dutch version of Amazon) stated: “We do not have a stable business model as a company and we will never have this. We are non-stop learning and evolving.”

This demands a different way of defining your company and your organization design.

That will be the next step in our evolution of enterprise design:

• from agile to resilient onto antifragile;
• from money and product as purpose onto a holistic approach to purpose;
• from complex enterprise-wide processes onto small (emergent) teams that just are and are not.

Food for thought: Ripping off the bandage in one quick motion is not better for the patient (or worse), it is better for the nurse. That is why this is preferred.

Want to talk about this with people that know more, email me at edzo.botjes@sogeti.com