The one big thing I don't do is claim to teach Scrum. I teach most of the parts, such as user stories, backlogs, velocity, and daily standups (not "scrums"), but there are a couple of terms I avoid and actively un-teach when students come across them.
SprintSprint says run like crazy, but not for very long. I know that's not what "Scrum Sprint" means but that's what "sprint" means. Words matter. I want my students to see development as steady loping, not repeated mad dashes. There's just one sprint in my course: a hackathon at project start to get the very first testable slice to the client. This first mad dash has benefits for the product, developers, and client-developer relationship. The one bad side is technical debt but the code base is still small and you have plenty of time to pay off technical debt. I use iteration.
The length of sprints, from two to four weeks, is also problematic. For anyone new to agile, I prefer one week. Move to two weeks when things are humming along -- or move to continuous delivery and drop iterations all together.
Scrum Master[Edited January 30, 2017]: Master? Words matter. Master sets up a power relationship with developers I am not at all comfortable with. Even worse, here is how Scrum Master is defined in the Scrum Guide:
The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules.
No wiggle room here. A Scrum Master is an enforcer. The Scrum Master tells you when you are and are not doing Scrum properly. This is about as far removed from a role I would want someone to play as can be.
What do I teach is the needed? Agile coaches. The role of an agile coach is to help you identify ways in which team and business needs could be better served. An agile coach is good at
- detecting when things are going off the rails before the team does
- identifying counter-productive processes and attitudes
- suggesting simple and effective things to try to improve the development of both the product and the team
- making these ideas real with stories from personal experience and case studies
IncrementMy minor grump is the definition. The Scrum Guide defines an increment as "the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints." This is an odd use of increment. In normal English, an increment is an increase or addition, not the accumulated total.
But my real grump is with the commentary under the definition of Done: "Each Increment is additive to all prior Increments." I am not the first to note that an additive view of implementation fits very poorly with the realities of product development. I use version with no commitment to steady growth. Build-measure-learn.