You are not a member of this wiki.
Best Practice - Look to the Scrum Guide *First*
Details of Coaching and Consulting services
For Training, Coaching, and Consulting engagements, please
for details on how I can help your organization.
When teams struggle with Scrum, it is my strong opinion that they should look
* to the
* to the Scrum Guide, if they are an experienced team)
A more complete way of saying this is:
When teams struggle(whether they be beginner or experienced), it is my strong opinion that they should look
* to the Scrum Guide,
secondarily to other resources (books, articles, online, other professionals) for help. In fact, read and learn as much as you can from the Scrum Guide and the secondary resources. So long as those other resources don't contradict the Scrum Guide, then it's probably ok to try what they suggest. If those other resources do contradict the Scrum Guide, then think long and hard before deviating.
I have observed the following Anti-Patterns with respect to Scrum implementation.
Faux Scrum: Disinformed or Misinformed
1. Someone advocates a practice that is not consistent with the Scrum Guide.
2. The team struggles with that "something, " often times because the "something" is not really Scrum at all.
3. Rinse and Repeat until either:
a) "Scrum" is a dirty word in your organization, or
b) your organization settles for mediocrity, or
c) you decide to move on to some other process(besides Scrum), or
d) your product becomes a dismal failure, or
e) until someone figures out what you are doing is way out of line with the Scrum Guide vision, and tries to help you get back to basics.
A good example of this:
The Afternoon ScrumMaster: Keeping Agile Teams on Track
Not all deviations from the Scrum Guide end in disaster, but they can.
Faux Scrum: Give up quickly and Deviate from the Scrum Guide
1. A team struggles mildly with implementing some practice described in the Scrum Guide.
2. Rather than retrospect and improve their implementation of the practice as the Scrum Guide would suggest, they choose a different practice that deviates from the Scrum Guide, usually with negative consequences that that team may or may not have the ability to immediately see.
3. See step 3 above.
Faux Scrum: Pretend you're doing Scrum
1. Pretend to be doing Scrum, but instead use a bunch of your existing practices instead of what the Scrum Guide suggests. "Hey look, Mom! We're Agile!"
2. Rename a lot of your old practices, artifacts, and roles with Scrum terms. Proceed as usual with the status quo and tell everyone in your company how Agile or how Scrummy you are.
3. See step 3 above.
(Ken Schwaber calls this the "Methodology Facade Pattern")
Faux Scrum: Selective Scrum
1. Like you did successfully with WaterRUP processes, selectively pick a small number of Scrum practices and implement those only.
2. Enjoy the new practices, but be sure you stop progressing towards the Scrum Guide vision either because you get too complacent or too busy.
3. see step 3 above
The Power of Positive Thinking
I know what you're thinking. Man, this guy is negative! If you spoke to people in my personal or work life, I think they would tell you that I'm generally a very positive person. I'm even hilarious at times, but that's hard to convey in prose about intellectual topics. I think, though, that they would also tell you I'm a very detailed person, and that I'm honest and direct about serious subjects.
So, rather than call everyone "Chickens" and "Scrumbuts" and "Faux Scrumites", what I do instead is I advocate a positive strategy.
That positive strategy is : When deciding how to proceed with Scrum, look to the Scrum Guide *first*.
If you look at my
, I generally give positive advice, but I also don't shy away from Worst Practices, Anti-Patterns, Bad Smells, and Traps. Any good tester tests happy, sad, and bad paths, usually with particular attention to the sad and bad paths. I do the same. I also make sure that I propose solutions to all of these Worst Practices, Anti-Patterns, Bad Smells, and Traps. I do want to help, but sometimes people are not Scrum knowledgeable enough to recognize the bad practices.
Sometimes, to convince people to get back to basics, I have to point out where they've deviated from the Scrum Guide. This usually involves quoting the Scrum Guide. Yet other times, to further convince people to get back to basics, I have to express some of the possible advantages and disadvantages of their current strategy. That's part of being a Scrum Coach and
, and comes with a certain amount of resistance. I'm ok with that. The reason I'm ok with that resistance is that I do it because I passionately and honestly believe it's the right thing to do.
help on how to format text
Turn off "Getting Started"