Framework Fatigue & No Transformation Initiatives
On April 27th, 2005, I first blogged about the topic of transformation fatigue and the cost and common failure of framework adoption. The original blog post is available in my book Lessons in Agile Management.
In October of the previous year, 2004, I was just 1 month into my new job, leading the process development efforts for Microsoft Solution Framework (MSF) – yes, there it is, ¨framework¨ – in Microsoft’s Visual Studio Team System business unit. The Team System product was still about 18 months from release and there were plans to bundle two process framework templates, one that was intended for small scale and reflected the trends in Agile methods such as Scrum at the time, and the other that was codenamed ¨formal¨ and was aimed at larger scale for organizations in regulated environments and was being developed in partnership with the Software Engineering Institute at Carnegie Mellon University and would be based on their Capability Maturity Model Integration (CMMI). Just one month into the job I was still getting oriented to the product plans and the system architecture that had been built already, yet, I´d already given my immediate boss the feedback that the product did not work the way that a software development manager would lead change and process improvement. I explained that you don´t simply install a process template or framework overnight, flick a switch, and everyone in the organization changes their behavior. No, much more likely, practice adoption was incremental, and the sequence of adoption, focused on specific problem areas for any one team, department, group, or organizational unit would differ from one group to another. The product needed an architecture that allowed incremental process change, not an install a template, based on a framework, then simply follow it. He replied that it was already too late, that rearchitecting the core functionality would delay the product and set back the intended release schedule. Hence, he said, my suggestions would need to wait for version 2, perhaps 3 years later. It was, in fact, 12 years, before Team System/AzureDevOps supported evolutionary, incremental process changes. A great opportunity had been missed.
So in October 2004, just one month into my new job, I was asked to facilitate a session at the Customer Advisory Council (CAC) meeting. The CAC comprised 20-30 senior advisors from big corporate clients of Microsoft´s developer tools. I started by presenting an outline of our proposed product. How it was engineered and architected certainly wasn´t my choice, yet, I intended to use all of my expertise with the process guidance and templates to enable it to be used more incrementally. That we were to base the framework on CMMI meant that it had to accommodate maturity and capability levels, and hence, by definition, it would be incremental, even if the underlying product architecture didn´t support it elegantly.
One seasoned member of the CAC, who had been involved for some years already, worked for EDS based in Plano, Texas. EDS was later acquired by HP then merged with CSC and now trades as DXC Technology. At the time, EDS was one of the largest IT consulting organizations in North America. This gentleman´s input was simple ¨don´t give us yet another quality initiative. We´ve tried them all and people are tired.¨ EDS and their clients had framework fatigue. They were tired of all the latest management fads and process improvement frameworks. This may have included the CMM/CMMI though he did not explicitly state it.
This contributor from EDS wanted Microsoft to take a leadership role and position to promote a more humane, incremental approach to improvement that was far more likely to stick. He was talking to the right person.
In 2002, while writing my first book, Agile Management for Software Engineering, I concluded that I was writing the wrong book, advocating for ideas that were doomed to fail at scale. The Agile Management book sought to promote the adoption of Agile methods and promote them to managers of all levels as a means to improve the economic outcomes from large-scale technology research and development activities. While I was writing in my spare time, I was leading a product development organization inside Motorola´s PCS division, and watching attempts to scale Agile adoption across that organization struggle. It wasn´t the first time. I´d seen it all before two years earlier at Sprint PCS. When attempting to scale a process framework or methodology, something with a prescribed set of roles, responsibilities, practices, metrics, and collaborative meetings, ceremonies, or events, quite simply, the adoption at scale failed or at best was lacklustre and failed to produce the outcomes and benefits expected. It failed not because the method or framework was bad or inappropriate, although the appropriateness of a framework choice is always a concern. Rather, the failure was intrinsic to the human condition. Scaled adoption failed because the human beings involved resisted the changes. When attempting to scale to scores or hundreds of people, there were enough humans involved that a few, maybe some, maybe many, of them would resist. Consequently, adoption was lackluster and the results disappointed. I had concluded that any framework was doomed to fail at scale!
So I had great empathy with this soul brother from EDS. I understood his frustration and pain but I was constrained by the architecture of the Team Foundation Server product. Microsoft Solution Framework (MSF) was indeed going to be presented as a ¨click to install¨ template inside the product.
It was two years later, when this job was complete, that I got the opportunity to move across town and work for Bill Gates as Senior Director of Software Engineering at Corbis that I would finally get the chance to pursue an incremental, evolutionary, start with what we do now, approach to change and improvement. Exiting Microsoft, I gave an interview with the Developer Network´s Channel 9 where I explained this new approach and that moving to Corbis would give me the freedom to pursue this experiment. For some of my new team at Corbis, given my background and reputation, it came as a surprise that I had no intention of installing an Agile method. Instead, what emerged there would become known as the Kanban Method – an entirely evolutionary approach to improving organizations.
No Transformation Initiatives
The ¨click to install¨ framework approach is doomed to fail at any scale with some exceptions – large-scale framework adoption appears to have been modestly successful in mature organizations, with strong leadership, and deep change management capability. Humans resist change that affects them socially or psychologically. Whenever you introduce change that affects an individual´s identity, or how they relate to others in an organizational structure, their role, and responsibilities, then they will perceive a significant risk to their status, recognition, respect, or dignity, and they will resist the changes.
The Kanban Method was specifically designed to avoid this. Kanban is the ¨start with what you do now¨ approach to change. You proceed with incremental improvement in an evolutionary fashion. You make improvements incrementally that take you towards a better fit for customer expectations. There are no transformation initiatives with Kanban instead improvement becomes a cultural thing with leadership at all levels. Improvements happen practice-by-practice incrementally and at a pace that everyone can come along
How to Succeed at Scale
I had concluded by 2004, that if change and improvement were everyone´s business, and that evolutionary, incremental change required leadership at all levels, then the focus had to be on improving organizational maturity. I’ve refined that model in the 20 years since then. To succeed at scale, it is important to improve organizational maturity, and to do that requires a focus on culture and the development of mature leaders across the organization.
By 2009, I concluded that, to succeed at scale, to create large-scale enterprise agility, then the Kanban Method with its feedback mechanisms such as operations review, strategy review, and risk review, was sufficient. Kanban delivered large-scale agility when implemented in a mature organization, with strong leadership, focused on enabling the right culture. I am now completely convinced that agility at the enterprise scale can be achieved by a combination of doing all of the Kanban basics locally on each service delivery workflow, implementing the feedback mechanisms as described in the method together with a focus onorganizational and leadership maturity to enable it all to happen.
To succeed at scale:
Do the Kanban basics well
- Focus on quality
- Limit work-in-progress
- Manage flow, eliminate blockers and sources of delay
- Engage everyone through visualization
Improve Organizational Maturity
- Pursue maturity level 3 for every service delivery workflow
- Pursue maturity level 4 for the wider organization
Develop the leaders
- Enable leadership at all levels
- Develop individual leaders to at least maturity levels 3 and 4
Implement institutional feedback mechanisms
- Enable evolutionary DNA in the organization with appropriate feedback loops
- Think in systems: implement the right metrics in those feedback loops
- Drive change obliquely using metrics, measures, and feedback rather than directly by command and edict
Framework Fatigue Revisited
It is 20 years since I last heard the complaint about framework fatigue – a call for a different, more humane, incremental, cultural approach to improvement. Recently, my LinkedIn feed has been full of Agilists making the same complaint and advocating for a similar solution – incremental practice adoption. It is ironic then that for at least 15 of those years, the industry pursued Agile transformation initiatives intended to install large-scale frameworks. Compared to the 15 years that proceeded, 2004, these were a different flavor of processes compared to those that preceded them in the 1990s but the resistance to change and the failure to scale were the same. And here we are 20 years later, an industry burned out from Agile Framework fatigue.
Looking back, it seems that there is a window of opportunity to build momentum for cultural, leadership-led change that starts where you are and proceeds incrementally in an evolutionary fashion. There is a window of opportunity to change the culture of an organization, to develop its maturity, and to make evolutionary change not just work but become the way that the organization operates.
To miss this window is to give the people enough time to recover from fatigue and exhaustion, and to once again start believing in a magic bullet, for wishful thinking to return, ¨ah it will be better this time around, things will be different¨, and once again to start the pursuit of ¨click to install¨ process frameworks.
Right now, it seems that we have a once-in-a-generation opportunity to recognize burnout, fatigue, and the failure of transformation initiatives, and to bravely embrace a cultural, leadership-driven approach. Each of us only gets two or three shots at this during our professional, working lives and careers. Let´s not mess it up. Join us on the journey. Resolve to abandon transformation initiatives, instead substitute leadership. Join us on this journey together.
Discover Our Leadership Training
Interested in learning more? Take a look at our Kanban Leadership Professional courses to find out how you develop a cultural, leadership-driven approach.
