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 2^nd generation Scrum taking advantage of the new, modern, Agile thinking see http://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.