Setting the Record Straight on Scrum and Agile

January 25, 2012 — Posted by Al Shalloway

The Gist of the Story

We believe in Agile software development for teams. From small teams to a 4000 person development group, our clients have enjoyed success with Agile. They have been able to deliver more value to customers at a more sustainable pace and with greater employee satisfaction than ever they were before. That is what keeps us going.

We believe in Agile in all its flavors: Scrum, Kanban, XP, Lean and all combinations thereof. Success with agile depends on using the approach that best fits the context. It never works to commit to one approach. There are too many organizational dynamics that are involved. One of our clients began by using Scrum on a pilot project and realized dramatic improvements; however, pushing Scrum onto the next project was a terrible experience. The first had the right set of conditions for Scrum to succeed. The second project had complexities in team structure and project that, properly understood, precluded the use of Scrum. Paying attention to those dynamics, they should have chosen something else.

Do you want to succeed with Agile? As quickly as you can, learn the various approaches and what makes them work. Keep growing so that you get beyond the "one-size-fits-all" mentality that unfortunately gets touted by enthusiasts and vendors. No matter what anyone tells you, there are no silver bullets. There are tools for a job. There are principles to guide you. And this is true whether your organization is large or small.

As you learn, look for patterns of success and challenge. Did something work well? Why? Did an approach fail? What were the factors involved that got in the way? The fault is usually never with the people. It might be that they did not know some basic practices and principles. It might be the organizational structure or technical issues or management oversight. It might be an issue of scale. Like our client who naively selected Scrum when it wasn't appropriate, did the method you used have some (often tacit) preconditions that were not met? Or did you just assume that it should be used?

It never helps to be dogmatic.

Scrum is a Good Framework for Teams

Scrum is popular. We have seen it used well and we have trained it and consulted with it extensively. A few words are in order because, as good as Scrum is, it can also fail when used artlessly.

Scrum works. It is most successful with cross-functional teams working in a time-boxed manner at the direction of a product owner who is responsible for a product. (The less this is true, the less likely Scrum will succeed). While not "classic Scrum", we find that Scrum works best when it is extended to include some essential practices such as acceptance test-driven development and managing "work in progress" (WIP): the number of stories active during a sprint at any one time. For a more extensive covering of these patterns see our Scrum clinic. While teams should be free to self-organize (a fundamental tenet for Scrum, Kanban, and lean), there is no sense in teams having to rediscover what has been proven to be useful!

Scrum is inspired by the brilliant authors of The New New Product Development Game, Hirotaka Takeuchi and Ikujiro Nonaka. The scope of their theory involved teams engaged in product development. It is an approach for teams.

While some might say otherwise, we find that it is a stretch to try to make Scrum – or any other team-based framework – apply at the organization level. The dynamics are different. A team of teams ("scrum of scrums") is quite different from a team of people. They are trying to do different things.

Do You Have These Challenges?

Are you finding challenges with your approach to Agile? At the team level, are you seeing any of the following issues?

  • Teams spend a lot of time fixing bugs that are discovered during the sprint
  • Teams have trouble completing their sprint forecasts (formerly commitments)
  • Teams finish stories only to discover what they built is not quite what is needed
  • Management frequently demands new items are inserted onto the iteration backlog during a sprint

At the enterprise level, are you seeing any of these issues?

  • Teams seem to be Agile but there are bottlenecks that prevent quick releases
  • Teams depend on people outside of the team and often have to wait for them
  • Stakeholders can't tell when something is going to be done because they depend upon several teams for the work to be completed
  • Stakeholders continue to ask for larger than necessary features in the hope that by over-requesting they will get more accomplished

These are common challenges. Perhaps you need to use a different approach. Or perhaps you are doing it right but your approach needs to be extended or combined with something else. In our experience, these issues usually arise when you fail to take a holistic view of the system, when you fail to attend to corporate culture, when you are not following the principles of Lean-Flow.

We have helped many companies overcome these challenges. Here are some helpful resources:

Summary

We like Agile methods when they are taught properly and used appropriately. We would never align behind any one method or approach. No method is the answer for every organizational context. Scrum – especially extended with Lean, Kanban, and technical disciplines – is one essential part of our approach to Lean-Agile transition. Use the methods that work for your situation. And don't try to force them to go beyond their scope.

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban