What Agile Manifesto didn't tell us

To kick off 2024, let's spend sometime to revisit Agile Manifesto and explore the myths and facts.

On February 11-13, 2001, at The Lodge at Snowbird ski resort of Utah, 17 people met to talk, ski, relax, and try to find common ground of improving product development, what emerged was the Agile ‘Software Development’ Manifesto.

Representives of Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others sympathetic to the need for an alternative to documentation driven, heavyweight software development processes convened.

Almost 23 years later, Agile Manifesto is still very relevant and it is the roots of all agile or scaling agile frameworks.

FACT 1: Agile ≠ fast

Principle 1: our highest priority is to satisfy the customer through early and continuous delivery of valuable software        

Agile will not make a 3 years program delivered faster, however with early experiments, inspect and adapt with hypothesis driven MVP, agile delivery can reduce risks in the delivery through close collaboration and early emergent of information, empirically, that ultimately contribute to success of a project, continuous delivery is not free, and require hard work to build continuous delivery pipeline from exploration of new ideas until release on demand, as a result reduce wastes.

It is the reduction of delay, that leads to speed.

FACT 2: welcome change ≠ accept change

Principle 2: welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.        

Agile doesn't mean the team accept any work that is coming towards the backlog, especially when capacity is full, rather, an opportunity to verify if we can deliver more value for customers, think like this:

If you are a cook in the kitchen, customers start asking you to go out and fishing in the ocean, do you start laughing the boat, or rather ask customer what exactly is the problem to solve. In fact, in most cases, customers are not the ones who can describe their problems clearly and accurately, this requires close collaboration to diagnose and investigate, before team can take actions, to strike a balance between welcoming change and knowing what to do.

FACT 3: end of an iteration is not the only time to show customer working software

Principle 3: deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.        

Principle 4: Business people and developers must work together daily throughout the project.        

Nowadays thanks to the rapid development of ABC, AI, Big Data and Artificial Intelligence, deployment can be made in seconds compared to months or even years in the old legacy systems.

Even we present the working software through iteration review at the end of an iteration, but this is not the only time to get feedbacks, rather, we shall work closely with customers, find out a way to fast verify changes in a sustainable way, again, to strike the balance between showing customers what we created vs. when early feedbacks are most valuable.

FACT 4: create a holding environment with psychological safety is a leadership's responsibility

Principle 5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.        

Nowadays companies are promoting agile ways of working, for a simple reason to attract talents, however in practice, that developers might not want to work in agile, or leaders are overwhelmed with demands, scrum masters are not experienced, and teams are disoriented, the nice promise of agile world on PPT is far from reality.

Cultivate a psychological safety environment, is critical to unlock the intrinsic motivation of knowledge workers, such as autonomy, master and purpose, for leaders.

Leaders gain?earned authority by modeling the desired behaviors for others to follow, inspiring them to incorporate the leader’s example into their development journey. Leaders?lead (rather than support) the transformation by creating the environment, preparing the people, and providing the necessary resources to realize the desired outcomes.

In other words, leaders plays a fundamental role when shifting to agile, and organization will produce a system that is the reflection of their leaders. Psychological Safety is not a given but requires deliberate effort and behavioral change by taking small steps.

FACT 5: face to face interaction is irreplaceable even for distributed teams

Principle 6: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.        

Whilst co-location is the common standard for self-organizing agile teams, it is not always possible due to distribution of teams and/or individuals, especially during COVID 19. According to Mckinsey, the pandemic accelerated existing trends in remote work and automation, even with up to 25 percent more workers than previously estimated potentially needing to switch occupations.

As working from home becomes the new habit of many agile teams, it is essential to organize regular team time together, for large organization with distributed teams, considering coming together in a PI Planning as much as possible. Face to face interactions improve trust and accelerate problem solving.

FACT 6: phase-gated milestone planning creates illusion of certainty

Principle 7: Working software is the primary measure of progress.        

Principle 8: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.        

In Agile Manifesto, "working software over comprehensive documentation", that is, while there is value in the items on the right, we value the items on the left more, but in reality, often PPT is used instead.

There was in fact no correlation between exiting phase gates on time and project success… the data suggested the inverse might be true - Dantar P. Oosterwal

For the record, we still need to use PPT in order to set context and senior executive engagement in most occasions, so PPT itself is not the problem, rather the mental model behind PPT: a phase-gated approach, that is often disconnected with reality, like watermelon effect.

Instead, the system must be built in increments, each of which is an integration point. Each integration point demonstrates evidence of the feasibility of the solution under development, at regular predictable interval, such as an iteration or a PI.

FACT 7: best architectures emerges from self-organizing teams, but if at scale, think again

Principle 9: Continuous attention to technical excellence and good design enhances agility        

Principle 11: The best architectures, requirements, and designs emerge from self-organizing teams        

You can achieve Agility without scrum, but can't achieve it without extreme programing. Technical Agility, requires close collaboration between business and IT development, engineering, architecture and infrastructure, applying XP practices such as BDD, TDD and pair programming.

However best architectures in large organizations, are not always just emerged from self-organized teams, rather a combination between intended architecture and emergent architecture.

Agile Teams apply emergent design through the development that incrementally evolve their parts of the solution. However, there is typically lack the breadth of knowledge of the end-to-end solution that would allow them to design components and infrastructure across all domains effectively.

Many of these design factors are simply beyond their scope of responsibility. Not to mention that it takes time for teams to grow expertise, and large organizations have multiple vendors with vastly different maturity level, therefore just let team design architecture is not sufficient.

FACT 8: replicate agile teams ≠ scaled agile

Principle 10: Simplicity--the art of maximizing the amount of work not done--is essential        

You might be able to successfully shift to Scrum in your technical delivery, but when you replicates scrum teams at scale, soon you will realize that it is not efficient in delivering value to your customers, why?

Scaling agile is a complex endeavor, combing many different domain from organizational design, organizational psychology and system development together. In other words,

"adaptive complex system", any part and their interaction creates unexpected side effect, solutions might soon become problems, when you try to implement new processes, it soon also become problems.

The principle of "simplicity", is perhaps the most underestimated and mis-understood principle: it doesn't mean that we don't introduce new practices or processes, rather, following the idea of "first principle", drill down to the fundamental truth and reason up from there, create hypothesis to maximize the work undone to verify and test outcomes.

To summarize,

Agile is more than just a framework, it is a collection of values and principles, and the practices and processes applied are context specifc, while agile values and principles are context free, Northstar when we are looking for solutions in adaptive complex systems.

To combine practice with theory, it requires discipline, continous exploration, conduct small experiements and expand.

For more information on this subject, check out my previous article here .

Source: Ahmed Sidky, Scaled Agile, LeSS, Agile Manifesto