scrumbut [skruhmbut] noun.
1. A person engaged in only partially Agile project management or development methodologies
2. One who engages in either semi-agile or quasi-waterfall development methodologies.
3. One who adopts only SOME tenents of the SCRUM methodology.
4. In general, one who uses the word "but" when answering the question "Do you do SCRUM?"


You wouldn't want your surgeon to follow just *SOME* of the steps in that procedure you're getting, would you?

SCRUM works great, if you can just follow the (whole) program. It's not surprising how many organizations say they have failed using SCRUM, when they have only picked and choosen a few of the aspects to implement.
For those of you who need a 12-step program... and you know who you are...


1. Use a 2-week or 4-week sprint. 2-week preferred
2. Appoint a scrummaster who will hold the team accountable, AND also keep the wolves at bay.
3. Make sure the entire team is jointly accountable for the success of the project.
4. Have a prioritized product backlog ready before the sprint. This can include both bugs and features
5. Have a REAL planning meeting where the team commits to stories and they are thoughtfully tasked out and estimated.
6. Team members commit to stories, and then break them down into tiny pieces (tasks). If any estimates are over 4 hours, break them down further.
7. Do a daily stand-up. What did you do, what are you going to do, and what's blocking.
8. Don't do anything that's not estimated and in the sprint backlog.
9. Establish, post, and meet DONE criteria. It's only real if it's posted and visible to everyone.
10. Post a sprint backlog task burn-down chart and update it daily.
11. Keep the product owner in the loop at all times.
12. Hold a stakeholder review a the end of the sprint - this is the fun part!
(13) Then, have a retrospective meeting to discus what went well, what could use improvement, and action items.

That's SCRUM!
Now, you'll never have to be a SCRUMBUT again!

Once upon a time, there was an Agile team that was working on stories in a sprint. The team was going on fine, until the product owner decided it was time for him to go on a month long vacation (and then leave the company).

Life Goes On
So, being a good scrum master, the SM appoints a new PO to make decisions on the specifics of the stories that were already in progress (and some finished). The new PO was a pretty sharp fellow, but he didn't have any background for the feature, so he was a might confused. But, the team had fairly good direction on the feature, so they persevered and completed the tasks as they understood them.

The Shadows
Now then, from lurking in the dark shadows, there emerged the original PO's Boss. The Boss of course looks at the feature nearly complete, and decides that there were a couple minor tweaks here or there - hey, he's the boss - he can do that. No worries, the changes were slight, and easy. Done deal. All the stories were completed, as well as the automated acceptance tests that verified the now-completed tweaks, as well as the remaining story criteria. All the words had been blessed by the Documentation folk, the UI had been blessed by the User Experience folk (this was the Second iteration of the UI design also BTW).

Demo Day
At the end of the sprint, we all get together with the interested stakeholders in a room, and review the stories, the functionality that was delivered. The managers, the development director, the project team, scrum master, and QA were all represented. Keep in mind now, that everyone has actually seen the feature at least once... "We can't have it do that..." says the boss. Well, apparently a modal dialog with OK and Cancel doesn't work the same in Boss-World as it does everywhere else. So, he fires up his argumentation engine and proceeds to corner the entire meeting with a redesign of not only the UI but also the functionality of a standard modal dialog. Nothing was up to par for the Boss, and - remember - he had seen it all demonstrated for him before...

The Outcome
None of the stories in the sprint were accepted. Sprint velocity: ZERO points. Bad day. Alcohol was required.

The Moral
The moral of this story is this: Have a Product Owner who knows what the feature does. Make sure the product owner has input from ALL the stakeholders - oh yes - in a TIMELY manner as well. Make sure your scrum master has the ability to keep lurking skeletons at bay. They can have their say in the next sprint. But at the end of the planning meeting, the stories should be pretty much fixed and everyone should understand the acceptance criteria for them. Stories shouldn't just have arbitrary criteria appended, grafted, attached, pasted, or otherwise affixed to them after the planning meeting, even by skulking lurkers.

We all know what design patterns are in software design and development. These kinds of patterns also are recognized in unit and other kinds of tests as well.

While it is not necessarily a new idea, it is a good idea. Here are some links I have found on the subject. Further research should yield a whitepaper soon, if I ever get time to write it.

Brian Marick's testing.com: http://www.testing.com/test-patterns/patterns/

A great example at CodeProject: http://www.codeproject.com/KB/architecture/autp5.aspx

RBSC: http://www.rbsc.com/pages/TestPatternList.htm

TypeMock Unit test patterns for .net: http://www.typemock.com/Docs/TestPatterns.html

Book: xUnit Test Patterns: Refactoring Test Code