A Practical Guide to Making Agile Not Suck!

Rediscovering the Adaptability of Agile

In my 20+ years of leading Agile teams, I’ve heard all too often that Agile sucks and that it 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 commonly, the Scrum framework that people are frustrated with. Instead, this angst results from subpar implementations and a lack of understanding of the methods, values and principles that define Agile software development.

Agile purists like to talk about unlocking Agile’s potential by “being Agile” versus “doing Agile.” I agree with this sentiment in many ways, but also believe that to help teams truly succeed in embracing Agile, we should reframe the conversation to be about “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.?

I’ve seen teams that dutifully follow Scrum but fail to increase productivity, struggle to deliver on expectations, and wonder why they’re even bothering with Scrum. 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, this is what sparked the debate about “doing” versus “being” Agile. It’s entirely possible to be Agile without Scrum.

“Doing Agile” Vs. “Being Agile”

Let’s define what this means. “Doing Agile” means following a project management framework like Scrum as a way of implementing an Agile methodology, while “being Agile” is about developing 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 to engage with this material and apply it in real-world situations. It’s in the application that you will develop a deep understanding of the principles and how they work best for your team.

It sounds confusing, but I’ll outline a practical approach to building your understanding of what all this means. I want to be clear: It will take you years to wrap your head around the Agile mindset thoroughly, but with a systematic approach, you can address your current problems, get Scrum working for your team, and kick-start your Agile journey.

First, Scrum—That Doesn’t Suck!

Too often I’ve witnessed teams whose way of running Scrum doesn’t work; they fail to produce consistent outcomes, the team is frustrated, and feel they need to put in extra hours just to keep up. I want to present a way to address these challenges, improve productivity, and help avoid burnout. Start by improving your knowledge of Scrum and what good Scrum looks like and then look for ways to improve your teams implementation so that Scrum works for you and your team. Here’s the 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 (15-20 hours in total) and dive into these resources to build on 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”), it’s the concise definition of Scrum.
• Agile Project Management with Scrum by Ken Schwaber is my go-to book 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 valuable uses 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. With this new deeper understanding of Scrum, take a step back and look objectively at how well your team has implemented Scrum as compared to best practices. For a quick assessment consider 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 are doing okay if you can confidently answer “yes” to the first five or six.

3. Evaluate Feedback and Metrics. Doing Scrum well involves listening to your team’s feedback and examining metrics. Use team surveys, retrospectives, and metrics like sprint completion rates and the DORA metrics to honestly assess where you currently are and as a way to measure your ongoing 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 useful yardsticks since they align well with agile principles and, based on DORA’s research, are the hallmarks of top-performing teams. Plug your numbers (best guesses are fine) into the DORA website to benchmark your performance against others in your industry.

Team surveys are equally as 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. At first, keep it short—maybe just the first 5 or 6 questions from the DX template, not all 18, as you progress in your Agile maturity add more questions to get deeper insights but limit surveys to quarterly or less frequently for best results.

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 needs to be addressed—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 to a much more productive application of Scrum in as little as a couple of months, but it generally takes six months, or longer to get things really running smoothly. Once you’re doing Scrum well, you can continue your journey and explore what it means to “be Agile.”

“Being Agile”

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” and continue your journey. Building on what you’ve learned about Scrum to deepen your Agile mindset further and use this knowledge to evolve how your team operates. Below are three methodologies that you can learn from on this journey.

The Manifesto for Agile Software Development . The Manifesto resulted from a meeting in early 2001 to explore better ways to develop software. This event, along with the resulting 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 your own 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 very 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 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 it saddening that XP has largely been forgotten and think it’s time to revisit XP and learn how combining XP practices with the Scrum Framework 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, including the highly recommended Extreme Programming Explained by Kent Beck.

Lean Software Development (Lean) originated as 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.

I hope you are starting to see that the values and principles of the various methodologies overlap (e.g., deliver fast, respect people, defer commitment). To me, this redundancy serves to highlight the real value of these practices for 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 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.

Also, stay tuned for my future posts where I’ll be digging into more details around Agile as well as Servant Leadership and other things I’ve learned over the years about how to help empowered teams succeed.

Don’t forget to have fun with Scrum and Agile. Teams that keep a sense of humor tend to perform better because it fosters a sense of belonging, camaraderie, and collaboration. Plus it makes work more enjoyable.