Previous: Agile Estimation Techniques – Next: Scrum in Game Development
Note: Scrum Masters should watch out for the mentioned Bad Smells and Anti-Patterns!
Be sure to watch Ken Schwabers short presentation on “ScrumBut” first when you think things aren’t going as they should with Scrum.
“The project was canceled because it turned out to be unclear, overambitious and unrealistic. The wanted to build too much stuff in too short time. Scrum was the messenger that helped them fail early rather than late.”
Henrik Kniberg is the author of the book Scrum and XP from the Trenches (PDF) which is also available as softcover print from InfoQ or other places like Amazon. It’s a short book full of war stories and best practices and i can highly recommend it!
Here’s Henrik’s lecture detailing the 10 bad smells that you can use to check wether you’re failing to implement Scrum properly, and where. Very interesting, even though you can’t see it, is the audience’s participation. They hold up green, yellow and red cards and Henrik sums it up for the viewer what the audience thinks about their Scrum problems.
Here are Henrik’s presentation slides. You can use them to do the presentation at your company yourself because primarily all that is needed is a good moderator who knows how Scrum works in principle.
And here you can download the mindmap he mentions in his talk: Scrum Checklists – are you really doing Scrum? (Henrik Kniberg, PDF & MMAP)
And Gojko Adzic has extracted the 10 ways and turned it into a checklist, too. Sweet!
Good tips on how to make your project fail. You do want your project to fail, don’t you?
Mitch describes a Scrum project that went downhill mainly because the costumer did not understand Scrum and the developers not holding the costumer accountable on their decisions and asking the unpleasant questions. After half an hour the audience starts actively participating in this talk which makes it very worthwhile to watch. Note: compared to other online lectures you can actually understand the audience’s questions for a change.
Hyperproductive Distributed Scrum Teams (Jeff Sutherland, 90 min)
This lecture is especially helpful for implementing Scrum in a distributed organization. I am tempted to say that this is also helpful for any company whose teams don’t all work on the same floor. Many may find it curious and surprising how much of a barrier as little as a few stairs can introduce!
Mainly focuses on the Mythical Part-Time Scrum Master
- Break apart the team when the current project is complete
- Keep the individual/team compensation plan a secret
- Don’t openly share financial data with the team
- Lay people off on a periodic basis
- Refuse to aggressively invest in employee training
- Keep the team ignorant of corporate goals and plans
- Do not allow any “slack” time
- Always cave in to the demands of the customer, regardless of the impact to the team
- Allow the customer to “cherry pick” the team members they want
- Ignore the skill set of team members when building a team (”Hey, aren’t we all cross functional?”)
- One word stories
- Technical stories
- Stories missing goal
- Stories missing user role
- Stories specifying architecture
- Customer doesn’t understand stories
- Boring stories
- Too many stories
Yes, even projects using Scrum fail. But are they really using Scrum properly? The expert gives us his opinion in this annotated video interview. See also his corresponding paper: 7 Ways to fail with Scrum (Jeff Sutherland, PDF)
This slideshow contains a couple real world examples of Agile/Scrum implementations that are easy to read and follow. It gives you a few quick & dirty tips on what to do and what not to do. Moreover, you don’t need the lecturer’s talk to really understand the bullet points (eg they are descriptive).
Agile Implementation at Nokia, Team Health Report, Anti-Patterns and Recommendations
Another presentation by Jeff Sutherland with lots of data collected from his Scrum experiences.
The Ordinary is very seductive. It whispers warmly in the ears of your teammates, “Why change now? Why mess with a good thing?” The Ordinary croons some of my favorite tunes, “If it ain’t broke, don’t fix it.” And “Good enough.” The seeds of The Ordinary seek to take root everywhere: in your goals, in your user stories, in your code, in your impediments. When things get “ordinary” on an agile project, it’s really the beginning of the end.