Harnessing Innovation: Lightweight Governance Models for High Performing Agile teams

I recently gave this presentation (harnessing-innovation) at a private, in-house agile community gathering for a large software enterprise. The focus was obvious from the title, how does the larger enterprise harness the agility, innovation (and yes, entropy) of all those newly empowered agile teams? Can they apply governance models that provide for some effective controls without killing the goose that lays this golden egg? Perhaps this quote sums up our agile strategy best:

“Although project teams are largely on their own, they are not uncontrolled. Management establishes enough checkpoints to prevent instability, ambiguity, and tension from turning into chaos. At the same time, management avoids the type of rigid control that impairs creativity and spontaneity. Instead, the emphasis is on “self-control”, “control through peer pressure” and “control by love”.

‒ By Toyota’s Takeuchi and Nonaka, The New New Product Development Game, Harvard Business Review, 1986 (see note (1) below)

A few key highlights from this presentation are highlighted below.

In the agile enterprise, managements need for results must be greater than the need for control

• But it is appropriate to create agile guidelines as governance documents
  
  • What agile means in this company
    
  • Expectations for agile behavior
    
    • Define unambiguously agile mandates (Examples: unit testing, retrospectives, daily standup)
      
• As lightweight as possible
  
  • 3-5 pages
    
  • Serve as templates for additional site-based or project specific guidelines
    
• Recommend, but don’t over-prescribe
  
  • Especially around the more controversial practices, like pair programming, TDD, tooling, requirements management, intentional architecture
    

Note (1): this seminal article in the Harvard Business Review in 1986 is the best article I’ve ever seen on the principles and practices of concurrent engineering from the Toyota perspective, and is further described in the post The New New Product Development Game and the Roots of Scrum. https://scalingsoftwareagility.wordpress.com/2008/06/05/the-new-new-product-development-game-and-the-roots-of-scrum/.

Advertisement

Failing “soft” is an Option in Agile

Recently, I noticed the following interesting post from BMC’s Paul Beavers: To Be Successful with Agile, Failure is More than an Option, it’s Necessary.

Paul highlights: “Failure from time to time is expected – trying, assessing, and adjusting are not optional”. This correlates with my experience as it’s in the stretching, and occasionally failing, in agile that creates the fastest learning environment and the highest end-result productivity. Of course, it’s best to fail soft rather than to fail hard. What I mean by this is that the rapid iteration cadence provides opportunities to fail soft at the iteration boundaries. These early failures help assure that the bigger and more consequential failure, failure to release, is a much lower probability.

As agile master Alex Yakima once commented while looking at an upcoming release plan and the few remaining iterations, “nope, not enough times to fail“. So we shortened the iterations (down to a few days in one or two cases) and made the release on time.

Editors update: I just saw this sign on the iteration tracking wall in an XP shop:

Fast failure is an option!

Announcing SSA Courses, Sep 11 & Nov 6, 2008

I’ll be delivering only two public courses of Scaling Software Agility: Best Practices for Large Enterprises this fall. Both will be held at Agile University in Boulder, Colorado. You can see the abstract and register for the course here. While the course is based on the book, the material is constantly updated based on my ongoing experiences helping some of the world’s larger software companies transform themselves to become an agile enterprise.

In addition to the delivered content, the small group setting provides an opportunity for informal discussions of some of the real world challenges that attendees face. Obviously, since most attendees face significant challenges of agile adoption at scale, the shared learning environment facilitates experience sharing and practical problem solving in the enterprise context.

Hope to see you there.

The Agile “Shine On” (Visibility and Truth in Agile)

Recently the post “Zero to Fear in 60 Seconds” appeared in Agile Juice . This great post highlights some of the challenges with the transparency and fact-based status assessment that agile purports to deliver. Simply put, it’s not unusual (at least initially) that the apparent visibility provided by the daily standups and story status tracking may paint a far rosier picture than the facts warrant. The post points out that these problems may not be discovered until the hardening iteration, by which time it is too late for effective corrective action. The article provides some rationale for this behavior, along with some recommendations.

Perhaps some of the reasons for this initial “agile shine on” (overly optimistic reporting) include:

1) our organizations and software development practices haven’t necessarily evolved in a fact-based way prior to agile adoption (typically reporting on plan until it’s proven that we are not)
2) companies have sometimes used the facts as bludgeons, rendering a fact-filled environment risky for the fact provider
3) people are people and asking them to step up to the bar of personal accountability is not a guaranteed win for all practitioners (the bar may be too high for some)
4) people would rather not deliver bad news

This just reminds us that visibility isn’t free and initially, it may not even be transparent!

So as leaders,  we must constantly foster and encourage the delivery of truthful and factual information at all times. We must never punish the messenger; rather, we adjust the process. Remember, the Facts are Always Friendly in agile.

Agile 2008 August 4-8 in Toronto

The Agile 2008 conference has recently announced the program for this summer’s meetings in Toronto. To quote from their brochure:

“It brings together executives, managers, software development practitioners and researchers from labs and academia. The conference is not about a single methodology or approach, but rather provides a forum for the exchange of information regarding all agile development technologies.”

This has evolved into the one “must attend” conference for agilists worldwide. There will be a number of tutorials and discussions focused on enterprise agility, including my tutorial on Scaling Software Agility on the main stage, on Wednesday, August 5^th at 4:00 PM.

If you and your enterprise are serious about agile., you should be serious about attending this conference too.

Recap: SEVEN Principles of Agile Architecture

Those following the agile architecture series will probably note that the principles and labels have morphed over time. I’ve been collaborating with Ryan Martens, Rally’s founder and CTO, and Mauricio Zamora, Executive Director at CSG Systems, in writing a whitepaper to be published on this topic. In the process, we’ve also had some comments from Grady Booch and Philippe Kruchten and the content has been evolving as a result. The article is nearly finished and I’ll post it here just as soon as it’s available.

In the meantime, here’s the (hopefully final) set of principles the article espouses:

Principle #1 ─ The teams that code the system design the system.

Principle #2 ─ Build the simplest architecture that can possibly work.

Principle #3 ─ When in doubt, code it out.

Principle #4 ─ They build it, they test it.

Principle #5 ─ The bigger the system, the longer the runway.

Principle #6 ─ System architecture is a role collaboration.

Principle #7 ─ There is no monopoly on innovation.

The New New Product Development Game and the Roots of Scrum

I was recently doing some research on prospective agile governance models for a company in the throes of understanding how to manage the entropy of a large number of newly energized and empowered agile teams. For perspective on the problem, I returned to the following article for guidance: The New New Product Development Game. This article was published in the Harvard Business Review in 1986 and provides a perspective on the “Toyota Way” of concurrent engineering in the automotive business.

I read this article back in the late 1980s and considered it incredibly relevant to the product development work I was doing then. More recently, I was reminded of this article from a talk Jeff Sutherland gave in 2006 or so entitled the “Roots of Scrum” and it provided some excellent background for Scaling Software Agility.

I am always amazed by the seminal, agile principles that are surfaced so well in this article. I consider this to be essential reading for anyone trying to better understand the core philosophies and principles behind Scrum (and agile). Here’s a teaser:

“This new emphasis on speed and flexibility calls for a different approach for managing new product development. The traditional sequential or “relay race” approach to product development – (editors note: i.e. “waterfall” ) … – may conflict with the goals of maximum speed and flexibility. Instead, a holistic or “rugby” approach – where a team tries to go the distance as a unit, passing the ball back and forth – may better serve today’s competitive requirements.”

And since they were building automobiles with this approach, it “scales” too! I bet you’ll agree if you take the time to read it.

Update on British Telecom Agile Adoption

I met Roger Leaton (British Telecom employee and Agile Advocate) and Geoff Watts (consultant, InspectandAdapt.com) at an in-house agile community gathering last week. They gave a peer presentation of the status of the agile rollout that they have been involved with at British Telecom. (A similar presentation was provided last year at Agile 2007). Roger noted that there were about 8,000 IT employees at BT and he estimated that as many as 25-30% of these had received Scrum training and were now operating in a substantially agile manner. That correlates to approximately 2,000-2,500 new agilists at BT worldwide. This is the largest rollout that I am personally aware of. (If anyone knows of even larger rollout, please shoot me an email.)

While, our paths had never crossed before, I was struck by the similarities of their experiences and my own. Clearly, there are some common patterns in Scrum and agile adoption in the really large scale, and I’ll comment on those on future posts. For now, however, with BTs permission I’ve posted their slides here (Scrum at BT) as a work-in-progress form of case study. Heads up though, it’s a 7MB download.

Roger notes that they have been collecting some hard metrics on the rollout, (hopefully to include productivity and quality measures) and we could hope to hear more from them soon.