Please find the attached slides and notes for the presentation:
Jurgen Appelo’s article “Agile Scaling Anarchists, Dictators and Networkers” resonated with me as I’ve been thinking a lot about the scaling issue of Next Generation IT. I think Jurgen correctly points that the extremes of Scaling Anarchists and Dictators are likely not the solution.
For the Scaling Anarchist approach to work, we need an incredibly efficient “invisible hand,” borrowing from economic theory, to provide the greatest economic value from the self-interested actions of individuals with no intentions of promoting the greater good. Conversely, Scaling Dictatorship is closely akin to Traditional IT’s false assertion that centralized planning and specialization are the best method for maximizing value; where just doing it in the name of Agile and not Waterfall. However, I don’t see Scaled Agile Framework (SAFe) and Holacracy as both being at the extremes of the Scaling dictatorship. If anything, Holacracy in my opinion would fall into the realm (but not quite the extreme) of Scaling Anarchists. Between the two exist many more options such as Disciplined Agile Delivery, Large Scale Scrum and others. SAFe is the most heavyweight of the Scaled Agile frameworks and Large Scale Scrum (LeSS) arguably the least.
I think we can leverage economic practice to see that different situations warrant different approaches, with varying and emergent success. Centrally planned economies of Russia/Soviet Union, China, Cuba, etc. are poorly suited for a revolutionary change to a completely liaise-faire economy. China’s done quite well, at least in the shorter term, with their Socialist Market economy; small steps, adapt and adopt.
In correlation, IT organizations that are just evolving from Traditional IT delivery with little to no Agile culture or practices would not adapt well to the lightweight LeSS or Holacratic Revolution. I can’t imagine traditional IT leadership having the appetite for the risk with this magnitude of change. A mature Agile organization might choose a lighter weight approach though because the magnitude of change makes the risk more manageable and recoverable. After all, the founding principles of Next Generation IT like Agile and DevOps, is evolution through small iterative changes and emergent learning.
I believe the same holds true for IT cultural transformation. In fact, when approached on the question of which “scaled agile framework” for my organization this was my exact thought process. I suggested SAFe as we are just starting to adapt Agile and DevOps principles. We are not ready for LeSS or Holacracy; we need to pivot from Traditional IT first, then and adapt and adopt along the way. SAFe provides a more familiar pathway so that the behaviors, thinking and culture can actually wrap their heads around a more laissez-faire approach. Our Next Gen journey is dismantling the Traditional IT anti-patterns organizationally and culturally first to increase our immediately agility with acceptable risk, then seek the next evolution of thought and practice that results in the greatest value.
Jurgen hits it on the head with his earlier article “No. Agile Does Not Scale.” A given “Agile framework” does not scale universally; there are no silver bullets. Dogmatic Agile holy wars will only be as successful Religious holy wars; no thank you. Agility does scale though, and in my mind Next Gen IT will massively increase the amount of technology enabled value to society through the independent, self-interested actions of individuals. Perhaps the “invisible hand” is working better than we thought.
Thanks for stopping by my blog! My passion is around transforming how IT is delivered across the Enterprise with next generation delivery methodologies and principles. After 20 years in the IT space in a variety of industries and solutions areas, I recognized that IT was in desperate need for change as existing methodologies that are haphazard at best (despite best laid plans) and demoralizing and dehumanizing to the point of killing us with stress related illnesses and Karōjisatsu at worse.
My journey started in the Manufacturing world as a Total Quality Management / Lean Six Sigma proponent and developing IT solutions to satisfy ISO 9000 requirements and eventually led me into full IT solution development and delivery. Cumulatively over my career, I’ve been a “full stack” IT person who has performed development, operations, project, and program duties over the course of my career. Almost 20 years into my career, I started to come full circle back to start of my career with application of Lean Six Sigma (LSS) principles to IT delivery. https://www.linkedin.com/in/johnwspangler
In 2011, I had a client looking to apply LSS to their ITIL implementation. As a veteran ITIL practitioner, I realized the likely chance of highly bureaucratic, ineffectual processes created in the name of ITIL; much as there was for ISO 9000 compliance back at the start of my career. While still a strong proponent of ITIL as a useful framework and vocabulary for large enterprises, I see Lean concepts as critical to leveraging ITIL effectively. Because of ITIL’s widespread adoption, I believe it’s an important component to address, leverage and move monolithic enterprises and IT organizations to faster, more effective delivery and management methodologies such as Continuous Delivery and DevOps.
Unfortunately in 2011, my personal body of knowledge and the industries in terms of Lean and IT were still very much in it’s infant stages. I did have my hands on Lean IT by Bell and Orzen (please see my Book Review section for this and other great sources) and this time prompted me to go back to get my Lean Six Sigma Black Belt and leave Program/Project delivery so that I could focus on fixing the system and not continue to be a puppet of it (it would take me a few more years though to really achieve that role).
For my Black Belt project, I used Value Stream Analysis on IT Project Portfolio Management at that 2011 engagement to demonstrate over $750,000 of just pure labor cost on IT project requirements that were highly unlikely to ever see the light of day because the organization did not have the capacity to deliver a significant portion of their portfolio in the next few years. This same problem plagues every IT organization I’ve worked with over the last 10 years, including my current employer. The relationship of WIP, Cycle Time, and Lead Time are still very foreign to IT leadership and one of the central struggles of transforming IT delivery.
Skip ahead to 2013 when I learned about the concept of DevOps and read Gene Kim’s The Phoenix Project which clearly shined upon the path that Lean Six Sigma could play in IT delivery. It’s been a roller coaster ride of adrenaline and information ever since. There has never been a greater time and opportunity to harness technology and the talent of millions of technologists in a much more effective and humane way.
This blog is about my past, present, and future journeys to transform IT delivery not just for a small segment of IT, but for the entire IT enterprise. I choose the title of “Unifying IT” because I see organizations experimenting with DevOps and Continuous Delivery with promising results, but a vast expanse of legacy IT technology, methodology, knowledge, and culture that will need to be addressed. Gartner has coined the term of “Bi-Modal IT” which I think is a valid “As-Is” model of today’s typical forward-thinking IT organization, but it is not the “To-Be” model we should be striving for in the long run. Just as Lean manufactures didn’t snap their fingers and achieve the marvels of efficiency and automation of modern day manufacturing; Unified IT will be an evolution as well and we should not tolerate an IT culture of Bi-modal first and second class citizens. As W. Edwards Deming, one of my personal heroes, stated “Put everybody in the company to work to accomplish the transformation. The transformation is everybody’s job.”
Breaking from the traditions and familiarity of the past is not a trivial matter. IT Senior Leadership largely achieved their career success despite inefficient legacy ways of delivering IT solutions. The next generation of IT delivery requires a fundamentally different mindset and often contrarian way of thinking. Traditional IT delivery can still considered successful even though it’s often accomplished by brute force, political marketing of achievements, and strategic burying of failures under the carpet.
If your legacy driven IT organization is generally considered “successful” your challenge is just that much harder to transform. Perceived success is just one more, incredibly powerful, source of inertia you’ll need to overcome. You can wait though, at your own peril, till other technology organization disrupt your organization’s concept of IT success. Fortunately, I do see broad awareness and gaining acceptance by even conservative organizations to experiment with next generation concepts like Continuous Integration/Delivery, DevOps, Microservices, Agile, and Lean.
The journey is long and it’s unique to each organization, but there is no reason to do it alone. My goal of this blog is to share my thoughts and point our community to leading thinkers and thoughts in next generation IT delivery so we can transform IT as a domain, reap the amazing benefits that technology can deliver the world, minimize the dangers of increasingly technology dependence, serve our customer better, and allow all technologists to retake pride and joy back in their work.
John W Spangler