Introduction

Once upon a time, there was a ski resort in Utah. It was 2001, and 17 practitioners/advocates of flexible programming found that they had more in common than not. The result was the Agile Manifesto, and the Agile Movement was born. The Agile approach delivers solutions of demonstrated business value, through a collaboration of self-organizing and cross-functional teams. It advocates adaptivity, evolution, and continuous improvement, creating an environment that responds rapidly to change. Not surprisingly, Agile itself has adapted, evolved, and improved.

Image courtesy of dandypeople.com

Cut to 20 years later, Agile has become the “new traditional” process for development. The main Agile variants (Agile, Scrum, eXtreme Programming) have grown to the point where 91% of US companies are at least partly Agile.

These variants have their own rituals, but still have more in common than not. I like this old study that shows four basic practices at the core of the variants: daily standups, retrospectives, iterative/incremental, and test driven development.

The Children of Agile

There have been a number of methods that have influenced, and been influenced by, Agile: DevOps, Theory of Constraints, Lean, Phoenix Project, Cynefin, SAFe, to name a few. I will explore what they are, and when they should be used below.

DevOps / Continuous Integration – Agile introduced the theory of iterations (bi-weekly, monthly, etc.), but found that delivering into (non-Agile) production was a challenge. DevOps started as a method for explicitly bridging the rapid release cycle of Agile safely into production, and is now a sub-discipline of its own. Continuous Integration is the discipline and toolset supporting daily builds of developed code, feeding into DevOps.
Good for: Rapid, lightweight applications like Web, mobile
Bad for: Waterfall enterprises

Lean – Adapted from the Toyota Production System from the manufacturing world, Lean was a method based on waste minimization without sacrificing productivity. Lean also focused on unevenness in workloads which tends to be a cause of bottlenecks in production settings. Lean was then adapted to software development and considered a subculture within the Agile community. It is based on seven principles:

1. Eliminate waste
2. Amplify learning
3. Decide as late as possible
4. Deliver as fast as possible
5. Empower the team
6. Build integrity in
7. See the whole

Good for: Iterative, incremental improvement of existing processes
Bad for: Reimagining a new process or workflow

Theory of Constraints – This theory addresses bottlenecks in production settings and which bottlenecks cause the most delays. The challenges are the usual: time and resources. The idea behind the theory of constraints is that every process has a constraint/bottleneck. Focusing effort on clearing/improving this constraint will be the fastest and most effective path to improved results. (Image courtesy of leanproduction.com)
Good for: Production, Operating environments
Bad for: Panicked environments not interested in learning new things

Phoenix Project – Okay, so this is a book, not a method. But it explores a mashup of the Agile, Lean, and Theory of Constraints. It proposes combining elements from the different methodologies to create a custom cocktail for your projects. The Phoenix Project is a novel that introduces and explores “The Three Ways” to do just that:

1.      Emphasize the performance of an entire system as opposed to the performance of a single department,

2.      Create feedback loops for easier communication and correction, and

3.      Finally create a culture of continual experimentation.

Good for: Everything
Bad for: Something not covered in the story line of the book

Cynefin – Cynefin (pronounced KUN-iv-in, a Welsh word meaning “habitat”) is an interesting framework initially created by David Snowden at IBM Global Services in 1999. It focuses more on how you make decisions for a company and how the ideal state is determined by balancing both company requirements and people’s behavior. The framework offers five decision-making “domains” that help managers perceive environments and understand their corporate behavior. (Image courtesy of Wikipedia)
Good for: Crisis Management
Bad for: Dogmatic structured environments

SAFe – Agile began and grew in the world of Web and smartphone applications, only later addressing legacy applications and large-scale programs. SAFe (Scaled Agile Framework) is meant to guide companies in scaling lean and agile projects to accommodate longer planning horizons and multiple teams. SAFe generally takes a “Big Picture” look across multiple workflows or workstreams. SAFe took the basic principles of Agile and added in product management, governance, and multiple program and development teams working simultaneously. This has slowly become recognized as the more common approach to scaling development projects. SAFe is a broad framework; expert practitioners typically “cut it down” for what is needed for particular programs.

Summary

A quick Google search will render hundreds of thousands of results on everything from dissecting the Agile Principles and Frameworks to a myriad of success and failure stories. This TIP outlined a few of these frameworks. Here is the guidance compiled into a single table for comparison.

Remember, each project requires a different framework and each framework requires a different implementation. Your single most important step for successfully navigating and executing that implementation is formal training and working with a Coach who has implemented Agile many times in the real world.

Trexin is here to help.