How to keep your team from getting Agile wrong

Twenty years ago, a group of highly experienced software developers, including as Martin Fowler (now known for microservices), Ron Jeffries (extreme programming), Robert C. Martin (now famous as "Uncle Bob") and Jeff Sutherland (inventor of SCRUM) met in Snowbird, Utah for two days to discuss some serious industry-wide problems that will sound familiar to any engineering manager even today: software estimations are often wrong, software projects are always being behind schedule, requirements change mid-development, etc.

What came out of that conference was the Agile Software movement. Unfortunately, what we call "Agile" today (SCRUM, sprints, stories, story points, standup meetings, retros, velocity) look nothing like what this group originally proposed. The entirety of the Agile Manifesto consists of two pages: the four values, and most importantly, the twelve agile principles.

But somewhere along the way, Agile went to the dark side. To demonstrate this point, please do the following:

1. Go to the original Agile Manifesto, and search for any of the following terms: sprint, story, velocity (or any of the terms that you closely associate with Agile). You will not find a single reference.
2. Now go to the official SCRUM guide, and search for the word agile. You will not find a single reference. Search for stories, story points or velocity. You will not find any references. It will only contain instructions on how a team will interact with each other (i.e. the sprint).
3. Design is considered "anti-agile" by some. Now go back to the Agile Manifesto and read principle #9: Continuous attention to technical excellence and good design enhances agility. Design and planning is fundamentally agile because a design is always easier to change than code.
4. Finally, ask members of you team how many of the original agile principles they can name. You will be surprised how many will be unaware of the existence of the principles.

Martin Fowler himself addressed this in his 2018 Agile Australia keynote speech, where he described the current state of affairs as "Dark Agile". We can observe two main types of Dark Agile:

1. A minority of bad-faith engineers weaponizing Agile to avoid technical design and planning responsibilities, and to also absolve themselves of delivery commitments. Attempts at up-front technical design or planning is shut down with the term "anti-agile". The answer to missed deliveries is "well this is the process". The voices of more sensible engineers get drowned out due to this vocal minority.
2. An entire industry of "agile consultants" and "agile coaches" selling their services to companies with struggling software development practices. Rather than developing a deep understanding of the 12 principles and using them to craft a process that works for each organization, they charge exorbitant fees to push a set of prescriptive, mindless processes on teams (which is the very opposite of the spirit of the original manifesto). When this approach invariably fails, the the "coach" blames the organization, claiming that they failed to follow the process perfectly, sometimes even using derogatory, purist terms such as "SCRUM-but".

As an engineering manager, how do you avoid these two pitfalls?

First, open your team's eyes about Dark Agile -- as you demonstrated to yourself above, demonstrate to your team that we have strayed from the original message of the Agile Manifesto's authors. Without this understanding, they will see anything other than the popular "Agile/SCRUM" process as "anti-agile".

Second, identify the two most important principles out of the original twelve, and implement them in your own way. Without these two, the entirety of Agile breaks down. And those principles are: (3) Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale and (7) working software is the primary measure of progress. This does not automatically mean sprints and stories. That is just one interpretation. The most important thing is this understanding:

This famous image by Henrik Kniberg embodies the entire foundation of Agile: frequently deliver small increments of value to your end user. Show them the working product, not project plans, spreadsheets or charts. That is all. Everything else is a process detail which can differ from company to company. For example, at :Different, where I work, we do this by slicing requirements into small bits that can be developed within 3-4 days and demo-ed to end users every Friday. Whether we use the words "story" to describe the requirement or "sprint" to describe the time period, is not important.

Here's another image you can use to drive the point:

Start with these two steps (namely, open your team's eyes about "Dark Agile", and encourage them to ship small, demo-able units of work daily if possible, weekly if not) and you're mostly Agile. If you want to do more, look no further than the remaining ten principles in the Agile Manifesto.