A few weeks ago I tried to answer the question from a person who asked me about the success of an agile transformation, how to conceive it, how to judge it? Since then, accompanied by Stéphane and Aurélie who carry the Atlassian offer at Smartview for a presentation on the mutation of a company in its path towards agile (and its related tooling, that’s Stéphane and Aurélie’s part), I’ve dug into the insightful proposition of Diana Larsen and James Shore: Agile Fluency (brought back to my attention by Claude during an agile raid).

Agile Fluency seems to me a very good way to think about one’s path through agility. Agility which is never in itself the goal of an organization, but let’s say the best way to move forward in the current era (see Modernité, Agilité, Engagé).

What does Agile Fluency tell us

Focusing on value

A first step is to understand that you must produce value and not work (or code). Value is finished things, so we reorganize teams so they work together in a heterogeneous way, and in a way that produces everything necessary to have something finished: usable, that can be put into production to generate value (learn with feedback).

Generally in a company we try this in a protected way in a “demonstrator”, one, two or three dedicated teams to try this new operating mode. But already this raises many questions like what is a finished thing, it requires rethinking the composition and work rhythm of said teams.

Reading the progress of value creation is drastically facilitated (if we’re sure to do “done”, “finished”: the only way to be definitively sure: put into production). Either we have something or we don’t have it. We forget the opaque: we’re doing X% of this feature or of the work to do. We no longer measure time (I’m going a bit far there)! We no longer measure the work done! We measure the value created (for that: the pirate metrics AARRR (their cry) for example, or better the cash generated, etc.).

Delivering value

The next step is to learn to deliver value when it has value. It’s a step that requires real technical expertise: we’ve acquired enough know-how (Test Driven Development, Pair Programming, automated tests, continuous integration platforms) so that the question of delivery is solely a business question. All the technology cogs allow at any moment to switch elements. We can associate it with the devops movement.

For IT, infrastructure, CIOs, developers, it’s the period of sweat. This learning is not negligible. And this infrastructure has a real cost – having quasi-prod platforms whose data sets are constantly exploited – but if you compare this cost to what your usual infrastructures cost you, very static, fossil, in technical and business efficiency, you quickly understand that you’ll quickly gain from it.

If the demonstrator has been a success we think about deploying more in the organization. So it’s also often the moment when Kanban deploys in the organization: either to integrate maintenance, or to synchronize the different teams, departments, etc. It’s the painful moment when we realize that a classic approach is not at all compatible with an agile approach: as much in culture, as in the operating mode in its rhythm.

To those who imagine having a two-headed organization: agile and non- agile, I say that you can tolerate it for a time, the time of transformation, but that it’s illusory as a target. This doesn’t at all mean that all agile in the structure is the same, absolutely not. It will take a different form depending on contexts, but it will be driven by the same culture, the same value focus.

Optimizing value

Once we know how to generate value, and deliver it when it has value, we will optimize in some way the value density, or optimize the effort/value compromise. We will maximize value, minimize effort. We try to learn as early as possible from the delivered value to readjust if needed the following movements. We can associate it with the Lean Startup movement.

It’s the moment when projects and maintenance also give way to a vision, business and teams approach. We no longer think project, we’ve taken a step back on the overall coherence, and placed value in a larger whole, connected to the business vision of the organization.

Today many structures are eager for innovation laboratories of the Lean Startup or Design Thinking type (new names for agile, which is becoming hard to carry). In my eyes it’s first the expression of a failure: not having succeeded in deploying this culture at the global level: innovation, agile culture is the subject of the entire organization, surely not of a single piece, especially if that piece is limited to a laboratory that doesn’t manage end to end the life cycle of a product. We tried Agile, we failed, for certain reasons, we fall back into “demonstrator” mode: we sanctuarize a space where we have the right to think differently (agile paradigm shift). Let’s hope these new seeds take better.

Optimizing the system

The organization rethinks itself around this value creation: no more maintenance or projects but business axes, of value, that we address. New ways of thinking about products, relationships between people, etc… If Diana Larsen and James Shore indicate a fourth level, for me it’s rather a constant maturation: the new company slowly emerges. Questions of hierarchy, XXXcracy, organization chart, HR arise as we go (and often require a double reading during transformation).

Emotion

Finally this transformation in my opinion, cannot be thought of without being accompanied by its dose of emotion, true energy, force of personal and company transformation (Émotion, énergie et conduite du changement). Emotion is the indispensable energy of change, without emotion all effort in this domain remains dry and useless analysis.

Warning because transformation never stops. But that’s also all the pleasure.

Very dear Fabrice, would you translate the complete text on Agile Fluency? (But perhaps you’ve already done it?).

Slides

If you’re interested in the slides with Stéphane and Aurélie (Atlassian at SmartView), here they are: