Introductory Slides

I started the topic by showing a few slides from the excellent presentation “Being an Effective Product Owner,” by Roman Pichler.  The slides defined the many attributes, qualities and focus of a good Product Owner.  As usual, I was awed by the person described there.  If you have such a person on your team, keep them!

We then reviewed the basic roles of Scrum, to put the Product Owner position in perspective.  As we discussed, I updated the marker board.

Open Discussion

Having consumed about 30 minutes with the contextual introduction, we opened the floor for questions and peer discussion.  This was great!  It was very easy to just bring up some aspect of a Product Owner’s work and have people ask and answer around it.  I apologize for taking so long to write this summary because I don’t remember all the things that were discussed.  Some I do remember were about:

• Getting the Product Owner to better fulfill the role.
• Product Owners for large teams or multiple teams.
• Dealing with enterprise deadlines as a Product Owner.
• What happens to the team when Product Owners make demands.
• How the role works on a large project with many Scrum teams.

I hope someone took great notes and is willing to share them with the group.  Post them or link to them as comment below.  I’d love to read about details I may have missed!

After Discussions

I enjoyed the opportunity to talk to each other about Scrum during the break and after the main part of the meeting.  Seemed everyone was networking and learning from each other.  That is exactly the sort of reason to have meetings, peer support and community.

Perry and I also asked for ideas about future meeting topics.  I published these on the group mailing list and repeat them here for convenience.

• How do things like architecture concerns, hardware requirements, costs and other constraints fit into the Scrum framework?
• Doing documentation in Scrum.
• The relationship between Scrum and other Agile frameworks such as Extreme Programming, Lean, etc.
• Working with quality assurance on or with a Scrum team.
• Do a user story workshop, as in actually fill out story cards based on a requirements document or feature list
• Using Scrum to develop video games
• Something about “future shock” (I just noted “future shock” but now don’t remember what that means. The person suggesting had some great ideas about it.  Please fill in the details!)

This is the beginning of a PhxSUG Meeting Product Backlog that we intend to make a way to publish and keep visible to the group.  (If you have a suggestion of how to publicly communicate our group backlog, please let us know!)

Thank You

The evening was a great success, from my view at the front.  Thanks to high participation by the attendees and great food from Some Burros and provided by our Infusionsoft hosts, I rather enjoyed the experience.  I look forward to more meetings and interaction!

Developer Certification

For quite sometime now there has been a great deal of discussion in the Agile community about certification.  The ScrumMaster Certification seen most of the focus in this discussion.  Starting this month, the Scrum Alliance is requiring the passage of a test in addition to the attendance at a 2-day workshop put on by a Certified Scrum Trainer.  The previous requirement of only attending the workshop has been scorned by some as a very weak certification.

A few months ago Ron and others were asked by the Scrum Alliance to consider the creation of a Certified Scrum Developer award.  This would be a certification similar to those for ScrumMaster and Product Owner.  Ron invited the public to the discussion on September 10th.  The Agile Developer Skills group exploded with discussion on this topic!

Ron and Chet choose to continue the discussion of developer certification at the meeting.  They first provided some significant context to start the discussion and then dove directly into the Ocean of Certification.

Provided below first are my observations about the event couched in an naritive as I remember it.  Next are points in the presentation that I found interesting.  This is all taken from my notes of the event and so is my perception of interesting and important.  Your impression may differ greatly so feel free to comment on anything I missed, glossed over or got completely wrong.

The Event

Ron and Chet arrived early and relaxed.  They mentioned they were well prepared with a stack of hand-written index cards they filled out during dinner just before coming.  They rejected the projector in favor of a marker board and a table.  They laid the cards out on the table in organized rows, chatted with people they knew or just met and then waited in the couch at the back.

Attendees arrived collecting pizza before sitting at the tables facing the marker board.  Perry Reinert efficiently introduced the meeting and presenters.

Chet and Ron were obviously well practiced with team teaching.  It was a wonderful sight to behold!  One would pick up the thread as soon as the other stopped speaking.  They took turns differing if one even hinted at speaking on top of each other.  They followed the cards on the table, picking them up for reference as needed.  Ron seemed to be the artist of the pair, drawing diagrams as needed.

They elaborated on Scrum as a framework that does not work without good engineering practices.  They gave a brief overview of XP practices and how they help maintain velocity of the team and support the success of teams using Scrum.  A discussion of good practices led into the need for developers that are Agile.  The characteristics of such a developer were a positive outgrowth of the work to define a need and content for the proposed Scrum Developer certification.

Then the cards ran out.

Ron started the discussion portion frankly stating that it looks like creating a Certified Scrum Developer course and award was too hard.  Many in the audience had various ideas about what such a certification would look like.  Some had been already covered in the Agile Developer Skills group emails and many were unique to me.  The idea ranged from working with an academic institution with undergraduate level curriculum to some sort of 1 or 2 week assessment.  All the discussion was well spoken and thought out.  I was impressed with the knowledge and talent in the room!

Stand-out Points

• “About 25% of Scrum teams get the full benefit of Scrum.”  – Ron quoting Ken Schwaber
• Why do so few benefit?  What can we do about it?
• In order to keep velocity steady or improving, we must keep removing cruft, refactoring, improving the design as we go and test consistently.
• “No high performing Scrum teams don’t also use XP [Extreme Programming] practices.” — Ron quoting Jeff Sutherland
• Pair programming is great for producing great code.  We never require it because certain environments (ex. distributed teams) or company culture do not allow it.
• TDD (Test Driven Development) is the best method of coding we currently know.
• Chet defines “overtime” as: Being at the office working when you don’t want to be there doing that.
• Ron defines “continuous integration” as: Minimizing the amount of time where one developer’s code is separate from all the other developers’ code.
• The “Gang of Four” patterns book is a dictionary, not a cookbook.  Don’t use it as a checklist but a vocabulary for communication and design.
• The Seven Pillars of an Agile Developer are:

1. Technical excellence
2. Business value
3. Confidence
4. Product understanding
5. Collaboration
6. Supportive
7. Self-improvement

• “I stand for excellence and I’m tired of hanging out with people who don’t.” — Ron quoting Jim(?) or Greg(?) Hill(?)
• How do we determine where a developer is on these Seven Pillars?
  • Test? No
  • College course? No
  • 1-2 week work assessment?
    • How to scale that?
    • Who pays for it?
• Ron is strongly leaning toward telling the Scrum Alliance that CSD is a bad idea and cannot be done “right.”

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>

Here are some pictures from the event.

I want to thank all of you that were able to make it a resounding ‘Kick-Off’.

Here is a link to some other pictures from Alan Dayley.