When Agile Falls Short: Let’s Return to the Basics

Introduction: Conversation With a Stranger Regarding Agile

At a recent expo, I found myself in a conversation with a stranger about project management. It quickly became clear that we had different opinions on which methods work best. 

There are basically three ways to approach a project, known as project methodologies:

1. Predictive (also called waterfall)
2. Adaptive (also called agile)
3. Hybrid (a mix of both predictive and adaptive). I recently heard the term "wagile," which combines agile and waterfall.

I'm a strong supporter of Agile, but the person I was talking to had a bad experience with it and called it "a disaster, especially when switching from Waterfall to Agile." My first thought was, what's his understanding of Agile? How could a method that originated from Japanese manufacturing and boosted productivity by 300-400% get such a bad reputation in the West? 

Maybe both of our views on Agile were a bit skewed. From what I've learned about agile—and the Scrum principles I've applied even in more traditional, predictive projects—something didn't quite add up. 

As the conversation continued, I listened closely, eager to understand why this approach I believed in so strongly wasn't working as well for him. It became clear that he was a senior manager with a lot of experience in the technical world, where Agile is the one true King. His perspective couldn't be dismissed lightly, so I was very interested in what he had to say. 

After sharing what he didn't like about agile, he explained what he was actually looking for in a project management method—and that's when it hit me. What he wanted was exactly what lies at the core of agile: teamwork and collaboration to solve problems together. 

I started to think that maybe agile has changed so much since it first started that it's turned into something else—something more complicated and not delivering the results it's supposed to. 

I remember reading Scrum by Dr. Jeff Sutherland, the creator of Scrum and CEO of Scrum, Inc, and how it made a huge impact on me. I even went back to find the notes I took at the time. It made me realize that perhaps we need to strip it back to basics. If we can get rid of the overcomplicated ceremonies and funny jargon and focus on what really matters, maybe we can make agile work again, even in traditionally predictive projects. 

Here are the notes I took to summarize what Scrum is, how it works, and how you can apply its principles to any project, whether it follows a waterfall, agile, or hybrid approach (sometimes called "wagile"). 

Touch, Pause, Engage – Let's Scrum! 

These three words are called out before every Scrum in rugby. Eight players come together, heads down, and push forward in unison. In a team setting, this means the whole team gathers to tackle a problem together. By pooling their energy and focusing on a shared goal, they can solve issues more quickly and efficiently than working individually. 

Let's start with the overall principles: 

• Pause and Reflect Regularly: Every now and then, take a break from what you're doing to review the progress. Check if you're on the right track, and think about how you can improve. 
• Focus on the Essential: 80% of a software's value comes from just 20% of its features. Prioritize what truly matters. 
• Identify Obstacles: Team members need to figure out what's slowing them down and stopping them from moving faster. 
• Keep the Process Smooth: Work should flow smoothly and without disruption. Management's main job is to find and remove anything that blocks this flow. Anything that disrupts it is considered waste. 

Divide Work up in 2-4 Week Spirits

The sprint is a 2-4 week production cycle called a time box iteration. At the end of the cycle, you should have a complete and fully functional unit of the product that can be tested. 

• Sprint Planning: At the start of the cycle, the team has a meeting to plan the sprint. 
• Workload Estimate: The team decides how much work they think they can complete in the next two weeks. 
• Sprint Review: At the end of the two weeks, the team reviews their progress and asks: 
• Did we take on too much work? 
• Did we not take on enough? 
• What obstacles slowed us down? 
• Based on our speed, when can we expect to finish the project? 
• How can we improve our team's speed? 
  • This does not mean working longer hours. 
  • Instead, identify and remove anything that slows the team down. 

Empower Your Team

• Cross-functional Teams: Teams have all the necessary skills and are self-sufficient. Ensure your team has all the skills needed to complete the work from start to finish. There shouldn't be specialists on separate teams handing tasks over to one another. 
• Intrinsic Motivators: The driving forces for all Scrum teams are purpose and autonomy. 
  • Autonomy: They have the power to make their own decisions. This means having the freedom to do your job the way you think is best, giving you autonomy. On high-performing teams, it's up to the members to decide how to achieve the goals set by leadership. 
  • Purpose: They work towards a goal that is bigger than just completing tasks. 

The New Roles

• Project Manager's Role: Your job is to help your team do their best work. It's not about telling them how to do it but providing the support and resources they need. 
• Management's Role: 
  • Leaders act as servant leaders. 
  • Executives focus on removing obstacles for the team, not dictating what to do or how to do it. 

Keep Your Team Small

• Team Size and Dynamics: Scrum works best with small teams, ideally with a maximum of 7 members. Any more than 9 people, and team velocity slows. 
  • Brooke's Law: Adding more people to a late project only makes it later. Large teams (20+ people) often take five times longer to complete a task than small teams of 5 or fewer. 
  • Transparency: On a Scrum team, everyone needs to know what everyone else is working on. You can only know that in small teams. 

Why Large Teams Struggle

• Time is lost bringing new people up to speed. 
• More people increase the number of communication channels, overwhelming the team. 
• Avoid Communication Overload: In large teams, communication becomes chaotic, with too many conflicting updates. This makes daily communication difficult and clouds the team's progress. 

Conclusion

The key takeaway is that while methodologies like agile can sometimes become overly complex, returning to fundamental principles can reveal their true value. Scrum's emphasis on team autonomy, transparency, and continuous improvement remains crucial.  

By focusing on these core aspects and avoiding overcomplication, teams can harness the true power of Scrum, regardless of their project's size or methodology. The essence of successful project management lies in understanding and applying these principles effectively, ensuring that team members collaborate with each other and when there is a problem – like in a rugby scrum – lock arms, keep your head down and focus on solving the problem.