Agile… This is the way | Fighting the Emergence of Dark Agile
If you are a fan of the Disney Plus series The Mandalorian, you are likely familiar with the somewhat strange religion which the main character, “Mando” or “Din Djarin” (portrayed by Pedro Pascal), holds sacred. It seems to be full of guiding principals, practices, and rules which always pop up in the show followed by Mando reciting the phrase, “This is the way”, then a chorus of all the other Mandalorians present repeating the same.
This struck me as all to familiar, not because I make it a habit of Bounty Hunting across the galaxy with a band of helmet wearing crusaders, but because I work in software development and this seems exactly like how many people treat Agile. The Scrum Master, or some other member of the team will say something like, “The Development Team must collectively estimate Story Points during Sprint Planning… This is the way”, then all the developers will speak in unison, “This is the way”. Or, something like that.
I think often times what is being portrayed as “the way” is “a way”, and often a successful way, but it is not necessarily Agile in its own right. Usually people are describing a practice in one of the many Agile frameworks. They are presenting the practices as the religion, instead of the values they fulfill. This is very much like being a Mandalorian and knowing that you have to wear a bucket on your head, but not knowing why. You are technically doing the right thing, but since you don’t understand why, you’re not really getting the benefit. You’re just wearing a bucket on your head and because of this, it’s easy to miss when you’re not following “the way”.
Agile is a set of values, completely agnostic of execution. Specifically, it is these values:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan— The Agile Manifesto
These values overarch processes and decision making. They are not rules and practices for developing software. The rules and practices come from the Agile frameworks (Scrum, XP, Kanban, SAFe). The frameworks give detailed instructions on how a team can learn to think in Agile ways and foster Agile values. They are not in themselves Agile. They are tools which, when used correctly, can support Agile values.
Dark Agile
The problem is when a team begins to use an Agile framework incorrectly. The team begins to focus more on their adherence to the process than they do to staying true to Agile values. This is Dark Agile. The team presents itself as Agile and believes it is practicing Agile, but it is not. It is practicing a framework without the support of Agile values. This can lead to micromanagement, a squashing of adaptability toward customers’ changing needs, and an extreme lessening of the benefits gained from an Agile practice.
There are three common symptoms which appear when your process is starting to drift towards Dark Agile.
- Discovery begins to be sequential, where requirements drive design, which in turn drives code. This is in opposition to the work being defined and designed collaboratively.
- The expected results begin to be outputs, as opposed to business results (outcomes).
- All risk is at the end of the process, in opposition to risks being addressed up-front, as early as possible.
These symptom can manifest themselves in many ways. The change usually comes from the top down. Deadlines will emerge for specific features. The team will begin to be told what to build and not what problems to solve. Management, or the Product Owner, begins to pressure the team to get more done, more quickly. Basically, the team is not allowed to self-organize, or be involved in the planning process.
It could be that the development is completely Agile, but the discovery process is not. Discovery becomes a process of someone having an idea, it making it onto the roadmap without validation, the Product Owner exhaustively gathering all requirements needed, design putting makeup on it, and it being sent to development to build. There is no testing or validation of the idea before development. Once it gets to the developers, they begin the first part of the project which is Agile, but by this point it is too late. There is no testing of assumptions before development. All risk is still being saved for the end of the process.
It’s easy to fall into these bad habits, especially if you are working in an organization where the rest of the business is operating in non-Agile ways. To fit into the organization’s planning activities, the development group is asked to make roadmaps and commitments, so that the other groups in the organization can plan accordingly. Dark Agile can become unavoidable.
Fighting Dark Agile
To fight the ever encroaching darkness, development teams must be fierce in their fostering of Agile values. They should trace their practices back to their root in Agile values and socialize this link often. The values of Agile should be the lens through which strategies and decisions are viewed. Frequent and detailed discussions of the values, and how they apply to daily situations, should be encouraged. In addition to this, a focus on the three principles which combat the common symptoms of Dark Agile should be observed.
- Risks are tackled as early as possible in the process, instead of at the end.
- Work is defined and designed collaboratively, rather than sequentially.
- The focus is on solving problems, not implementing features.
It will be hard. There is no silver bullet for conquering Dark Agile, only a relentless pursuit of instilling Agile values. You have to make sure your Mandalorians know why they wear their armor, not just that they should. Dark Agile is easy to fall into because it is the easier path. throwing un-validated ideas onto a roadmap and pushing a team to meet arbitrary deadlines is easy. Spending everyday developing your team’s understanding of Agile values, testing assumptions early, collaborating on schedules, and working closely with customers— these things are hard. But with this hard work comes the greatest rewards.
The most successful teams are not successful because they have one easy practice that solves all their problems. There is no silver bullet. The most successful teams are successful because they work hard, they don’t sacrifice their values, they persevere and they understand why they wear their Agile armor.
Sources
Agile Manifesto — Is the Agile Manifesto still a thing?
by Claire Drumond
Dark Agile: Perceiving People As Assets, Not Humans
by Pernille Bjørn
INSPIRED: How to Create Tech Products Customers Love
by Marty Cagan
Manifesto for Agile Software Development
by 17 Authors
