A statistician, a veterinarian, and a physicist are at the horse races. Being gamblers, they are trying to decide which horse to bet on.

“We should tabulate their previous performances to determine which horse has the highest chance of winning,” says the statistician.

“No!” says the veterinarian. “We are not betting on the past; we’re betting on the present. We need to examine the horses today to determine which is the most physically fit!”

The physicist scratches their chin, and says “Well, assuming the horses are each perfectly spherical and traversing a vacuum…”

Perfectly spherical horses aside, similar debate often rages regarding agile project methodologies e.g. Extreme Programming (XP), Kanban, Rational Unified Process (RUP), Scrum, etc. Each Agile methodology takes a unique approach in adapting the Agile Manifesto, and the associated 12 principles.

In a world full of different approaches, each with passionate advocates, how can we choose the “best approach”? Furthermore, with organisations frequently adopting the technologies and terminology of agile methodologies, but not adopting truly agile ways of working, is picking a “best approach” enough?

I invite you to take a quick journey with me back to the 1990’s in search of answers, during a time when Mixed Martial Arts (MMA) was being shaped into the sport many of us recognise today. At its inception the Ultimate Fighting Championship (UFC) marketed tournaments as real-life tests to determine which martial art was the most effective in fights with minimal rules.

UFC 1, an 8-fighter tournament held in Denver Colorado on 12th November 1993, featured experts representing numerous fighting styles including savate, sumo, kickboxing, kenpo, boxing, wrestling and taekwondo. Ultimately Royce Gracie, a practitioner of Brazilian Jiu-jitsu, triumphed. Royce dominated these early UFC events, winning the 16-fighter tournament at UFC 2, and the 8-fighter tournament at UFC 4. He withdrew due to exhaustion and dehydration after winning a bout against a taekwondo expert at UFC 3. And fought to a draw, after 36 minutes, in a singles match against Ken Shamrock, a wrestling expert at UFC 5.

MMA has progressed a long way over the last several decades, and Royce has since retired from active competition and has been inducted into the UFC hall of fame in 2008. His success in these early UFC events cemented Brazilian Jiu-jitsu as an effective way to win against bigger and stronger opponents. Nowadays professional MMA fighters have their own specialities but, importantly, also a solid grounding in multiple disciplines including Brazilian Jiu-jitsu, boxing, wrestling and kickboxing. No professional cage fighter in the modern era restricts their thoughts and movements to a singular prescribed fighting style.

When it comes to the different agile methodologies, we would do well to look past raging supremacy battles. Those who advocate specific agile methodologies commonly have significant time and monetary investments in them. Investments that can encourage them to overlook the inherent limitations of their chosen agile methodology. If all you have is a hammer, everything looks like a nail.

Instead, we should internalise and appreciate the core practises of the various agile methodologies e.g.

• Pair programming in Extreme Programming (XP).
• Feature teams owning feature development in Feature Driven Development (FDD).
• Fixed time-boxed project phases in Dynamic Systems Development Method (DSDM).
• Early architecture design in Agile Rational Unified Process (Agile RUP).

While simultaneously internalising their respective pros and cons. With a deep understanding we can be creative in making incremental changes towards a bespoke agile approach, focusing on realising better outcomes for individual, teams, and ultimately organisations. To use a music related analogy, the goal is to create a playlist of the best songs rather than remaining committed to any individual album.

A gentler first step for teams new to bespoke agile is to identify issues, and then trial the relevant core practises as possible solutions e.g.

• Teams looking to share knowledge of the code base could trial pair programming, as prescribed by XP.

• Teams struggling to ensure development remains aligned with stakeholder expectations could trial having a designated advocate for stakeholders assume the role of Product Owner, as prescribed by Scrum.

• Teams requiring better visibility of workflow can trial using a Kanban board. This can be trialled quickly and cheaply by using marker pens, sticky notes and a wall/whiteboard.

Teams exhibit disparate levels of maturity in their adoption of agile practises and their ability to self-organise. More experienced teams should be encouraged to deviate in nuanced ways from the guidelines evangelists of specific agile methodologies can be in the habit of mandating. These teams can benefit from trialling ad-hoc changes to their current agile approach, to directly address their specific needs. Examples include:

• Teams vary wildly in their ability to write and execute good stories. It is important proficient teams are trusted to continue to autonomously create stories at a pace that ensures valuable work is readily available. In such instances, the length and frequency of story related meetings can be reduced to allow the team to make better use of the time. Conversely, teams that struggle to write stories may require more hands-on assistance. Trying to identify the main source of the difficulties e.g. struggling to break down complex tasks into smaller ones, or not identifying clear requirements, etc. is key. We can adapt the content of the meetings to address the specific issues, but also trial increasing their duration and frequency.

• I have witnessed several teams push meetings reflecting on their performance and processes into the future, indefinitely. Similarly, other teams have the meeting just to go through the motions. This has proved detrimental each and every time. Fostering an open and safe environment is key, as does feeling free to pick a format that fits the team. In fact, a different format could be used every single time to maximise engagement, keep the ideas flowing, and preventing the experience becoming stale e.g.

  • If you could pick one thing to appreciate others for their efforts and contributions to the completion of your tasks this development cycle, what would it be?
  • If you were a time traveller, what message would you write to your past self before this development cycle started?
  • If you could ask a fairy for one wish to fix the biggest issue during the development cycle, what would you wish for?
  • How would you describe the hardships you overcame and strategies you employed in doing so, in the style of a survival story?

• A weird quirk of language is for concepts to be described and understood but still leave people with disparate interpretations. For example, “tall mountain”, though a simple phrase, leaves our imagination to fill in a lot of the details. This is often exacerbated in larger organisations by different stakeholders using different terminology for the same concept. In instances where clarity is required, software demonstrations, with carefully chosen attendees, and clear agendas, can be hugely beneficial. A lot can be communicated very efficiently, with everyone’s individual interpretations aligning more closely.

• Another useful practise is observing the meetings of other teams. This can be a cost-effective way to expand your knowledge of agile methodologies, especially in larger organisations. A lot can be learned from other teams that can be trialled when iterating your own bespoke agile approach. It can also have other non-obvious benefits for the department including fostering collaboration, knowledge sharing, and helping identify areas where teams can work together more efficiently.

Of course, the road to achieving bespoke agile can be a difficult one, especially if there is resistance to agile principles within the workplace, or a fundamental misunderstanding of them. Those aside, here are some other common pitfalls that I have helped other organisations navigate:

Firstly, in the same way each beach is unique and is constantly being reshaped by natural forces, each team is unique and is constantly being reshaped by its members and other key stakeholders, each with their individual diverse perspectives, experiences and talents. Teams are further influenced by the complex problems they are solving (changes in the nature of the work, scope, deadlines, budgets, etc), and the organisation (its values, goals, etc). Moving towards a bespoke agile solution that addresses a team’s specific needs is a constant challenge. A “best” bespoke agile approach cannot be adopted in perpetuity. Iterating a bespoke agile way of working for a team is a journey and not a destination. Additionally, bespoke agile approaches cannot be transplanted wholesale between teams and presumed to have the exact same outcomes.

Secondly, change for change’s sake should be avoided. Disregarding the use of periods at the end of a sentence would be a novel bespoke approach to writing this blog post, but not conducive to your understanding of it. Ideally adjustments to a team’s bespoke agile approach should have an expected beneficial outcome, and a review date. When reviewing the trialled changes, it is important to consider two; whether the change has been adopted as expected, and whether the outcome has been beneficial.

Sticking with the theme of teams iterating and adapting. We can consider how to put more focus on further empowering agile teams to make better use of their untapped potential. Some decision theory popularised by Amazon founder Jeff Bezos around 2015 is that of “one-way door” and “two-way door” decisions. A one-way door decision is consequential, important and hard to reverse once made e.g. carbon neutrality commitments, or Greggs replacing the pizza slice (a uniquely messy/greasy offering in comparison to its pasties) with a pasty-sized calzone. A two-way door decision is easy to reverse e.g. changing the navigation menu of a website, or changing the time of a regularly occurring meeting.

Self-organising agile teams are regularly given limited freedoms to trial two-way door ideas at their behest such as allocation of work, code base changes, meeting scheduling, etc. However, I think more can be done to redistribute decision-making to the teams who are directly doing the work. In my experience empowering teams to more autonomously employ low-risk, low-cost, creative solutions to two-way door decisions can result in spectacular wins.

Low risk - not to be confused with risk free. “Controlled experimentation” might be a less succinct but more accurate description. Betting small, learning quickly and iterating. Failure is inevitable, but big losses are not. If an idea works, keep it, if it doesn’t, it’s a small loss resulting in valuable learning. For example, sampling using only select few customers, or a small quirky marketing campaign.

Low cost - exactly as described. Often, the cost of speculation around an idea in meetings can far exceed the cost of simply testing it. Real innovation often comes from acting quickly and learning from actual data, rather than from discussing what might work.

Creative - not to be confused with simply coming up with more ideas. It starts with fostering an environment where open collaboration and the free exchange of ideas are actively encouraged and supported. Then focusing on the art of reframing problems in interesting ways, often with a focus on psychological insight, envisioning perception-driven solutions that tap into how people experience or interpret situations. Thinking differently, harnessing chaos with purpose. Solving with imagination, not just engineering. It’s driving a bulldozer through assumptions and building a castle from the rubble. Acknowledging the simplest ideas can have the biggest impact e.g.

• Having passengers walk further to baggage claim, so bags arrive just as they do.
• Making time to simplify user flows through software, or removing valueless features, rather than defaulting to always adding new functionality.
• Adding fake bus stops outside dementia homes to help calm patients who are trying to leave.
• Welcoming customer complaints as a valuable source of feedback.
• Tanzanian mountain guides encouraging traditional Swahili songs to be sung to raise climbers’ spirits when witnessing a rescue on Mount Kilimanjaro.
• Junior employees mentoring senior colleagues on modern trends.
• Using more comprehensible warm user-friendly language to increase engagement.
• Viewing long waits as an opportunity to offer a little something extra e.g. free tea/coffee, blankets, Wi-Fi, etc, for patients undergoing chemotherapy/dialysis.

There are two caveats worth a special mention. Firstly, broadening decision-making autonomy within an organization is most effective when approached at a measured pace, aligned with the organization’s readiness and openness to change. Secondly, being ready and able to provide additional support to employees should confusion arise regarding classifying decisions.

I have already mentioned one of the major benefits being the discovery of big successes that far outweigh the low commitment. Additionally, employees feel a stronger sense of ownership in their roles, that naturally brings more enthusiasm, energy, and usually discretionary effort. This approach fosters a culture of trust and accountability, and increases ownership, engagement, and adaptability within an organization. It also removes lightweight decisions from bottlenecking the slow, one-size-fits-all decision-making processes meant for larger, more consequential decisions.

Finally, just to touch on one-way door decisions. It is important they are elevated to senior executives to employ caution, analysis, and ultimately decide the best course of action. Having clear and widely understood pathways for escalating conversations about single door decisions enables the creativity, unique skills, and fresh perspectives of employees at all levels to extend beyond their daily roles. For example, discovering several actively developed internal software tools with similar functionality that could be unified into a single software tool, or employing lightweight usage scripts to track app activity to identify software licenses that could be downgraded or cancelled.

Conclusion

In summary, I am advocating for teams collaboratively making incremental advances to realise and continuously refining a bespoke agile approach. A bespoke agile approach that is responsive to feedback, and keeps a focus on continually improving outcomes for the individuals, teams, and ultimately the organisation as a whole.

In addition, I am encouraging empowering individuals and teams with increased decision-making autonomy. Trialling creative and easily reversible ideas, that have the potential to drive significant successes, that can far outweigh the minimal cost or disruption incurred by experimenting with them.