1st Meeting Review – Schwaber “Scrum, But…” Talk

We did it … and it was awesome!  Over 80 people showed up last night for the first-ever Phoenix Scrum User’s Group.  A funny thing about the event is that it turned out to be yet one more application of the 80 / 20 rule.  We had about 80 people who ate about 20 pizzas!   A slightly more interesting statistic … from the ultra-accurate, raise-your-hand analysis, showed that about half the people in the audience are already Certified Scrum Masters (about 30-40 people).  That means we have some talent here in Phoenix.  Now let’s get onto the meeting.

Ken Schwaber was speaking live, but remotely via Goto Meeting.  The technology worked OK, but not perfectly.  The video feed seemed to freeze occasionally for about 3-5 seconds, and the streamed audio was not the best.  The audio actually got quite good when we held the cell phone up to the microphone – very high-tech!  That said, everyone who attended tolerated the minor challenges pretty well, and they all seemed very interested in Scrum, the User Group, and future meetings.  The other good news is that Ken agreed to come back and do another talk for us, and he assured me we’d test and improve on the technology beforehand.  That talk will likely be in the fall time frame.

As for this talk, Ken Schwaber kicked it off with his talk titled “Scrum, But…” (here’s the .pdf).  He began with a relatively quick overview of Scrum as background, and he then proceeded to explain the concept of “Scrum, But….”  This “Scrum, But” talk addresses a very common comment:  “We use Scrum at our organization, BUT because of <some difficulty> we have had to modify Scrum to make it work for us.”   So a “Scrum, But” is simply some reason (yes, often a “lame” reason) why a team/organization can’t take full advantage of Scrum.  One of the beautiful things about Scrum is that it brings to light dysfunctions within the organization.  Some people forget this, and instead of trying to resolve the dysfunction, they try to “fix” Scrum to make it work with their dysfunction.  Ken also pointed out that only about 30% of the teams that attempt to do scrum actually succeed.  The other teams end up doing “Scrum, But”.   Some examples of “Scrum Buts” include (also in above .pdf):

• We use Scrum, but we can’t get everything done in the development sprint, so we have added other “special” sprints.
• We use Scrum, but our teams don’t see a need for a daily meeting, so we meet only on Tuesday and Thursday.
• We use Scrum, but our developers just don’t take the initiative to be “self organizing”, so our Scrum Master tells them what tasks to do and when they should be done.

Ken had the group do an exercise that included splitting into small groups and discussing how to handle Scrum in a distributed environment (e.g., people in Europe, California, and Phoenix).  That was a good exercise, as it got people talking with each other.  People liked talking about their experiences and challenges.  We are definitely going to do more group work in future meetings.  Oh, and the best answer to the distributed environment question…”Don’t do it – use a co-located team” (sorry).  Actually, some other options included:  Use a wiki or an irc-like shared chat tool for communication, trade meeting times so all teams share in the off-hour meetings, use tools like Rally or VersionOne to manage the user stories and tasks.

Another good question from the audience was – “We need the complete analysis to get the project funded, so how do we do this analysis when we’re supposed to be working one-iteration at time?”
Ken explained that:

• 35% of a projects requirements change
• 50% of the features initially scoped are rarely used

Because of these statistics, following a waterfall approach (or doing a “complete analysis” with a complete requirements list) is simply the wrong way to look at the problem.  It just doesn’t make sense to waste the energy on the 35% of the requirements that are going to change.

Jim Cundiff took over when Ken finished.  Jim talked for about 30 minutes on the Scrum Alliance.  We had an interesting talk about Scrum Master Certifications, and the new certification exam.  So, yes, there WILL definitely be a certification exam (See this for the latest).  The reasoning behind the exam is that without the exam, you really just have a “Certificate of Attendance”, not a “Certification”.  The exam will legitimize the “Certification”.  The exam is now in its second Beta, and people at the Scrum Gathering in Florida were able to take the Beta exam.  The exam will be a computer-based, non-proctored, multiple-choice exam that covers objectives from four major Scrum topics.    Some other key points about certification:

• The official CSM exam “release date” is pending analysis of the second beta.
• Certification is good for two years (for CSM, CSP, and CSPO).  People who certified before April 1, 2009, must re-certify by April 1, 2011.

Jim also gave some statics about certification growth:

<To be Inserted here>