Scrum Gathering Las Vegas – Day 2

• mayo 9, 2013• 4 min•

This post is a little late, but I wanted to make sure I wrote a summary of the important ideas before I left for San Diego.

The Agile CEO: Patterns, Principles and Practices (Charlie Rudd) – I was interested in this topic since it was about executive leadership.  When I arrived in the session, it was your standard speaker at a podium telling you their ideas.  OK…. I really did give this talk a good ten minutes before I bailed.  The thought of listening to this guy drone on for another 80 minutes was just too much.

The ScrumMaster Maturity Model: How to Assess Your Effectiveness at Enabling Hyperproductive Teams (Brian Rabon) – this talk was SO much better than the last and was based on Brian’s consulting experience helping Teams and organizations succeed with Scrum.  Brian has identified five levels of ScrumMaster maturity as a way to understand how effective the ScrumMasters are and how powerful their impact is with the organization.

  1. Wolf in Sheep’s Clothing – people at this level are intentionally (or unintentionally) using Scrum to micromanage the Team.  People doing this often enjoy telling people what to do and how to do their job.
  2. Scrum Scribe – individuals at this level are basically the Team admin.  Anything that needs to be documented ends up in their lap, but if the Scrum Scribe has any advice for Team on how to improve, they are completely ignored.
  3. Facilitator – this is the first functional level in Brian’s model equipped with the basic knowledge of Scrum and how to be an effective ScrumMaster.  People who are at this stage in their development are good at doing Scrum.
  4. Coach – individuals at this level have extensive experience with Scrum – they either have worked with many Teams or many organizations.  When a ScrumMaster is a Coach, the Team actively seeks out their advice and trusts their observations.
  5. Servant Leader – the highest level of Brian’s model are the people who inspire people to action and embody the characteristics of a Servant Leader.  As a true Servant Leader, these ScrumMasters take care of the Team’s needs, not just their wants.

Agile Project Management for Government: A Comparative Review of Agile Adoption in the US and UK Governments (Brian Wernham) – I was interested to see Brain speak in person since I wrote a review of his book on amazon.com.  In this short 30 minute talk, Brian discussed two Agile case studies he was involved with – the UK’s Universal Credit program and the FBI Sentinel program.  Some of the interesting conclusions from the case studies that Brian highlighted in his short talk were:

  1. A single Product Owner does not work in large multi-agency programs.  
  2. Understand and discuss up-front what types of data volumes a program expects in the final system.
  3. Water-Scrum-Fall may be inevitable (?) for large government programs which require extensive testing prior to release.
  4. Tight-Light governance – Brian’s concept of giving Teams room to maneuver and respond real-time – is essential for success.
  5. Senior government leaders cannot abdicate the management of program risk to federal contractors and other suppliers.
  6. Bring software development activities in-house, i.e. government employees build and test the features.
  7. Senior leaders in government get the need for Agile practices and it is the middle management who are invested in the procurement and contract models that are the greatest source of resistance.

Making Scrum Stick in Regulated Industries (Laszlo Szalvay) – I was curious to attend this session since some of my first experiences with Scrum were helping a San Diego biotech use Scrum to create medical devices regulated by the FDA.  During the presentation, the speaker shared an anecdote that large global shipping companies (UPS, DHL, etc.) normally staff their most experienced staff to work in customs since adhering to all the regulations associated with customs requires many years of experience in the business to navigate successfully.  This insight I found quite relevant for developing software regulated products – only should strive to have your most mature, knowledgeable and experienced staff work on products that require compliance to regulatory and statutory requirments.  I have seen the results of having junior (or immature) people work on regulated products – it is not pretty.