Scrum is not Agile

More Customers, More Software Development Organizations, More Software Professionals, more than ever before, are today waking up to the "Agile" that was started 6 years ago and called the Agile Alliance . In the haste to embrace Agile, many are suffering in transitioning to a new set of paradigms without first understanding its implications.

The understanding of Agile, sometimes, I feel is so hollow, that some people have started equating their methodologies and tools to Agile. Once such case in point is Scrum. With aggressive marketing and high sales pitch, Scrum, one of the methodologies under the Agile Umbrella has already created 12000 Certified Scrum Masters and plan to reach 20,000 of them by end of this year. So much it has been marketed worldwide, that, today, the perception is that Agile is Scrum and Scrum is Agile.

Organizations are picking up Scrum overnight and scaling it up to Multi-location, Multi-project, Distributed Software Development Projects, without giving due attention to the rationale of its implementation and suffering the consequences.

I named this post "Scrum is not Agile" not to say that Scrum is not Agile. but to say "Agile is not Scrum" loudly. Give me some of your time to understand why I say so. I welcome your feedback and comments.

We all talk about Agile. What is Agile ?

Agile is a "School of Thought" that is best described in the Agile Manifesto. It is a set of Values that provide ways to build good software, faster, cheaper and better, especially, in the face of volatile requirements and unpredictable development environments.

Agile Software Development Paradigms attempt to counter the volatility and uncertainties through iterative cycles of "Speculation-Collaboration-Learning" that enables the participants to minimize the adverse effect of risks and maximize delivery of Value to the Customers.

These Paradigms are built over a set of complex assumptions, the understanding of which is a key imperative , if one wishes to reap the true benefits of Agile.

I have tried to analyze these imperatives to enable those implementing Agile, understand, "how-to" harvest and realize such benefits, efficiently, in their respective software development endeavours.

Where do we start ? Let's start by understanding how Agile promises to deal with the following issues that it targets :

1. Volatile Scope (Customer Requirements can keep changing or evolving over time and we cannot know much of it when we start, yet we should be able to keep the "cost of change curve" , flat.
2. Unpredictive Development Environment ( most of the times, we develop software in scenarios where much of what we need to know, cannot be known upfront. Such uncertainties could range from issues related to technology, team capability, cost/time estimation or even our ability to upfront design a good solution that fully addresses the real needs of our customers)
3. Create higher Value to Customers ( building the right software faster, cheaper and better, with a motivated set of team players)

The "Agile Strategy" employed to achieve this is based on the following four core principles:

1. Customer Collaboration : change the way we work with the customers. Collaborate with them to minimize risks and unpredictabilities. We cannot achieve this through any other means. Agile can work only if Customers and Developers, actively collaborate and work together as one team. To do this effectively, both customer and supplier organizations may have to undergo a serious paradigm shift in their Business Policies.
2. Motivated Team : we can improve the productivity of knowledge workers only through improving their Motivation. We can harness the power of creativity and innovation only through empowered self-organizing, cross-functional teams working in an environment that fosters transparency, mutual trust, informal face-to-face communication, team-play and accelerated learning. To nurture such teams, management policies and managers may need major paradigm shifts in the way we manage people resources today.
   
3. Iterative Software Development: we can produce high value to customers, in an environment of high volatility and uncertainties, only through iterative software development that helps us produce the right software, right through active and ongoing collaboration and feedback from our customers. This is the PDCA approach for continuous improvement in the way we do, what we do. To be able to implement iterative software development, teams may need new software engineering skills that include incremental architecture, refactoring, test driven development, continuous integration, test automation. The engineering managers may also have to undergo a torturous paradigm shift in the way they manage software quality assurance and software quality control.
   
4. Agile Project Management: To achieve this, the way we manage our teams and projects have to change. Agile Project Management introduces the new paradigms of empowerment, servant management and collaborative leadership. It aims at providing the right work environment, the right resources, the right support and the right guidance for the Agile Teams to succeed. For this to work, management of organizations and their managers will have to undergo a total cultural and value re-orientation of how they should be managing projects, people and processes.
   

Now all the four items listed above are critical imperatives for Agile to work. In implementing Agile, we have to ensure that all these four critical success factors are evenly aligned and each is effective, failing which the velocity of the Value streaming can suffer seriously. This is best illustrated by the figure below.


The Value is streamed to the Customers by the Developers through a pipe that has four sections. Each section may be constrained by the effectiveness of that factor in play. Therefore going by the Goldratt's Theory of Constraints, the rate of throughput (which the value stream here), is affected directly by the bottleneck in the system. Bottleneck is the core constraint of the system. So even if one part of this system is not effectively managed, notwithstanding how well the other three parts of the system are managed, we will not be able to improve the rate at which Value is delivered to the Customer.

This is the SECRET that we all need to know and understand before implementing Agile, if we were to HARVEST the true benefits of AGILE.

Coming back to Scrum.

Scrum is only an Agile Project Management Methodology under the Agile Umbrella and addresses only one aspect of Agile Software Development Paradigms out of the four Agile Imperatives described above. It does not address, as it is today, any other critical success factor of Agile Software Development.

So, Scrum Implementers, especially those who do in haste, enlarge only one section of the pipe and are therefore not able to improve the rate of Value Delivery to the Customers, which can only happen when all the four sections of the pipe are declogged simultaneously.

Scrum therefore fails, more often than it succeeds, if it is implemented as an Agile Software Development Methodology in a software development environment. It can only help manage one part of our problems. It is no way a PANACEA.

Thanks for your time. I know we can do better. I sincerely look forward to your feedback and comments. I will be eager to know if this helps in improving the way we can use Agile Paradigms, Agile Methodologies and Agile Tools on our future Agile Projects.