Rediscovering the Adaptability of Agile

In my 20+ years of leading product and engineering teams, I’ve heard all too often that Agile sucks. Agile fails to magically deliver on the perceived promise to transform teams into high-performing powerhouses overnight. From my experience, it’s not Agile or, more likely, the Scrum framework that people are frustrated with. Instead, this angst results from poor implementation and a lack of understanding of the values and principles of Agile development.

Agile purists talk about unlocking Agile’s potential by “being agile” versus “doing agile.” I agree with this sentiment in many ways, but I believe that to help teams succeed in embracing Agile, we should reframe the conversation to be about both “doing agile” AND “being agile.” Let’s get into it.

Agile Is More Than Scrum

Too often, teams feel let down by Scrum, trapped in a slog of endless Sprints that fail to deliver on expectations. This is all too frequently due to a Scrum implementation that focuses on the mechanics of Scrum rather than on the spirit of Agile software development. 

Frequently, I’ve seen teams that dutifully follow Scrum fail to become more productive, struggle to deliver on expectations, and wonder why they’re even bothering with Scrum in the first place. These teams are likely asking too much from Scrum, which, at its core, was designed to be a project management wrapper for Agile.

Agile isn’t about rituals. Agile is about cultivating an adaptive, responsive, and collaborative mindset, which sparked the debate about “doing” versus “being” Agile. It’s entirely possible to be Agile without Scrum.

“Being Agile” Vs. “Doing Agile”

Let me define what I’m talking about. “Doing Agile” means following a framework like Scrum or Kanban to streamline the development process and unlock a team’s true potential, but “being Agile” is a mindset. “Being Agile” means:

  • Embracing a philosophy that prioritizes flexibility, learning, and collaboration over following a process.
  • Committing to Agile’s values and principles as outlined in the Manifesto for Agile Software Development, Scrum, Lean Software Development, and Extreme Programming (XP)—plus many other tools and techniques. 
  • Taking the time and effort to engage with this material and apply it in real-world situations will help you develop an understanding of the principles and figure out how to apply them in a way that works for your team.

It sounds complicated, but there are practical approaches. Let’s be clear: It will take you years to understand the Agile mindset thoroughly, but with a systematic approach, you can assess your current problems, get Scrum working for you, and kick-start your Agile journey.

First, Scrum—That Doesn’t Suck!

I’ve often witnessed teams whose way of running Scrum doesn’t work; they fail to produce consistent outcomes, the team is frustrated, and they feel they need to put in extra hours to keep up. There are ways to address these challenges, improve productivity, and help to avoid burnout. Reassess how you’re running Scrum. Take a hard look at it, ensure you know what Scrum should be, and then ensure you’re doing it well. Here’s a four-step process:

1. Solidify your understanding of Scrum. There are so many great resources available to you to learn from, as well as a whole industry around Scrum training and certification. Spend an hour or two per week for several months (around 15-20 hours in total) and dive into these resources to build your understanding of Scrum:

  • The Scrum Guide. The Scrum Guide is a logical place to start to ensure you have a solid understanding of Scrum. It’s regularly revised, with small functional updates (“ceremonies” are now called “events”), and it is the concise definition of what Scrum is.
  • Agile Project Management with Scrum by Ken Schwaber is my go-to because it clearly outlines how Scrum should be run, and it’s just as valuable today as it was when it was published in 2004.
  • Scrum training and certifications from Scrum.org or ScrumAlliance are a valuable use of 2 or 3 days for an in-depth, professional deep-dive into Scrum. While you’re at it, get certified and add the badge to your resume.
  • Sign up for a local Scrum Meetup chapter
  • Read Scrum newsletters or blogs via Scrum.org or ScrumAlliance.

2. Take a Quick Pulse. Take a step back and look objectively at how well your team is accomplishing with Scrum compared to the Scrum Guide. For a quick assessment, take 20-30 minutes to evaluate these questions:

  • Does the team feel good about the process and what they are accomplishing?
  • Are your sprints productive?
  • Is the team’s velocity predictable and consistent?
  • Is the team good at estimating and coming to a consensus?
  • Are all tasks the team committed to in a sprint getting done?
  • Do your retrospectives lead to real improvements?
  • Does the team get value from every Scrum Event?
  • Does the team self-organize to run Events?

Ideally, you’d be able to answer yes to all of these questions, but you’re heading in the right direction if you can answer yes to the first five or six.

3. Evaluate Feedback and Metrics. Doing Scrum well involves learning from your team’s feedback and examining metrics. Use team surveys, retrospectives, and metrics like sprint completion rates and the DORA metrics to assess where you currently are and as a way to measure progress.

The DORA metrics use four indicators grouped into Velocity and Quality measures:

  • Velocity: Deployment Frequency and Lead Time for Changes
  • Quality: Change Failure Rate and Failed Deployment Recovery Time

These are good yardsticks since they align well with agile principles and, based on DORA’s research, are hallmarks of top-performing teams. Plug in your numbers (best guesses are fine) into the DORA website to benchmark your performance against others in your industry. 

Team surveys are equally important. Check out the Developer Experience Survey Template (it’s free) from DX and use it, or something similar, to get anonymous input from your team. Keep it short—maybe just the first 5 or 6 questions from the DX template, not all 18.

If the employee surveys disagree with the metrics, trust the survey results over the metrics. Your team is composed of the people doing the work and whose ability to work effectively matters. If your team members are not happy with how things are working, then there’s something wrong that you need to address—even if the metrics say otherwise.

4. Improve your Scrum implementation. With everything you’ve learned from the previous three steps, it’s now time to put it into action:

  • Use what you’ve learned from the self-assessment and the practices outlined in the Scrum Guide to drive your improvements. 
  • Engage the whole team in figuring out what issues to address first, and be open to everyone’s input to build consensus and trust. 
  • Measure the impact of the changes by revisiting step 3.
  • Use the feedback to inform the next steps (refer to the Plan-Do-Check-Act process) and commit to ongoing incremental improvements.

I’ve been able to transition teams in as little as a couple of months, but it generally takes four to six months or longer to get things running smoothly. Once you’re doing Agile well, you can continue your journey and explore what it means to be Agile.

“Being Agile”

Let’s continue the Agile journey. Now that Scrum is working well and you are “doing Agile,” it’s time to draw from other sources and improve your understanding of what it means to “be Agile.” Build on what you’ve learned to develop an Agile mindset further and evolve how your team operates. Below are three methodologies that you can use to continue this journey.

The Manifesto for Agile Software Development. The Manifesto resulted from a meeting in early 2001 to explore better software development methods. This event, along with the Manifesto, is what kicked off the Agile movement. It includes four values and twelve principles. The four values are:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

I’ll let you explore the twelve principles on the website, but I would like to highlight my personal favorite, which is:

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

Extreme Programming (XP). XP and Scrum work well together. Unfortunately, you’ve likely never heard of XP; if you have, you know little about it. XP emphasizes teamwork, close customer collaboration, openness to change, incremental delivery, and empowered teams. Look to XP to help address some of Scrum’s shortcomings. 

XP’s values, engineering best practices and core principles can significantly enhance Scrum’s agility. XP has been around for over 25 years, and it is more of the backbone of Agile than Scrum. I find this saddening, as the XP has largely been forgotten. It’s time to revisit XP and learn about how applying XP practices can dramatically improve team outcomes. I’ll write more about XP in the future; until then, take twenty minutes and browse Extreme Programming: A Gentle Introduction. There’s also a whole series of XP books from Addison-Wesley Publishing.

Lean Software Development (Lean) originated in a book by the same name by Mary Poppendieck and Tom Poppendieck. It is adapted from the Lean Manufacturing process and focuses on eliminating waste and delivering only what’s needed when needed. As an Agile framework, Lean has a foundation of seven principles that focus on improving the efficiency of developing software. These principles are:

  1. Eliminate Waste: Focus on reducing non-value-adding activities, unnecessary code, and functionality to streamline processes and reduce costs.
  2. Build quality In: Integrate testing and quality control measures early and throughout the development process to prevent defects and reduce the need for rework.
  3. Create Knowledge: Encourage continuous learning and information sharing across the team to innovate and improve products and processes.
  4. Defer Commitment: Maintain flexibility in decision-making by waiting until the last responsible moment, when you have the most information available, to decide.
  5. Deliver Fast: Accelerate the delivery process to provide quick feedback and realize value sooner, enabling faster adaptation to change.
  6. Respect People: Foster a respectful and collaborative environment where team members are empowered and their contributions are valued.
  7. Optimize the Whole: Focus on enhancing the entire value stream, from concept to customer, to improve overall system performance and customer satisfaction.

As you’re starting to see, the values and principles of the various methodologies repeat (e.g., deliver fast, respect people, defer commitment). To me, this overlap reinforced the real value of these practices in high-performing teams.

Continue the Journey and Make Agile Your Own

To continue your Agile journey, dig into the above resources and use what you learn to continuously assess, refine, and adjust your approach. Get good at retros, use them to determine what is and isn’t working, keep doing the good things, and take action to address what’s not so good. Mix up who runs retros and how they’re run to get diverse perspectives and insights.

As your team improves its agility, you can adapt and move beyond the Scrum framework and develop ways of working that best align with your projects and culture. As you gain confidence in your new ways of working, you may even consider eliminating Scrum.

Agile should not be a burden. Ultimately, it should serve the team and help you deliver customer outcomes. By understanding and integrating the essence of “being Agile” with the structured practices of “doing Agile,” your team can harness its benefits over the long term. Continuous improvement, responsiveness to feedback, openness to change, and a commitment to quality are vital to doing and being agile.

Don’t forget to have fun with it. Teams that keep a sense of humor tend to perform better because it fosters a sense of belonging, camaraderie, and collaboration.