How’s your Agile Foundation (underlying your transformation)?
So, I was honored to speak at an event in Columbus recently for a meetup group I’d never heard of, the Association of Technology Professionals, which I suppose isn’t surprising because they are a group of data and voice IT professionals, not my usual software crowd. But they wanted to hear about “transformations”… and they had a bunch of people who attend that aren’t typical agile software team members, so I prepared an interesting hodge-podge of content to cover Agile Foundation topics, Agile Transformation topics as well as my passion for Business Agility. It was a whirlwind of a talk, but it was well received and it got me thinking.
In order to be successful in ANY agile transformation, there must be a fairly universal understanding of agile basics forming an agile foundation that can be built upon.
So, what are those basics? Clearly it’s more than just the manifesto, 12 principles and scrum guide, which I’ve blogged about before. I’ll try to cover a brief summary of the talk and my logic, because speaking about agile to people that don’t have of lot of experience to draw from is interesting and you are likely find yourself doing that too.
Where to Start?
I think beginning with “Why Agile” makes sense. It’s a mystery to many people who don’t work in software projects every day. Agile seems like a fad to them. So I started by explaining there’s a way to tell whether agile is relevant to your problem space or not using the Stacey Diagram. If you know all of your requirements solidly without much ambiguity and you know what tools, technology and people you’ll use to solve it, then a traditional waterfall approach to walk a project plan actually makes sense. But if there’s some ambiguity around requirements and you have options and technology choices to make along the way, then agile as an approach makes a lot more sense. The Stacey Diagram also recognizes that if you have no idea about your requirements and no idea what your tools should be, you are in sheer chaos or anarchy and it’s a bit like trying to predict when a volcano will erupt or when the next natural disaster will strike. (But agile will take you right to the edge of that sort of impossibility too!)
Next, Some History
Agile’s roots come from a number of places. There are many aspects of agile inspired by Lean Manufacturing, including the likes of Henry Ford, Frederick Taylor and Taiichi Ohno. And of course, the software industry experts who gathered at the Snowbird Ski Resort in Utah, almost exactly 18 years ago to write the Agile Manifesto and its 12 Principles. Lean Manufacturing influenced agile with its concepts of optimizing flow, baking quality in, and just-in-time inventory management. Taylorism and Scientific Management was hyper-focused on maximizing output by minimizing waste of movement and wait times. Taiichi Ohno used these same principles to create the Toyota Production System, which represented his vision and inspiration for how he managed the company. Maybe you’ve heard of the andon cord that enables anyone to stop the production line to fix a problem with quality. And the word Kaizen which means “change for better” has become one of many agile principles inspired by the Toyota Production System.
The connections mentioned above from the manufacturing world were most directly translated into what has become the Scrum software development process by Hirotaka Takeuchi who was the main contributor to an article called The New New Product Development Game published in HBR in 1986.
Then Understanding Risk
I think it’s important for people learning agile to understand, much like the Stacey Diagram shows, that Waterfall is a perfectly fine approach when you have identified enough of the risks through understanding the requirements and understanding the tools, technology and people involved in your approach. But when the risks are higher due to there being more unknowns, we need a different approach. When using Waterfall, there is an inherent risk baked into the process, because the feedback loop with the customer is almost always delayed until the product is done. By that time, it’s too late. We may have built the wrong thing. Or, like many of the world’s software products built this way, only a small fraction of the features are used. That risk is represented by the pink triangles in the diagram above. But if we deliver working software much more frequently, in batches, and ask for feedback from the customer after each iteration, the risk is drastically reduced as shown by the purple triangles. More detail and the source of this diagram is available in this great blog post.
If we think about the themes of the world around us, there’s a reason why this idea of risk has become even more compelling. When it was harder to build large software projects in the 90’s and even just 10 years ago, there was some false sense of safety that using a Waterfall method was still OK, because other companies struggled to deliver large software products too. But now, it’s become commonplace to see young startups build software quickly that directly competes with large companies. This volatility forces large companies to rethink their strategies. You must be more nimble and able to react to changes in the marketplace. It is no longer acceptable to incur any more risk than is necessary in building products. This concept is best represented by a new acronym of sorts that describes the nature of most industries today: VUCA. “It’s a VUCA world”, meaning everywhere you look there is volatility, uncertainty, complexity and ambiguity.
Building an Agile Foundation
In this VUCA world, companies must consider the foundational elements needed today to be able to build software in an agile way. These things include learning the basics like Scrum (read the Scrum Guide, it’s only 15 pages long!), embracing Product Management, building long-standing agile teams that are trusted by management to build the right things and have the freedom to voice dissenting opinions with a sense of psychological safety (Google study proves it’s the most important thing to make great teams). Building great teams in an agile environment requires you understand the benefits of smaller teams, targeting approximately 5–7 people with all the necessary skills you can possible include in those individuals to design, build, deploy and maintain the product. There must also be focus on technical excellence, embracing concepts such as XP, DevOps, Continuous Integration, Continuous Delivery, and Test-Driven Development.
We hear the word “culture” all the time when we talk about Agile Transformations and when shifting from Waterfall to Agile. That starts with an understanding of the Agile Mindset (read the book by Gil Broza!), having a willingness to embrace change and build a Culture of Learning and a Culture of Experimentation. In this way, companies trust their software teams to innovate and make it a priority with the products they are building, not relegate innovation to special teams. It will become OK to read a book at your desk for the good of the team. Individuals will welcome the idea of sharing knowledge and consider pairing with each other as they write code so that no one individual has special knowledge that could hamper the team should they disappear. And most importantly, the team takes ownership of their solutions and understands WHY they are building the product from a customer’s perspective. This allows the team to stop treating “requirements” like orders and more like “hypotheses” that are meant to be validated and explored before building things to best ensure that the customer is delighted.
At the end of this part of the talk, I also spent some time talking about how there are many misconceptions about agile. My book explains this and walks people through what to know instead. Unlearn the myths, to learn the mindset.
Maturing Agile — Transformations and Agility
We’re like an hour or more into my talk at this point. So, I spend just a little time talking through some very complicated topics: Transformations and Business Agility.
These critical success factors represent my opinion about how to guide a successful agile transformation. It’s nontrivial, of course. But there are steps that can be described in a practical way and I especially like the simplest step of all which is starting an Agile Community of Practice. Many companies make the mistake of trying to transform and do too many things at once. Building a foundation of strong and modern agile principles cannot be emphasized enough. I’ve blogged in more detail about the importance of these key ingredients to an agile transformation. Business Agility, which I believe is the future of agile, is an even more complex topic. But to conclude, I’d suggest exploring everything the Business Agility Institute has to offer, attend our meetup group conversations and maybe read a summary of potentially practical advice I wrote on the topic.
About the Author: Brian Link is the author of AgileMisconceptions.com (also available on Amazon) and the owner of Practical Agilist, LLC. Brian provides leadership and coaching services as an Agile Coach at LeanDog. Follow Brian on Twitter @blinkdaddy or LinkedIn, and subscribe to his newsletter.
