Mixing Scrum and Waterfall will provide you an interesting mix...  This is one of my older MSDN posts from August, 2006.  Enjoy. :)

Friend and colleague Brad Wilson defines Scrummerfall as

Scrummerfall. n. The practice of combining Scrum and Waterfall so as to ensure failure at a much faster rate than you had with Waterfall alone.

"Bob, what is a sprint planning week - I've never heard of that" I asked.
Bob responded
"I’m probably not using proper Scrum terminology but in our team we commonly use “sprint planning week” to describe the single week before the 4-week sprint where we work out the sprint backlog, people resources, and timeline for implementing and testing backlog items."

What I found is that this particular team breaks their work out by the following:

Week 1 - Planning
Weeks 2 - 5 - The actual sprint.  During this time, developers code while testers write test cases and do light testing
Weeks 6 - 7 - Integration
Week 8 - Deployment to live site
Week 9 - Buffer, just in case.

This is further compounded by the following:

"Notice there’s not a period for writing PM specs, dev design docs, or test plan/specs.  We’re trying to address that starting in our next sprint."

What scares me in this approach is the fact that there are 5 weeks of work (and growing) to encompass a 4 week Sprint.  This is an example of a larger problem that looms in companies across the world.  Instead of working inside a time-box, the team chose to do its "coding" during the Sprint and do everything else outside the Sprint.  Being potentially shippable does not play in this model. 

Being Agile is a mindset.  It is understanding that writing code is only 5% of the work needed to ship software.  Yes, he actually did write that.  Writing code is 5% of the work needed to ship software.  By taking an approach such as the one listed above, that 5% swells into close to 50%.  As a result, things fall through the cracks.  Integration testing, stress testing, environment management, documentation, you name it - it will be forgotten.

Just remember, in the end, Scrum is a framework.  If projects fail, it's not because of the framework, it's because of the people.  Frameworks do not fail, people do.

Comments

Add New Search RSS

Write comment
Name:
Email:	do not notifynotify
Website:
Title:
UBBCode:	-color-aquablackbluefuchsiagraygreenlimemaroonnavyolivepurpleredsilvertealwhiteyellow -size-tinysmallmediumlargehuge
	Please input the anti-spam code that you can read in the image.

Powered by !JoomlaComment 3.12

Copyright (C) 2007 Alain Georgette / Copyright (C) 2006 Frantisek Hliva. All rights reserved.