Play Now Medium Resolution

Play Now High Resolution

Today, a special announcement: I would like to introduce you to the Patterns Video Podcast.  Ben Woznicki and I have been working on this project for nearly six months and it is finally time to stop starting and start shipping (that’s an agile joke). 

Our idea is to share patterns (hence the name) for how teams and organizations can release sooner with higher confidence. Both Ben and I have helped a lot of different organizations. We’ve seen things that work well, seen things that work poorly, seen some things that do both, and unfortunately some things that would make your hair stand up. The effective patterns are what we are here to share as well as provide space for you to interact and learn. All of the videos will be on the shorter side. (more…)


Four Centers of Excellence

I used the term DevOps Center of Excellence to describe a COE that delivers a service to the organization in the essay, Types of Center of Excellence.  This type of COE is a consolidation of the personnel to deliver a service into a group that can be drawn on by other parts of the organization.  Another name or description of this type of COE is a Center of Functional Excellence (COfE). After reading the essay Pete Franklin (@PeteFranklin) tweeted:

Eight Avoidable Reasons Why COEs Fail… via @TCagley – I’ve almost never seen a functioning CofE

When asked his opinion on why that was his experience he responded:

My theory is that the whole model is based on some fundamentally incorrect assumptions. In particular, that skills that exist in one place can be deployed into another team with no losses or issues. The old ‘fungible resource’ fallacy 🙂

I have seen functional COEs work and work well, however, I tend to agree that the seeds to make this type problematic are often present. (more…)

Coaching is a tool to help individuals or teams improve performance. Effective coaching requires trust but – not all trust is the same. Christophe Hubert (@christopheXpert) responded to our essay, Trust, the Backbone of Coaching by tweeting:

“Could we define a trust level on a scale?”

The answer is obvious, we do not trust everyone to the same level. I trust the person that delivers mail to my house differently than my wife or family. The knowledge that trust is variable is important to help coaches tailor their approach. (more…)

Shanghai Skyline

Change is in the skyline!

Modernism, which dated from the 1800’s to the early 20th century, was replaced by postmodernism. Art Deco was replaced by less extravagant architecture. All movements come to an end and are at some point replaced by something else. The mainstay of software development, waterfall development, introduced in the late 50’s and then documented in 1970, was supplanted by Agile. Now, organizations are adopting Agile at a slower rate and with more adaptations that fall outside the intent of the principles in the Agile Manifesto. We have reached or are reaching the end of Agile as a movement. Stating that we are approaching Agile’s end has elicited a number of responses. For example, I had the following exchange on Facebook

Michael Miller So Agile, in the end, is just another fad?

Thomas Cagley Jr Not exactly. The point is more that for a variety of reasons Agile as a movement is over even though some are still in the adoption mode. At some point, another movement will catch fire and build from the base that Agile and DevOps have wrought.

Agile as a set of frameworks and techniques is not at risk of going away, but the principle drive of the movement as described in the Agile Manifesto is being weighted down and by four things:

  • Method Lemmings – Just doing Agile, and therefore often doing Agile inappropriately.
  • Proscriptive Norms – Defining boundaries around methods that reduce flexibility.
  • Brand-Driven Ecosystems – Splintering of schools of thought driven by economic competition.
  • A Lack of Systems Thinking/Management – A resurgence of managing people and steps rather than taking a systems view.

The question then becomes what is next, because there will always be something next. Which is exactly what Woody Zuill asked on Twitter.

Woody Zuill @TCagley Do you have a definition of “post-agile” that you can share?

I am not the first person to use the term “post-agile”. Woody uses the term to mean “We accept all the good things that Agile brings, and are ready to explore and innovate beyond”.  I am far less sanguine. The four drivers suggest that we have reached high tide. But when a wave breaks, while some water rolls back to the sea, some sinks into the beach to feed the animals and water the plants.  The Agile movement has helped many teams and organizations to take steps toward unlocking the power of teams.  Tools and techniques such as collaboration, kaizen events, retrospectives and frequent planning are part of our basic vocabulary.  These tools provide the basis for what is to come.  Which to some extent makes Woody’s definition correct.  The definition I use for the post-agile age is the age of improvement punctuated with innovation. The age of improvement will not be limited to process, technology, or even people improvement individually, but an age where organizations change how they work based on a process of learning and adapting.   When Mike Miller stated:

Michael Miller It sounds like after 50 years we don’t really know how to do SW development — we keep coming up with new methodologies.

He is correct. Of course, we don’t really know how to do software development, After 50 years of software development it is time to try new things combining everything we have learned before with what we will learn tomorrow.  The post-agile age is an age of improvement, even if we are all starting at a different point with different constraints and capabilities.  

Essays in Post Agile Age Arc include:

  1. Post Agile Age: The Movement Is Dead
  2. Post Agile Age: Drivers of the End of the Agile Movement and Method Lemmings
  3. Proscriptive Norms
  4. Brand Driven Ecosystems
  5. A Lack of Systems Thinking/Management
  6. The Age of Aquarius (Something Better is Beginning) – Current


Vanity metrics are not merely just inconvenience; they can be harmful to teams and organizations. Vanity metrics can elicit three major categories of poor behavior.

  1. Distraction. You get what you measure. Vanity metrics can lead teams or organizations into putting time and effort into practices or work products that don’t improve the delivery of value.
  2. Trick teams or organizations into believing they have answers when they don’t. A close cousin to distraction is the belief that the numbers are providing an insight into how to improve value delivery when what is being measured isn’t connected to the flow of value.  For example, the organization that measures the raw number of stories delivered across the department should not draw many inferences in the velocity of stories delivered on a month-to-month basis.
  3. Make teams or organizations feel good without providing guidance. Another kissing cousin to distraction are metrics that don’t provide guidance.  Metrics that don’t provide guidance steal time from work that can provide real value becasue they require time to collect, analyze and discuss. On Twitter, Gregor Wikstrand recently pointed out:

@TCagley actually, injuries and sick days are very good inverse indicators of general management ability

While I agree with Greger’s statement, his assessment is premised on someone using the metric to affect how work is done.  All too often, metrics such as injuries and sick days are used to communicate with the outside world rather than to provide guidance on how work is delivered.

Vanity metrics can distract teams and organizations by sapping time and energy from delivering value. Teams and organizations should invest their energy in collecting metrics that help them make decisions. A simple test for every measure or metric is to ask: Based on the number or trend, do you know what you need to do? If the answer is ‘no’, you have the wrong metric.