Scrum Plus: Agile Heresy No More!


Old habits die hard.  Useful habits die harder.  

Six years ago, I earned my CSM from the ScrumAlliance. Another six years before then, I had already been baptized as an evangelical apostle of FDD (Feature Driven Development), christened by Jeff De Luca and Peter Coad. Yet another six years before, I was already teaching the “Baseball Model” of agile, concurrent development processes…but that’s another story. (Yikes! A “6-6-6” pattern? Naw, probably just intervals in my learning curves.)

Agility and FDD were woven into our collective DNA at TogetherSoft. Our business cards were tagged with our mission statement:

Improving the ways people work together TM

My card displayed a “Senior Coad Certified Mentor” title. Mentor to our customers. Mentor to other mentors. Helping others learn FDD was part of my job. That was a remarkable privilege. I got to share the love!

So, as a newly minted Scrum Master in 2006 did I renounce my faith in FDD?

No, I didn’t. Not a snowball’s chance…

Agile apostasy? Not likely.

Ever since earning my CSM from the ScrumAlliance in June, 2006, I have risked being labeled as a heretic among practitioners by promoting “Scrum Plus” perspectives in software development. Until recently, Ken Schwaber’s “Scrum But” pronouncements could be cited by Scrum zealots to indict ecumenical methodologists and freethinkers for alleged departure from Scrum orthodoxy. Perhaps even so when the “departure” was strictly additive. But no longer is it the case, thanks to Schwaber himself, who went on record with his plea for “Scrum And” in April, 2012. Hallelujah!

Why extend Scrum?

The baseline Scrum framework only shows us how to marshal our efforts through collaboration. We are left to our imaginations to organize our work units and apply our engineering methods. Some have already built their software development “process” superstructures on a Scrum foundation. Amalgamations such as Scrum+XP, Scrum+FDD, and so on.

Without “breaking” Scrum, I’d call that a “Scrum Plus.”  For a few folks, that seemed too much like “Scrum But.”

But no longer. Thanks to Ken’s “Scrum And” missive, a “Scrum Plus” perspective now has even more credibility. In fact, some emerging work exhibits a string of “Scrum+” notations. has been soliciting proposals for “Scrum Extensions.”  You can follow their draft examples here.

Whither Scrum+ next?

Now that we seem to have blessings from Schwaber and friends to openly build on the Scrum framework, what might we do next?

The time has come when it is acceptable to explore the possibilities of the plus sign.

How have you put your “Plus” on Scrum? What will you do next?

Let’s hear from you, please!  


–Ken 😉

PS:  No flames. No burnings at the stake.  It’s OK to #try #fail #learn and #trydifferently.

6 Replies to “Scrum Plus: Agile Heresy No More!”

  1. The thing about Agile is that it’s processes can be modified to fit the team’s or the function’s needs and still retain basic fundamental “Agile-ness” – keep on, keeping on my friend!

  2. This past Monday, we brought Workday customer #254 live. We use the Workday implementation methodology, based on workshops and iterative prototyping. It isn’t Scrum, or even Scrum-but, but it is unarguably Agile. Of course, the product itself was built and continues to be developed using Scrum, in a pretty vanilla fashion, with major upgrades pushed to production three times a year. So, should the combination of the development teams using Scrum and the implementation teams using the iterative prototyping methodology be called Scrum-plus? I would argue that the labels don’t matter. Results matter.

    “An evangelist is someone who wants to impose his religion on you.”

  3. FYI just dropped Scrum Extensions. I and others (Notably Ron) argued that Scrum Extensions were likely to have the wrong effect.

    The good:
    – They would document practices/patterns that people have found useful example planning poker.

    The bad:
    – By calling them extensions and blessing them with the stamp they were made to look like official parts of Scrum. They went from good practices in a given context to “Best Practices in All Contexts”.

    In the end David agreed.

    The elegance of Scrum is that it is incomplete. It doesn’t pretend to have all the answers. In that context you should always be experimenting ex: try TDD, BDD and even good Feature Driven Development. By not extending Scrum we make it clear that all experiments are good.

Leave a Reply