If an organization is going to 'buy in' to SCRUM there are two fairly critical Agile principles they need to follow:
- "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done"
- "Business people and developers must work together daily throughout the project."
Sounds good, right? Give business a daily voice in development and give the technical team the resources they need to do the job.
So why can we relate to Scrummerfall?
Let's start with Agile. Like it's predecessor Waterfall, Agile is a general label. It's a foundation that has generated different ideas and styles along with new tools and technologies for delivering software.
Scrum, TDD / BDD / FDD, paired programming and other development strategies fall under the Agile "brand." Tools such as JIRA & TFS, Selenium & Cucumber, Docker, & CruiseControl are just a handful of the hundreds of platforms available to deliver in an iterative and continuous fashion.
By definition, if they serve the underlying purpose of delivering software efficiently, you can mix and match these strategies. When you boil it all down Agile is simply finding a way for business and technology to work together to find a better way to put usable software to production.
Scrum & Kanban have been mashed up into Scrumban so why not mash up Scrum and Waterfall? Some would argue DSDM could be branded Scrummerfall.
After all, Agile is not without it's foibles. Fifteen years after the manifesto was written organizations still struggle to implement an Agile strategy that works for everyone. This is especially true in large, established organizations where there are many impediments to large scale Agile adaptation.
Who knows, maybe in the next few years we'll see Scrummerfall (or a variant) pop up on the drop down in TFS. And that's the beauty of Agile.
