Agile has run its course. What next?

The fact that a lot has changed in the organization of IT, owes an awful lot to the emergence of Agile and its Manifesto in 2001. It claimed to be disruptive and indeed it was, but also to the extent of creating new conflicts by way of becoming idealistic. Some organizations landed in a cul-de-sac of ideology, from which only the ubiquitous “change management project” with all its pains and opportunity costs was the only escape.

I believe this is what happens when the ideology becomes the central reason for being. The vision - which primarily was to increase production, reduce time to market and avoid mistakes instead of fixing them - got lost in dogmatic arguments between “changers and traditionalists.”

The term disruptive as defined in the in the business context in Cambridge Dictionary states the following:

Changing the traditional way that an industry operates, especially in a new and effective way

(There is also the general definition that reflects the way some Agile changers saw their brief… but that is for another blog to deal with).

I believe the key part of this definition is “Changing the traditional way…”  Changing does not imply wholesale replacement or turning everything on its head, but instead taking what is “traditionally” available, evaluating what works and what does not, then moving forward on a journey of continuous optimization. This is the way effective change management works. It is however a very process orientated - and valid - approach. But effective organizational change management also respects that there are people involved, people with varying degrees of needs and values that will – and should – influence the change process.

The Agile Manifesto states “Individuals and interactions over processes and tools” – a statement that is so often crudely simplified to “people before processes.” The mere word “over” introduces a polemic into the statement that in turn disregards the context of business and how people operate in value chains, which are the life support systems of companies. As this over-simplified phrase passes through organizations as an ideology, it provokes the continuous outlawing and abandonment of processes.

There are and there always will be processes in the working context. Organizations need frameworks for their members and stakeholders to attain – and maintain – a common understanding across the board. This common understanding delivers the orientation that people need in order to interact with one another.

Returning to the vision of Agile, what is expected as a result of change to technology organizations? In short increased production, higher quality and faster time to market. The Agile vision took this paradigm and said, well if the domain of conceiving, building and improving the product is solely within the Dev-Team, then the resulting strategy places the accountability for the product in the Dev-Teams. The results will follow as a matter of course.

But, what this Agile vision failed to consider is that Dev-Teams have no sales, marketing and business competence and cannot therefore be accountable for the whole value chain of the product. The simple answer to this caveat is... the Product Owner takes care of all that. This is an impossible set of tasks – even in a 60-hour working week. The Agile definition of the Dev-Team made no provision for supporting the Product Owner. Traditionally a Project Manager is the support, taking care of processes and managing the organizational interfaces to sales, compliance etc.

But the Scrum Master replaces the Project Manager with a role that does not assume accountability for these tasks, thus resulting in a support gap for the Product Owner. Which takes me back to “the traditional way” and how it has been discarded by an overbearing ideology. The Project Manager role worked fine in the past, which in my opinion has become blatantly obvious, as the role has been discarded in changing to Agile. A deciding factor has banished along with the role: Leadership.

Agile has no provision or any thought on leadership and in fact more or less rejects the concept as out-dated, unnecessary and restrictive. Organizations and their Teams without leadership become dysfunctional over time. In the very first chapter of Peter Drucker´s The Practice of Management (Harper & Row, New York 1954) he writes, “the role of management is to turn resource into production.” It may sound traditional (well he did write this in the 1950´s) but is a core objective in businesses. The meaningfulness is in the how one chooses to translate the statement into particular contexts. The role can be the Project Manager. The resource is the Backlog. The production is the end result, i.e. the market deployment of the product. Agile maintains this is what the Dev-Team can do autonomously, yet without all the skills and interfaces along the business value chain. Operations remain a different department in the organization. DevOps rightly improves this immensely by removing the interface and allowing the Dev-Team to deploy and monitor the product in the market. But other organizational interfaces still prevail – and will continue to do so. They need to be managed! They need to be led!

The Scrum Master missed the opportunity of becoming the new leadership role in self-regulating teams. The role is just too shallow and devoid of accountability, so that it falls far too short in providing the necessary skills in leading teams to becoming self-regulated and high performance. The opportunity has passed, the train as left the station and the Project Manager role combining the attributes of incremental organization of work towards targets and deadlines, coupled with lateral leadership qualities to bring teams up to expert level – and beyond – is now highly sought after. Some companies now call this role Delivery Lead, some Agile Project Management. Whatever, the brief is clear and perhaps discernible in my suggestion of a continued improvement to the Agile Manifesto:

Through improvements we have come to value:

1. Individuals and interactions with supportive processes and tools

2. Working software with a required level of documentation

3. Customer collaboration founded upon contract negotiation

4. Responding to change by adapting the plan

You may say you read it here first!