Early Agile Scaling at Adobe

Scaling agile is a hot topic these days. I’ve recently given a presentation at a few local user groups about the experience of scaling agile at Adobe. The presentation describes early scaling as well as our experience helping a large shared technology group adopt a model using the Spotify Approach as a template. Below is a synopsis of the early scaling approach which naturally emerged at Adobe.

Viral Agile Adoption vs. Mandated Agile Adoption

Agile at Adobe was a grass roots effort. There was never a mandate from an executive that “thou shalt use Scrum”, and I think that this is an effective adoption pattern. Executive support is critical, but an executive tell can be a death knell for any initiative. Starting with a few product teams in 2005, teams adopted scrum when their peer teams noticed the benefits that the early adopters were having.

“Proof”

One of the challenges with convincing later adopters is that they are typically looking for more concrete evidence before risking a change. A challenge with providing evidence of the effectiveness of scrum is that many metrics are different between traditional development and agile development. One metric that remains the same for most projects is open defects. On a traditional project, the total number of open defects will grow during feature development, then rapidly decrease as the team focuses on fixing and/or deferring open bugs leading up to the ship date. On a scrum project, every sprint the total number of defects should approach zero as the team gets the iteration “potentially shippable”. We can compare the total open defects from the release cycle prior to adoption an agile approach with the first release cycle using scrum and see the difference. Below are the charts from five Adobe products that adopted scrum showing this data:

What these graphs don’t show is the impact the lower defect counts had on the team. After adopting scrum, the Audition team’s final months leading up to the release of their product required no weekend work, no late nights; essentially a low-stress, high confidence release. Other teams that had not yet moved to scrum noticed this and started asking what the Audition team were up to. Seeing our defect curves and the fact that we were spending time with friends and family while they were working weekends trying to get their bug count down was a major impetus to them investigating and eventually adoption scrum.

The other impact of these defect rates was on the quality of the product. When you are trying to get a huge number of bugs reduced down to zero, that often means painfully deferring bugs that you really think ought to be fixed in order to meet the date. Without this time pressure, bugs were much more frequently fixed rather than deferred, resulting in an overall improvement in the final quality of the release. There is also some data that suggests that waiting to fix a bug substantially increases the overall cost of fixing it, and so waiting until the end of a multi-month release means that the overall cost of fixing bugs was much higher before moving to scrum.

Typical Adobe Product Team Structure

Moving into the scaling topic, most Adobe product teams are larger than seven people, and so scaling patterns were built into our approach from the earliest implementations. The picture below illustrates a typical scaling approach for an Adobe product team.

With one notable exception, this is a standard scaled scrum approach. We have multiple scrum teams working on related sets of features within the larger product context. The primary difference is how the Product Owner role is played. Prior to adopting scrum, the Audition team had a management group called the Feature Council. This group comprised an engineering leader, a test leader, a product manager, a program manager, and a user experience leader. They collaboratively made decisions regarding the vision, staffing, features, and other related areas. When we learned about scrum and the “single set of vocal chords” product owner role, there was no exact fit. While our product manager was awesome, we had never seen him as the single voice for product decisions. We felt that his was one very important perspective, but that we got tremendous benefits from including other perspectives (technology, quality, design, and process). We decided to keep the feature council intact and have it collectively play the Product Owner role. We decided that if we couldn’t reach consensus on a prioritization decision, our Product Manager would then make the call as the “Ultimate Product Owner”. In several years, we never saw this happen.

The scrum teams handled technical coordination through weekly meetings of the various competencies (Engineering, Testing, etc.), similar to the Spotify Chapter Meetings.

Upcoming Classes

Peter regularly provides Certified Scrum Master and Certified Scrum Product Owner courses throughout the western United States. If you are a member of a local Scrum User Group, you are eligible for a 20% discount – please contact Peter for a discount code. Check out his next courses in the Salt Lake City area August 17-18 (CSM) and August 19-20 (CSPO):

August 17-18 Certified Scrum Master

August 19-20 Certified Scrum Product Owner