You cannot separate Transformation from Delivery


The digital or IT parts of the much-hyped “Digital Transformation” are not the most significant, interesting or value-creating aspects of the changes that need to take place in organizations today. There is already a lot of consumer driven momentum behind the advances in technology and not many blockers. Consumers demand it, we save money implementing it, it helps us integrate various channels cheaply, there is a healthy market of options regarding experienced technology partners to supply specific skills and services at appropriate price points, and as a nice side effect recent advances in technology provide us with huge amounts of data that helps us understand our customers with a level of insight never seen before, thus providing the potential (realized by recent advances in, and increases in the supply of skills, in data science and analytics) to meet their needs more accurately and efficiently in the future. These cool new technical ideas are readily embraced by technical staff like software developers so I see them as a quick win, or low hanging fruit.

One significant part of these new changes taking place is the adoption of agile methods among software development teams. Over the last five years especially, the use of Scrum within software development teams has become almost mainstream. Often however, especially in larger organizations, true end-to-end agility has not been achieved because the IT focus of Agile and Scrum left the other parts of the value stream feeling somewhat excluded. This focus on IT is essentially what Kahn refers to as mere Digitalization, a kind of precursor to true Digital Transformation.

Ideas intending to support scaling Agility in larger organizations, such as SAFe, LeSS and Nexus, even when successfully applied still tended to focus on a transformation of “IT”, leaving the organization itself unimproved, and often staying with older management approaches that clashed with the new culture emerging from the IT department.

Very recently concepts such as Design Thinking have helped “evolutionize” the upstream activities in the product development process somewhat, but these have seldom been well integrated into the agile software development part of the value stream, and have even reduced agility in many cases, as the typical implementation results in a waterfall-style “design thinking” phase, resulting in documentation to later be converted to user stores as input for the “agile software development” phase.

A large consulting company recently had a brief period of prestige as the main company responsible for the Digital Transformation of a large client’s innovation approach. The main mistake was in separating transformation and delivery. They sold an expensive consulting package to the client, with the intention of setting up the structure of the new organization, while other providers were supposed to fill in this structure later and deliver the actual products. But you can’t really form a new organization before the people are there to fill it and before there is anything to do. What they actually delivered was simply documentation; PowerPoint slides. A guide book if you like, explaining how everyone that comes along in the future is supposed to do things. Of course this didn’t work. The delivery organizations had their own ideas about how the work was supposed to be structured. And of course the client misunderstood the somewhat abstract and theoretical, prescribed approach. Existing teams picked and chose what to implement and how. They embraced, for example, design thinking, but on the business side in a phase based waterfall approach. They never even considered working in the same teams as software developers. They probably couldn’t have even if they wanted to. By the time Scrum Masters were involved (when the development phase started) it was too late, most products were already designed and described in documentation, wireframes and even prototypes. There was no creativity required anymore, just the conversion of an almost finished product into source code. At this point, Scrum and its roles are completely superfluous.

If only transformation and delivery were correctly recognized as being two inseparable aspects of the same thing, as always envisioned, all parts of the process would have improved together, all issues would have been resolved in a holistic manner, any misunderstandings could have been corrected immediately, and the organization would have enjoyed the full benefits of true end-to-end agility.

It works the other way too. I cannot imagine an organization properly introducing Scrum as a product development framework without experiencing profound transformation. The very nature of Scrum as a framework rather than a process demands this. The teams require the freedom to evolve their own process over time within this framework provided by Scrum. And this evolution has to be continual. The market changes, technologies change, the very power of agile and scrum lies in this enablement of teams to drive this decentralized transformation that the organization requires. In fact in most cases, it can only be at the team level that this transformation can occur quickly enough. Even, or perhaps especially, in areas not directly related to the product development itself. The role of management in particular can change from a command & control style, to a Scrum Master-style servant leadership approach focused less on maximizing employee utilization and more on coaching their teams, removing impediments, and connecting people together. The way we look at the work itself will change, being less about scheduling and dependency management, and more about ensuring information and value flows throw the organization quickly, without building up in delay-inducing queues, and market feedback can be delivered to and exploited by those who need it just as rapidly. In fact the very structure of the organization may evolve, becoming less top-down, hierarchical, and adopting more of a decentralized, outside-in, market led, network of cross-functional squads, supported by core functions located at the center.

Keep this in mind when introducing Scrum and especially the Scrum Master to your organization. Supporting delivery is only part of their role. Scrum, together with other powerful tools in the Scrum Master’s toolbox such as Kanban, can support a beneficial transformation in your organization that is not localized to the software development team.

The new Lean / Agile approach is therefore not to consider Delivery and Transformation as separate things. Lean / Agile consultants will be empowered to not only support you in the delivery of new product innovation but also provide guidance regarding adjustments that could be made in the organizational structure, culture, roles, processes and systems across the whole end-to-end value stream, and they don’t (and wouldn’t be able to anyway) go in and simply tell you to change without discovering together in the real context of delivery, exactly which optimizations bring the actual bottom line results that you expect.