The Inovis Blog

After the All-in Scrum implementation at Inovis with 12 different Scrum teams launched across 6 different development sites, we were eager for some more Agile nourishment. Fortunately, the Agile 2008 Conference in Toronto afforded such an opportunity, so we rounded up some ScrumMasters and Product Owners and headed for the Canadian border.

Themed after a music festival, Agile 2008 offered a daunting list of sessions. With over 30 happening simultaneously on different stages throughout the hotel, it was hard to cover the entire conference (although I tried real hard to). In the spirit of a music festival where participants learn from each other, let me share some of the things that I took away from Agile 2008.

Don’t Forget to Facilitate!

Jean Tabaka (author of Collaboration Explained) ran an incredibly interactive session on facilitation tools and techniques. Along with some basic servant leadership skills (the mark of a skilled ScrumMaster), she had some excellent tips for better facilitation:

• Always start with a Purpose and Agenda to focus the meeting
• Use the “parking lot” wisely! (it is often abused as a black hole where things go in and never come back out for discussion)
• Let the team make decisions and use a fist-of-five to confirm consensus
• And my new favorite stand-up phrasing… (notice the focus on team commitment rather than status)
  • What commitments have you completed since the last stand-up
  • What do you commit to do until the next stand-up
  • Are you blocked in meeting any commitments?

Even though she had content and exercises for twice the time allocated, Jean followed her own advice in the session and made time to go through the “parking lot” of questions a few minutes before the session ended. Now that is facilitation by example!

Big Iron for Big Agile

Image Source: http://www.saasu.com/big-iron-saas/

Everyone knows the Agile practice of Continuous Integration, and it is easy to make it work on a single team, but how do you scale it? If not managed well there can be an explosion of servers and hardware requirements for running different builds per product/platform/codeline.

I asked the Enterprise Scrum panel this question and here is what they had to say:

• All the companies on the panel (including big names like Google, Yahoo, Salesforce.com, and the GAP) either currently had or were actively working on creating centralized infrastructure to support version control, builds, and other common Scrum team needs.
• One of the value-adds that they brought up was the ability to do metrics and reporting to gauge team progress (for instance, the GAP leverages statistics on check-in frequency to see if all the commits are happening at the end of the Sprint and they need to focus on getting smaller chunks delivered earlier).
• They all also had teams to support the infrastructure that were partially or wholly staffed by dedicated internal resources. (and in the case of Google re-inventing everything themselves… but that is the Google way!)

Enterprise Agile Highlights

Image Source: http://scalingsoftwareagility.wordpress.com/

One of the meatiest talks at the conference was Dean Leffingwell’s session on Scaling Software Agility. He had a lot of great points, but I’ll hit on a few highlights:

• The Secret Sauce for Distributed Teams - Are your teams spread across multiple development sites? Do you have time zone issues within a team? From an executive level none of this matters as long as you:
  • Empower the teams to self-organize for effective collaboration (there are plenty of tools and techniques to choose from)
  • Have everyone in the team meet face-to-face once a release (this is essential even if it is only a few times a year)
• Architecture and Agile Go Together - It is a common misconception that Agile doesn’t need architecture. It is quite the opposite, because Agile teams are constantly driving architecture changes and improvements through new stories and refactoring. In order to be successful at this, Agile teams need to embrace what Dean calls “Intentional Architecture” by following these 7 principles:
  • The teams that code the system design the system.
  • Build the simplest architecture that can possibly work.
  • When in doubt, code it out.
  • They build it, they test it.
  • The bigger the system, the longer the runway.
  • System architecture is a role collaboration.
  • There is no monopoly on innovation.
• ScrumMasters are Important, Product Owners are Essential - The success or failure of an Agile team weighs heavily upon the shoulders of the Product Owner, which, ironically, is probably one of the least understood role within the team. Dean spent a good portion of his presentation clarifying the role of a Product Owner, making some excellent points:
  • Qualifications of a Product Owner:
    • Communication - The Product Owner is the glue between the team and the customer, so they must be able to translate business requirements to user stories and also be able to present the complete functionality back to the customer.
    • Technical Skills - In order to triage requirements and scope stories to manageable chunks, the Product Owner needs to understand the technical trade-offs and be able to express this in language the Agile Team can understand.
    • Trust - Finally, the effectiveness of the Product Owner in accomplishing the above items depends upon their credibility with the team and ultimately the Trust to make the right decisions and trade-offs.
  • The Product Owner must be part of the development team which means:
    • collocated with the team
    • held to the same performance measurements as the team
    • (ideally) reports in to the same line management as the team
  • Perhaps the most surprising new tidbit for the audience was his current advice to separate Product Management and Product Owners. In his experience with successful large companies, the external facing role of Product Management went largely unchanged, and Product Owners were closer in role to a Business Analyst or Technical Product Manager. At the same time, Product Owners and Product Managers necessarily work very close together.

For more details, Dean has an excellent blog dedicated to Scaling Software Agility:

http://scalingsoftwareagility.wordpress.com/

If it Hurts, There is a Problem

Ron Jeffries had a great talk on deriving Agile Principles from the Natural Laws of Software Development, which besides being interesting (Chet and Ron had a great stick going), reinforced some best practices that are intuitive but often forgotten or ignored.

For example, one of the biggest temptations in Scrum is to wait until the last few days of the Sprint to finish development and then squeeze QA down to the point where they are either working massive overtime or have to finish QA the following Sprint. This is driven by the desire to overcommit and underplan, but inevitably comes back to bite the team with a buildup of QA debt as development outpaces testers, quality issues and defects interrupting the next Sprint, and reduced team morale (this hurts!).

But what if during planning you committed to only your average velocity (not the peak all-time velocity) and you planned stories that were no larger than 2 or 3 days (depending on if you ask Ron or Chet, respectively)? With small incremental chunks not only would you provide customer value earlier, but the QA team members would have something to test immediately, rather than waiting until the last day of the Sprint to get started (an Agile solution!).

TDD is for Rockstars!

Image Source: http://www.flickr.com/photos/lassekoskela/2755587371/

One of the coolest new sessions at Agile 2008 was the lunchtime Programming with the Stars competition. Agile coding “masters” were paired up with some conference participant volunteers to compete using Agile development practices. What resulted were some of the best (and worst) examples of Pair Programming, Test Driven Development (TDD), Refactoring, and Mock Object usage ever seen in a timeboxed, live demo. The judges were equally humorous and colorful in their no-holds-barred retorts and cowboy western judging style. Nothing was off limits from slams against Apple/Windows, IDEs (or lack thereof), and decrepit languages (TDD in C++ anyone?).

The winning team of Lasse Koskela and Noah Jacobson had an awesome example of TDD on a video playback using Mock objects. Most developers would shirk that off as too hard to test, but these guys were Rockstars! Some other cool demos included some hardcore TDD in C++, barebones TDD in Javascript, and some very cool test runner bars that continually ran the unit tests in the background immediately turning red on failure and green on success (this was a real crowd pleaser!)