One of the most popular modules of my training, webinars, and presentations is Dark Agile, which focuses on when and how Agile fails.
Dark Agile is a collection of anti-patterns at the team and leadership level; it describes the mistakes that set the environment and foundation for individuals and teams to succeed or fail in an Agile transformation.
Looking at Scrum Master or Product Owner anti-patterns may be educational, but role-specific insight isolates the situation from the rest of your team and organization. In the Dark Agile module, we look at what causes challenges overall.
Below, we consider why the Dark Agile module is getting attention and resonating well with participants.
1. Agile transformations require change outside of teams
Organizations assign Product Owners and train Scrum Masters. Agile ceremony practices start, and the organization expects the promised benefits immediately. When this doesn’t happen, water cooler talk turns cynical—“Agile is not for us.”
Many Agile transformations don’t account for the fact that multiple legacy mechanisms hinder introduced changes. These legacy mechanisms can, for example, be a management culture of command and control, a project funding model, annual incentive planning, a sales bonus model, or an overly stage-gated development process.
Many problems described in the Dark Agile module come from mechanisms defined and used outside of the Scrum team. When Scrum or Agile fails, the methodology and ways of thinking get criticized when the problem lies with the organization’s inability to adjust legacy mechanisms to meet the demands of change in the team.
The Dark Agile module shows development organizations that missing benefits are not a team issue but an environmental one, and wider business change is required to succeed in a transformation.
2. Agile must change and absorb traditional methods to be successful
It’s easier to implement Agile ways of working in environments where full-stack developers are at hand, and the scale of activities involves 10-20 people. Agile becomes more difficult when you scale the product development upwards or introduce dependencies to hardware, third parties, production, logistics, or legacy products in the field.
Situations where team members are highly specialized, and can’t work on just any item in the backlog, call for a different approach to pure, idealistic Agile. Agile must change and absorb traditional planning-based aspects in such situations to succeed. Gantt charts and stage-gated processes can be made to work with Agile methods.
To make this kind of hybrid model work, we need two things. First, Agile purists must acknowledge the need to use traditional project control mechanisms, albeit with an Agile way of thinking. Second, management must recognize uncertainty and change the mindset from controlling to steering activities.
Another thing to take into consideration in this kind of Agile hybrid model is cross-team communication. A common problem in projects shared by Agile and non-Agile teams is that different ways of working can reduce this, but weekly alignment and whole-project daily meetings can help.
In hybrid projects, discussing the need for agility and any uncertainties is essential; what’s being tested or investigated? For Agile working methods to succeed, the entire project personnel must understand the need.
3. Implementing Agile principles in practice can be difficult
It’s human nature to want to belong. During an Agile transformation change, implementing Agile principles and practices can feel difficult; “Am I the only one struggling?” and “Am I stupid for not working in this supposedly better way?” may be questions you ask yourself, but rest assured, others are wondering the same. This should help diminish any doubt surrounding your approach, grasp, or competence and leave you thinking, “I was right; this is not how it’s supposed to work!”
Agile frameworks describe a target state. They paint a picture of a mature, transformed organization that implements Scrum, SAFe, LeSS, or Kanban modes of working perfectly. They’ve clearly defined the roles and responsibilities of the product owner, Scrum Master, and the self-managing team of developers and filled these roles with motivated, experienced, and skilled people.
These individuals will have participated in training, coaching, and mentoring and will have had the time to develop and hone their skills. In short, Agile frameworks do not describe the pain, failures, and individual learnings of the transformation journey.
Embarking on an Agile transformation is akin to enduring the pangs of adolescence, where the pain of growth and change is an inevitable companion. Both processes can be uncomfortable, challenging, and even frustrating at times. Yet, just as teenagers eventually find their way, organizations that embrace the Agile journey often discover newfound strength, resilience, and success.
4. Agile does not guarantee success
By acknowledging that Agile doesn’t guarantee success and looking at how it can fail, you can speak up about the impacts on your organization. I think this is a major reason why the Dark Agile module is gaining such traction.
I like to spend at least half a day on this topic in my training as it creates a safe space to raise problems. Stakeholders and leaders are strongly encouraged to participate in this module alongside Scrum professionals.
5. Agile transformation mistakes
By learning from the mistakes of others, you can avoid repeating them. Nobody sets out to fail in adopting Agile; most challenges come from people believing it to be easy!
Some people look at frameworks for Agile, such as Scrum or SAFe, through rose-colored glasses as they describe the happy path. They state how the organization should work when the transformation is complete, leaving little room for how the journey can create difficulties or even fail, leading to a loss of hope.
Any successful transformation is a learning experience that involves moving from one small failure to the next. It’s important to keep improving, to learn as you go, and to steer your transformation forward. Forget assumptions of instant gains; the real benefits come from learning to fix what doesn’t work.
By acknowledging that Agile adoption isn’t a straightforward process, you inoculate yourself against potential problems ahead and are less likely to quit at the first sign of trouble.
Agile anti-patterns and what they can teach you
A good anti-pattern helps you see the problem and notice what it looks like while providing alternative approaches and ways of avoiding challenges altogether. My goal with the Dark Agile module is to show what a problem looks like, identify pain points, and demonstrate how to attack and survive the situation.
The total value of Dark Agile is achievable if the right people hear the message and identify the common pain points. Doing so allows you to discuss and create momentum to conquer the challenges in your organization.
I encourage you to compare any initiative to improve your agility—processes, working methods, or tool configurations—against these principles.
Published: Jun 30, 2023
Updated: Mar 28, 2024
