Agile Camp Northwest 2017 was held in early September at the Nike World Headquarters in Beaverton, OR. There were a couple talks that really got me scribbling. These are some takeaways from the talk Scaled Agile and DevOps: Give Your DevOps Initiatives More Context by Leveraging Agile At Scale by Kathryn Kuhn (Slides)

Highlights from the Talk

The talk focused on how Agile and DevOps transformations really need to happen together. Both agile and DevOps are grounded in many of the same Lean principles: small batch size, limit WIP, continuous improvement, and both have a strong emphasis on the need to connect strategy and business value. Here are the top four concepts that really stuck with me after the talk.

The Goal: Business Agility

The “Goal” of agile and DevOps transformations could be defined as Business Agility: an enterprises ability to sense and respond to change quickly and confidently as a matter of everyday business. Contrast this to a ‘squirrel’ mentality where one is constantly chasing and changing direction. Another way to think about it is that business agility through agile and DevOps transformations enable ‘calculated’ change over ‘spurious and disruptive’ change.

An interesting metric for measuring business agility that I gleaned from the talk is to measure the ‘wake’ when change is made. How much disruption, confusion, loss of productivity, and angst is caused by changing direction? It is one thing to celebrate a new feature, rearchitecture or process improvement made in record time, but what was the cost of focusing everyone’s attention on it? Did other priorities fall off? Did morale take a hit? Did technical debt accumulate? Being able to rapidly shift and not cause large wakes is a sign of a mature organization/team.

How can a organization improve its business agility? A couple of key points:

  1. Adaptive planning is needed for Agile and DevOps transformations over sequential, phase gate planning
  2. Focus on achieving the shortest possible lead time

Gemba Walk: The Real Place

The Gemba Walk, a part of Lean management philosophy, was shown to be an excellent first step (and ongoing habit) in understanding the problems that exist in an organization striving for business agility. Gemba comes from the Japanese term meaning “the real place”. It involves going to see the actual process, understanding the work, asking questions, and learning from the people involved in actually producing the value.

What I really appreciate about a Gemba is that there is an emphasis on questions rather than answers when identifying improvement opportunities. There is an investment in getting dirty on the ground rather than the observing from the ivory tower.

A good example of what I’d consider a “Gemba walk” came from another unrelated talk at Agile Camp. Mamie Jones, the Sr. Vice President of Product Development at Intuit gave a fantastic talk on Leading Tranfomrational Change (Slides). As a new leader coming into a dysfunctional organization she sat down with all the people involved in the value stream (100s of people) and asked a simple set of questions before starting any improvement work in the organization. This type of curiosity and desire to understand problems is a quality that I aspire to as an agile coach or scrum master.

Maturity Models

One topic in the talk that caused some healthy head scratching was the speaker’s general dissatisfaction on agile ‘maturity models’. The alternative was to focus on ‘capability models’ instead. The capability model referenced in the talk is called DORA: DevOps Research & Assessment. The DORA is only available through a consultancy at $40K for a company analysis, so it raises some flags. How is a ‘capability model’ better than ‘maturity model’, or really how they are all that different? I’m still not sure, but my takeaway is that with any metric or model, they can be abused. When looking at adopting a maturity or capability model to evaluate team or organizational health, care must be taken. The metrics shouldn’t be used to compare or reward teams as this will cause the metrics to be gamed and manipulated.

Another key takeaway that hasn’t occurred to me is to be weary of ‘reaching the ceiling’ in maturity models. For instance, if you reach the top tier in a maturity model, does that mean you are done and there is no room for improvement? I find maturity models to be a useful tool as a starting place to identify growth opportunities and for teams to aspire to greater technical and process health, though it is good to also recognize there are dangers in overemphasizing the model.

Agile and DevOps Together: Horse Shoe Diagram

The final piece inspiring piece I want to share from the talk was the speaker’s “Horse Shoe” diagram for visualizing the product lifecycle with an Agile and DevOps focused culture. There’s a few things I love about this diagram:

  1. It shows that the traditional Product Lifecycle stages are really no different than Agile/DevOps Product Lifecycle stages. The lifecycle is there to take a concept and turn it into money. The obvious difference with the Agile/DevOps Product Lifecycle is that it minimizes the cycle time through automation, autonomy, lightweight process, and strong engineering/quality practices.
  2. It shows that Agile and DevOps practices need to be developed in tandem to realize a true business agility.
  3. There is emphasis on measurable outcomes. A Goal or hypothesis should be defined up front. As the concept moves quickly through the stages of agile an DevOps lifecyle reaching a production environment there is then the opportunity to inspect and adapt.
    Horseshoe Diagram credit: Kathryn Kuhn

Conclusion

Kudos to Kathryn for delivering a great talk that has left me pondering over the last month on how to better scale agile and DevOps in unison. Also, kudos to the organizers of Agile Camp. It’s nice attending a single day conference, as it leaves space for material to be absorbed versus being overwhelmed and drained with far too much information over multiple days. I’d like to write up another post on another fantastic talk by Kevin Goldsmith, CTO at Avvo titled Creating a culture of continuous improvement in your company. Stay tuned.