Twitter Blog: Scrum-But is Due to the Unawareness of Scrum-And

September 9, 2012 — Posted by Al Shalloway

Context

Continues my thoughts on why we even have something called Scrum-but.  What has been ignored by too many thought leaders is that it is a pattern that occurs with such frequency it could be considered to be an inherent part of Scrum. The patterns of challenge people using Scrum are having are so well-defined and predictable that it is clear Scrum has something to do with it – it’s not just people are doing it wrong. Unfortunately, the dissemination of these ideas continues to be resisted by many Scrum thought leaders. Sometimes by merely ignoring the questions being asked, sometimes by attacking those raising the questions as bashers.

Some others are now jumping on the Lean bandwagon.  We see all sorts of companies offering Certified Scrum Training who now mention Lean somewhere on their site.  Few, unfortunately, seem to realize that putting some lean practices into Scrum is quite different (and insufficient in all but the simplest of cases) to doing Scrum within the context of Lean.

The first person who suggested shock absorbers was not bashing carriages, he was trying to help the carriage owners.

The Twitter Blog

What is “Scrum-And?”

Scrum-and is Scrum extended taking advantage of what we’ve learned by using Scrum for over a decade.

It’s a true 2nd generation Scrum taking advantage of the new, modern, Agile thinking see https://www.netobjectives.com/blogs/mindsets-waterfall-1st-2nd-generation-agile

For 5 years Net Objectives has been suggesting that to do Scrum beyond a single team you need to:

  • use lean to create the context within which teams can work instead of Scrum-of-Scrums
  • understand lean-flow to better manage the team’s work
  • know more than just planning poker in how to do estimation (planning poker is usually not best method-taking way more time than necessary)
  • know how to use Kanban to manage the work of folks who cannot be 100% on a team
  • use acceptance test-driven-development to avoid the waste of building the wrong things
  • create a common vision across all levels of the organization (lean can help here)
  • use Kanban when it is a better method than Scrum for a team (remember, one size does not fit all)
  • abandon the product-owner only role when you have multiple stakeholders
  • include management in the development process
  • use shared backlogs instead of Scrum-of-Scrums to coordinate work
  • understand how/when to use feature teams, dynamic feature ands & core/extended teams
  • recognize the scope of Scrum and not attempt to use it to guide an enterprise agile transition if it is not the best way
  • know when to use Scrum and when to use something else (e.g., Kanban) one size does not fit all

-------------------------------------------------------

I believe if people even knew they should do these things we'd see a significant drop in the use of Scrum-but.

Knowing of alternatives is extremely important.

See The Scrum Clinic for more on how to extend your Scrum.

See Net Objectives Lean-Agile Roadmap on how to do Agile at Scale.

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.


Comments

This is exactly why when I coach teams, I do not prescribe any one method. Yes, most teams will have some elements of Scrum, XP, etc. - the somewhat typical makeup. But I focus a lot of value and principle-based Agile and "what works". Also, the more intrinsic buy-in you get from the team, the more they will be creative in solving problems and continuously improving.

As stated by Alan, "One size does not fit all." Team members and the project leaders with various roles should have knowledge about when to use and when not to use Scrum. The training should include simulated product development activity, role plays and case studies. There is nothing to mastery about Scrum, its just a philosophy or say an approach to achieve the set project goals. So, you have to be in a process of continuous learning,improvement and experimenting.

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