Global Scrum Gathering 2017 Notes

I used to attend Agile and quality related conferences years ago and have saved notes from many of them. While some topics have become overtaken by events since then, there still seem to be some useful ideas that I’d like to pass along. [These are notes from other another attendee (Christopher Trudeau) as I don’t seem to have mine.]

Keynote: Jeff Sutherland: The Shu Ha Ri of Scrum @ Scale

Jeff Sutherland spoke at length about Scrum at scale, adding his voice to a common topic in the industry. The point he hammered home hardest was that most problems of Scrum at scale are not caused by scale but by not being Agile. Common patterns he has seen in the industry are Scrum at the team level but waterfall management practices, badly prioritized backlogs, architectural dependencies, legacy systems, antiquated engineering practices, and 3rd party waterfall outsourcing.

He outlined 4-dimensions of growing Scrum:

• Scale — the number of teams involved
• Distribution — how geographically distributed are the teams, or worse portions of the teams?
• Saturation — how prevalent are the Agile principles within the organization?
• Velocity — how is velocity being managed? Ten teams, five times as fast is better than fifty teams.

Scaling is still a significant challenge in the industry. Agile teams still aren’t delivering: 61% of Agile teams are failing at scale. This is an improvement over the 89% of failing teams in the waterfall world, but still nothing to brag about. He recommended a focus on the team level. This should happen within IT and and at the business level through a tightening of the product ownership loop. In large organizations this change needs to come from upper management and so requires buy-in well beyond the Scrum team level. Training is needed at the management level (see also Dave Sharrock’s talk from SGCAL) with a focus on teaching them how to get out of the way and letting the teams be effective.

As for methodologies, Sutherland is a fan of the “fractal application of Scrum”. Most of the successful projects he spoke about used Scrum-of-Scrums up to the fourth or fifth level. These meta-meetings are both on the management side (EAT: Executive Action Team) and in the Product Owner space (EMS: Executive Meta-Scrum). The EAT is done to create a quick escalation path for removing impediments the EMS is used to clarify product backlogs and provide portfolio management. He gave an example from the SAAB Gripen project where there are 5 dailies: starting at 7:30 at the team level, 7:45 for S2, 8:00 for S3, 8:15 for S4 and 8:30 for the EAT.

Scrum-of-Scrums to Scale and Manage

Organizationally, the problems often go right to the top. It is common for the CEO to want faster teams and claim to be embracing Agile for this to happen, but still want the reports that waterfall generated. The changes need to be to the culture, he gave an example where 3M has changed the HR department to now be called Agile People Operations.

“To implement Scrum at scale, first you have to implement Scrum.” — Jeff Sutherland

Thomas Friend: Scrum To The Stars

Thomas Friend is a Business Agility Consultant who spoke about Agile processes at NASA. With varying degrees of success, NASA started a new approach to its projects in the nineties called “Faster, Better, Cheaper”. The idea was to focus on smaller, more specific projects rather than larger more complicated ones. Successes during the use of this approach include the Near Earth Asteroid Rendezvous (NEAR) project. NEAR actually completed with a budget underrun, something almost unheard of at NASA.

In the first six years of Faster, Better, Cheaper there were 9 successful project and only one failure. Unfortunately, this record changed drastically in 1999. Friend blames the change on the increase of management’s involvement with the product backlogs.

Although Faster, Better, Cheaper is no longer in place at NASA, some of its spirit lives on. Joint research with universities has resulted in the creation of cube-sats: small satellites in a standardized 10x10x10 cm package. These packages get their computing power from the same technologies used in cell phones. By standardizing the packaging, university scientists have been able to hitch a free ride on many of NASA’s existing rockets. The weight distribution of a rocket is rather important so NASA currently uses aluminum panels it can attach in the payload area to achieve this balance. The Pico Satellite Orbital Deployer is a device that fits the same configuration as the ballast but contains the cube-sats. Over 500 cube-sats have been deployed and much of the packaging and internals are now based on COTS components.

NASA’s after-action report on Faster, Better, Cheaper is publically available.

Woody Zuill: Mob Programming

Woody Zuill gave an introductory talk to Mob Programming: a more extreme version of XP’s pairing. The thing I liked most about the talk was Zuill’s self effacing style, he openly said he wasn’t advocating Mob Programming or saying it would fix your problems, simply that it had worked for his teams and he wanted to share the experience. The honesty in this is refreshing, especially when people so often present their ideas as silver bullets.

Similar to a Scrum team, a mob programming group needs to have all the skills required for a given project present. This includes business representation and any necessary development and testing skills. The model uses the driver/navigator pattern of paired programming: one person is using the keyboard and the other is expressing the ideas needed for coding. Zuill modified this concept to use multiple navigators.

The idea evolved out of a coding dojo where the driver/navigator pair was used for teaching and practice. The rest of the team was meant to be quiet and observe and then given turns at navigating and driving. Zuill commented that he believes one of the reasons mob programming worked was that although there are multiple navigators, they had gone through the coding dojo exercises and knew when to speak and when to be silent — a process far less chaotic than its title might imply.

The recommended practice was for the main navigator to become the driver and the driver goes to the back of the queue of navigators. This rotation should happen every 7–10 minutes. For any idea to get into the code it must first go through someone else’s hands.

A team needs to be working well together already for this to work. A collaborative environment is necessary, one where the team knows who the experts in any given feature area are. At any time, members of the team will float in and out of the mob. The “law of two feet” rules: if you don’t feel you’re being useful or need to focus on something else, leave the mob and come back when you’re ready.