I recently noticed a former colleague gain a Disciplined Agile certification. In my congratulatory message I also indicated my interest in learning more. In addition to that conversation, he also pointed me towards a series of meetups and LinkedIn articles led by Ivar Jacobson around “Essence for Agility”. I won’t go into all the aspects of that, but I do want to share some of the thinking that it inspired me to do about how I’ve been been working and why that has been a solution to the Achilles’ Heel of Agile Adoption.
The upcoming meetup is meant to drive forward the conversation started with this LinkedIn post by Ivar Jacobson: Some of the Craziest Things in Working with Methods and Frameworks, which was followed up with a second installment and the creation of a LinkedIn group to continue the discussion too. Basically, as I worked through these posts, and reviewed the Introduction to Disciplined Agile, I really started to reflect on the work I’ve been doing as a consultant these last 7 years, why I basically “unplugged” from the Agile movement in that time, and how I think the way we’ve been working these last 7 years is solving the Achilles’ Heel of Agile Adoption.
Basically, to jump right to it, I think that our cooperative approach to building solutions is key to making the leap from knowledge to wisdom, if you will. The “Achilles’ Heel” that Ivar identified for Agile adoption is really true of all kinds of change. So, generalizing, I think that while knowledge, training, coaching, and other external “activators” (such as strategy consultants or technology implementers) may be necessary, they are not sufficient to achieve the kind of significant change companies are looking for as they “reinvent” themselves through “transformations”. Further, it is through a cooperative partnership approach, where we’ve integrated with our clients to form cross-company and cross-functional teams; working on everything from strategy to execution, from experimentation to operationalization; that I think we’ve shown we can avoid this “Achilles’ Heel” and facilitate, accelerate, and realize successful change.
Now, coming back to Agile, and a little bit of the journey that led me to step back and see the way we’ve been working with our clients in a new light.
As I read through the comments in Ivar’s “second installment” (The “Craziest Things”​ with Methods and Frameworks …feedback and comments), where he highlighted some of the good comments the first article had inspired, this comment resonated with me:
I did search in this article, how many times customer was mentioned? Zero. IMHO the craziest is that we focus too much on methods and frameworks. I believe in what was written in the agile manifesto: “Individuals and interactions over processes and tools”. In order to “beat these abnormalities of our discipline” I help others to see “value in the items on the right, but value the items on the left more”.
Vladimirs Ivanovs in response to Some of the Craziest Things in Working with Methods and Frameworks
At the same time, Ivar’s response (follows) seemed to miss addressing some of what I thought Vladimirs was driving at, namely that we’re not thinking enough about the actual customer, the person, or organization, that is spending money for an offering and expecting to derive or realize some value from it. On the other hand, rereading what Vladimirs wrote and Ivar’s response, I’m not sure that it wasn’t me who was working at a different level of meaning …
Every method or framework must have great practices to deal with customers. And all the successful frameworks pay significant attention to customers. Otherwise, they wouldn’t be successful. They most likely do it in different ways, and that is fine. However, the way they do it, is not easily reusable by anyone else. It is hard to learn from others. The practices are in method prisons.
Ivar Jacobson responding to Vladimirs Ivanovs in The “Craziest Things”​ with Methods and Frameworks …feedback and comments
My “different level of meaning”? Well, for the past year and half I’ve been working to drive an enterprise transformation using customer experience centricity. And when I speak about the customer, I’m not talking about our client as consultants, but about their customers (and also their partners and the customers served through them). So when I think of the “customer” I’m thinking of my client’s customer. But when Vladimirs and Ivar were speaking about “customers”, they were probably thinking of their customer as consultants. And that is pretty much baked-in to the Agile way of thinking:
We are uncovering better ways of developing software by doing it and helping others do it.
Manifesto for Agile Software Development (emphasis in the original)
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Regardless, powered by my recent experience, by Steve Denning‘s great book, The Age of Agile (which you’ll see mentioned below), and by my study of Effectual Entrepreneurship through the Hunter Hastings‘ Economics for Business initiative with the Mises Institute, I joined the LinkedIn group Ivar started to continue this discussion and did just that:
I do see a repeating pattern of focusing on the methods, inventing/designating customer proxies, and never really making the “Copernican shift”, as Stephen Denning puts it, from a firm-centric mindset to a customer-centered mindset. Indeed, my experience has been that the number one indicator of whether a company is “traditional” or “transformed” is this mindset.
Me on LinkedIn (with some edits for this post, including info from some of my responses to comments)
For almost 20 years what Scott Ambler used to say when speaking in the Agile community in Toronto has stuck with me: “Show me your customer, show me your tests, and I’ll show you how agile you are.” (Or something close to that.) I think a lot of work has been done of the “tests” part of that statement: for example, I’d argue that the DevOps movement has expanded and concretized what is meant by that part of the statement. I think too, a lot has been done on the “customer” side, perhaps more led by the product community, the Lean Startup movement, and the operating model of companies like Amazon.
Regardless, these are the two key elements I look to assess and implement improvements to in the work we do. Which practices to apply and how to apply them differs across teams and time, but when I think of the Golden Circle (WHY-HOW-WHAT, “start with the why”) from Simon Sinek, I see a nice mapping:
– WHY: unique to each org, its purpose/mission, defined by its leaders
– HOW: simplified to “the tests” by Scott, but I think it could be said that the “how” is with Tempo and Stability (which are roll-ups of the DORA metrics: Tempo includes Lead Time and Deployment Frequency; Stability includes Time to Restore and Change Failure Rate), and this is enabled by adopting, implementing, and continuous improvement in Agile practices
– WHAT: “the customer” and their ability to have its needs met or to realize its goals with the specific product or service of the company
Could this way of thinking help “break the cycle” of methods and frameworks hype? Could using tangible starting points of WHAT is being created, defined from the customer’s perspective, and HOW it’s being done, with the practices being considered in light of their impact in enabling the team(s) to increase Tempo and Stability, create the common ground?
Could we solve the craziness around methods and frameworks by choosing and evaluating practices based on:
1. Their ability to help increase Tempo and Stability
2. Their ability to help provide and/or exploit greater line of sight to customer needs and goals
As for how to meet clients where they are, I’m reflecting on how I’ve been working for the past 7 years as a consultant: we’ve adopted/evolved to a model where we pair with our clients on both the implementation of the software and of the new ways of working. Meaning that the teams are hybrid between our clients and ourselves, them bringing domain and current system knowledge and our teams bringing knowledge or new technologies and ways of working.
Well, for me, after I thought more about it and tested it in a few conversations, I do think we’re doing something that makes it faster and easier for our clients to realize their need outcomes. I think too that there is something to the idea that Agile practices can be evaluated in a given context for their ability to increase Tempo and Stability and their ability to help the firm be more customer experience centered. But there’s a lot more discussion to be had and I look forward to it happening in The Craziest Things in Working with Methods and Frameworks LinkedIn group, the series of Essence for Agility meetups – especially the July 28 one: Crazy Challenges Working with Methods and Frameworks, and through my own personal conversations. It is for that last purpose, if for no other, that pulling all this thinking together and writing it down will be most helpful, as I’ll be better able to articulate what I (think I) see to colleagues and friends.
7 Comments