More I spend time with teams, helping them adopt Agile and Lean ways of working, one trend is almost always common, people being in a hurry to get down to mechanics of “doing it”. While it is not uncommon for practitioners to demand the “How” and surely there are quite a few people who learn just by doing it, transforming into new experiential ways of working, is as much mindset driven as it is action driven.

It has got so much to do with our underlying mental models, success and failure patterns, as it is about picking up new flashy DevOps tools from the shelf and putting them into our development and release process. If we aspire to get to frequency and speeds of delivery which Google, Facebook or Amazon has already achieved, we do need those technology enablers. But people who work with these technologies are human beings who have a complex mind and patterns of behavior which can make these tools and processes very quickly ineffective. We need to deal with this complex human mind while we expose them to the new mechanics.

Having introduced the knowledge worker to the new principals and answered most “Whys” which arise with it, the next (not necessarily exactly sequential) step has been putting measurements in place to understand where the biggest systemic issues exist. These measurements then drive what possible combination of mechanics to apply. Methods and Mechanics being introduced before we know the real problems on the ground is usually a failure pattern of transformation and coaching, which undermines the value of “subjectivity & co-evolution,” one of the eight ways to understanding and working with complex adaptive systems. ( Management 3.0 – Jurgen Appelo)

With the confidence of having a common understanding of Agile & Lean – values, principles, vocabulary and firm data points with real discovery on the ground done with team members, it usually sets the stage, now, to start experimenting with solutions. This starts with introducing methods, practices, techniques, and tools. But having made the discovery together, this application should be a lot more contextual and real, then a rigid enforcement of a guide or big picture on the ground as it is popular and proven elsewhere.

Some teams full of early adopters would accept and reap the benefits immediately, and some would externalize the problem, delay and defer the change till the success is socialized and proven with other teams. Some teams could not initiate or sustain this change from within, and we had to incubate the change in methods, technology, and engineering enablers, by seeding the team with external experts and change agents. People who had in their second nature working with these methods, tools and technologies. These were full stack developers, DevOps professionals, Scrum Masters and in cases liberated and experienced delivery professionals who worked closely with the leadership.

We would start measuring the adoption of practices and techniques as leading indicators, till the real business and technology outcomes start becoming visible. But only after some teams have reliable and proven results and a success pattern, can we start to look at scaling and bringing the approach mainstream.

Scaling these team successes, across the enterprise, was a no simple task, and required working with coaches and delivery professionals who have the knowledge and skills of the method(s) but also substantial delivery execution experience to operationalise those methods as well. Among a lot of additional things, internal champions or player coaches ( see my previous post “Building The Bridge” on the topic) are critical in navigating the internal corporate politics, culture and pushing the change forward and across. Till the change itself starts influencing both, politics and the culture.

This process is never completely done, though, and across all of my recent experiences, I can not say we were done with the transformation when we completed the engagement. But when we walked out, we did have a critical mass talking the same language, asking right questions and displaying improvement in real business and technology outcomes which had started to create pull for the new ways of working from other parts of the organizations.

Mapping some of these recent successful and failed attempts at Agile transformation which were frequently coupled with a new Digital Head, running a Digital transformation, has led to this visualization of an Agile + Digital transformation model:

8forwards_Agile_ Transformation_Model from Rishi Raj Srivastav

This model is evolving as I write this, and as always we are discovering new and contextual issues which need to be addressed with each new situation we get into. But largely what I together with the organizations I work with seem to follow a similar pattern on the path to the newer world and hence wanted to share this. Would be curious to understand what is working or not working for others in the same space? As always a conversation would be great!