From time to time we see people complaining about Scrum and Agile being sold as a magic painless solution to all your problems. We can't seem to catch anyone in the act of making these claims.

So who's going around saying Scrum is a silver bullet, and that it's all you need? Ken Schwaber's not saying this; Danube isn't saying this; other Scrum trainers and coaches aren't saying this ... at least not when I'm around. We're all saying quite the opposite. I see more complaints about hype than actual hype.

Starting April 1, 2009, you will need to pass a multiple-choice test, in addition to taking a CSM class, to become a Certified ScrumMaster.

This step was debated in the Scrum training community. I was initially skeptical whether a multiple choice question could add any value. But I've become convinced this is a positive step after being involved with the process of writing test questions, doing peer evaluations of test questions, working with the ScrumAlliance's testing company (including a "psychometrician"), and actually taking the beta test in Stockholm (tying for the top score of 89 -- which isn't really fair since I'd seen a third of the questions beforehand).

A number of CSTs, including two from Danube, were involved in creating and reviewing test questions. Most of the questions that made the Stockholm beta are pretty good. Some should be discarded or reworked.

If only it were as easy as rocket science!

Writing fast reliable multithreaded software is a harder problem than rocket science.

A famous example of this was Therac-25, an X-Ray machine that occasionally killed people due to multithreading issues.

It's even harder now that we usually have multiple processors/cores running the same program.

Ken Schwaber and the rest of us advocate paying attention to what "done" means for a Product Backlog Item (PBIs, or "stories"). For a lot of programmers (like me), "done" often means "It works on my workstation!" The ScrumMaster is charged with advocating a "done" that includes everything else needed to build a potentially-shippable product increment.

There's still some confusion out there about whether the Product Owner is a member of the Scrum Team. Rather than pile on the confusion, please stick to Ken Schwaber's terms: "Scrum Development Team" for the subset of the team that excludes the Product Owner, and "Scrum Team" for the dev team + ScrumMaster + Product Owner. These are defined by _The Enterprise and Scrum_ (Schwaber 2007).

I attended your training class a couple of months ago. We are continuing along with our scrum process, and we are learning a lot. I have one question - hope it is ok to ask. We did story point estimation as part of our team's Sprint planning, and came up with the total story points that we were going to tackle for the sprint. As we started working on some of the tasks, we realized that they were more difficult then we had originally estimated. Also, some people finished their tasks early and picked extra stuff from the backlog.

My question is as follows: Do you ever change the total story point value in the middle of the sprint (for either of the reasons that I mentioned above), and it if so, how would that work if your burn down is based on story points vs time. I know we talked about it in class, but I can't remember the answer.

I remember asking my own Scrum coach the same question a few years ago.

A Scrum Team is:

• A Product Owner
• A Scrum Development Team
• A ScrumMaster

Organizations that are looking for an automated tool to help manage Scrum fall along a continuum.

• At one end are the Scrum purists, who feel that resistance to doing real Scrum is an organizational impediment to be exposed and rooted out rather than accommodated as business as usual. These folks believe the highest performance and ingenuity comes from intense collaboration, small cross-functional teams lacking defined roles, self organization, face to face communication, and even a certain amount of chaos during Sprint execution. They typically prefer lightweight tools that make the Scrum artifacts visible without impeding team self organization.
• At the other end are those who want some version of the Scrum/Agile practices, but also feel "traditional" practices (such as Taylorism, waterfall, or parts of the PMBOK) would meet their current needs. They may be dealing with impediments to self organization, lack of co-location, suboptimal team composition, large departments, entrenched practices, regulatory requirements, etc. Or they may not be in a position to wait for teams to go through the "forming, storming, norming, performing" growth stages. These folks tend to request features that make the purists cringe.
• Some are in organizations that are transitioning from traditional practices to Scrum. Some skeptics I've known became full-fledged advocates after seeing results from pilot teams attempting uncompromised Scrum with good coaching.

I've collected a dozen Dilbert cartoons relevant to Scrum. This week brings us a couple cartoons depicting a dysfunctional daily Scrum (an exercise we sometimes use in class). Previous cartoons have lampooned user stories, working without plans or documentation ("Just start coding and complaining!"), and forcing Agile approaches from the top down.