The meeting last night with “Agile Bob” was excellent.  Bob expressed thanks to everyone for a pleasant and intellectually stimulating meeting.

New Schedule

We announced that the group meetings will now start following a regular schedule.

• Our meetings will be held on the third Thursday of every month, starting on February 18th.
• We will strive to have special guests twice a year, on two of our regular meeting days.
• We will have special meetings outside of this regular schedule, as interest and opportunity present.

Please note, I announced last night that we will meet on the third Tuesday.  I was incorrect.  We will be meeting on the third Thursday of every month. Sorry for the confusion!

Back Story

Since the beginning of PhxSUG, we have been having meetings on irregular days.  The main reason for doing so is to be flexible for special speakers.  We have been able to accommodate their schedule to allow them to speak, since they were in town anyway.  The Steering Team for the group had several months of on-and-off discussion about this “random” schedule.  Some preferred to have a regular meeting day every month.

We finally chose to follow the regular schedule.  While we may not have as many special speakers, we feel the regular schedule will make it easier for local people to attend.  Your calendars can be planned out with the third Thursday evening set aside for whatever PhxSUG is doing.  Building the local community is very important.  We believe a regular meeting day will help do that.

And, we’ll inspect and adapt.

We appreciate busy schedules.  Every evening is precious time that must be spent in a valuable way. We are thankful when you choose to spend it with our community, growing our knowledge of Scrum and Agile.  We commit to making sure the time you invest provides great value to you and your teams!

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!

Please accept our appology.

We are working on a meeting announcement for November 25th. Watch for it soon!

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.”

The Phoenix Scrum User Group Steering Committee wants to create a thriving community around Scrum and agile practices.  Interactive communication withing the group is key to this goal.  Use of a Yahoo! Group has served the larger Scrum community well with excellent participation and information in the scrumdevelopment group, among others.  We want the email lists from our PHXSUG group to feed our knowledge and value as we improve our Scrum practices together.

To minimize spammer infiltration, requests for membership to the group must be approved.  We commit to approving all requests within 48 hours.

Please come join and add your voice to grow our Scrum community in the Valley of the Sun!