by Craig Barbakow

Agile Frustrations

In our Agile transformation engagements, we’ve worked with a wide variety of customers across many different industry sectors. While each one is unique, there is one common theme we’ve heard: “We’re not sure of the ‘right way’ to do Agile.” In other words, our customers are asking us, “Are we doing Agile wrong?”

Recently, one of our customers in the financial services industry told us their homegrown “Business Agility Transformation Initiative” was getting disappointing results:

  • The expected benefits of Agile were not being realized.
  • Quality and speed were not improving.
  • Teams were still unable to rapidly respond to change.
  • There was still a fixation on documentation and process, instead of focusing on customers and achieving business value.
  • There was little or no evidence of innovation or continual improvement.

A Variety of Perspectives

In the past, this customer received a lot of conflicting advice on how to address these types of problems. As a result, the company was not sure what their next steps should be on their Agile journey.

The opinions they heard varied widely and often included extreme and contradictory recommendations including:

  • Scrum is the best way to implement Agile” to “Scrum doesn’t work. It’s awful!”
  • Scaled Agile Framework (SAFe) gets the best results and is the easiest way to implement Agile at scale” to “SAFe is an abomination.”
  • “Agile means the entire business needs to change” to “Agile should be done incrementally. You should start from where you are and scale organically.”

Seeking perspective and guidance, this company reached out to Point B. They wanted to know what approach we would recommend based on their specific needs.

Point B’s Agile Point of View

We recommended they start with the core values and principles of Agile (as described in the Agile Manifesto).

If you’re violating the Agile values and principles regardless of the framework chosen, then it’s fair to say you’re probably NOT doing Agile very well. Conversely, if you’re following the Agile values and principles, then you’re probably on the “right” track.

Put another way, there are a lot of excellent Agile frameworks out there to help organizations become nimble, collaborative, and high performing (Scrum, Kanban, XP, LeSS, SAFe, etc.). Most of these Agile frameworks share a lot in common and only differ on specific details.

In fact, in practice, most Agile teams blend methods. For example, the official Scrum Guide does not mention user stories, Kanban boards, or story points. It’s possible to follow Scrum to the letter and still not use any of these common techniques. However, most Scrum teams choose to utilize a lot of these “complementary practices.”

The implication is there are many ways to become a high-performing Scrum team. Similarly, it’s possible to have a world-class team that uses another approach like Kanban, Scrumban, etc. The team can achieve excellent results even if they decide not to use Fibonacci scoring or they don't like the most commonly used Agile user stories template.

It might be more helpful to think about these Agile practices, methods, and frameworks as styles – as opposed to right and wrong.

It’s OK to have a favorite approach. For example, in tennis, many people prefer a two-handed backhand. But is it wrong to use a one-handed backhand? No, and there are plenty of Wimbledon champions who can easily disprove that notion. What works best for one person may not work well for someone else.

Another analogy is driving to a destination. For example, there are multiple routes one can take driving from Los Angeles to San Francisco. The “best” way to get there will depend on your needs, wants, and desires (i.e. requirements). For the scenic route, take the California coastal highway. If time is an issue, take the interstate freeway.

Different problems and contexts usually require different solutions. You will be more effective if you’re not too dogmatic in your approach to Agile. It’s OK to blend methods as long as you have a good reason for doing so.

In our experience, to be successful, the focus of an Agile adoption initiative should be built on, what we call, the five pillars for Agile success.

  1. Agile Knowledge – The organization, including both leaders and team members, needs to understand the key values, principles, and best practices of the Agile approach.
  2. Pragmatism – There’s no single right way to do Agile. Successful organizations are pragmatic in their adoption of Agile. They spend the effort to adapt Agile practices to their needs where necessary and adapt their existing processes to Agile where it makes sense.
  3. Leadership and Management – Adoption requires executive sponsorship as well as buy-in from teams. Existing structures and processes may need to change to support Agile, including corporate budgeting, organization structures, and compensation. Agile teams must be provided with appropriate tools and a physical environment that is conducive to Agile work.
  4. Agile Mindset – Agile is not just another project management methodology – it’s a fundamental change in culture. The Agile mindset embraces communication, collaboration, feedback, and adaptability.
  5. Personnel – Successful Agile implementation requires staff with the necessary technical skills, subject matter expertise, and strong communication skills.

Point B helped our financial services customer with its enterprise Business Agility transformation using this pragmatic hybrid approach. The company’s technology group essentially adopted a modified version of the SAFe framework while other non-IT groups utilized a variety of approaches based on their specific needs and context (ranging from Scrum, Kanban, Scrumban, Lean, and even elements of more traditional Agile Project Management – including the creation of an “Agile PMO”). The outcome was a smooth evolution to a more nimble and responsive organization without the need for a one-size-fits-all solution that would be difficult from a change management perspective.

The Bottom Line

There are many paths to a sub-standard adoption of Agile (i.e. “doing Agile wrong”), but there is no single RIGHT way. Agile should be about inspecting and adapting. This is basically just the scientific method: Continual learning based on observations and evidence. Organizations need to feel empowered to experiment while relentlessly moving forward with the goals of speed, quality, and never-ending improvement. It’s critical to remain open-minded and flexible. If it works, then use it. If not, then don’t be afraid to try something else.