August 10, 2018
I’m often called in to help when Agile transformations are stalling out “in the real world”. I’m sure you have your own stories about that! I also get calls when a tool-stack modernization can’t get off the ground or has a slumping adoption rate... again, a common issue. I’m a huge fan of Agile and a bigger fan of DevOps (not that they are comparable) and modernizing our tools, but the notion that an Agile transformation is too disruptive to add major changes to tools and tech stacks at the same time is simply not true. In fact, out here in the real world many of the problems my team helps to solve came into being because our clients did one with little forethought or concern about the other.
Living in an Ecosystem
Every organization is an ecosystem, and it can only be optimized globally. Imagine a rainforest, and how the introduction of a new species in one corner can lead to unpredictable failures that cascade throughout the system. Now think of all the tool types that allow your company to create value efficiently- that make up your organization’s “production ecosystem”: communications, documentation, storage, distribution, and production itself. Now let’s pick an easy one, documentation:
Do we have multiple ways of creating and storing documents?
Do people need to be re-trained on a new documentation tool when the change departments?
Do we have to duplicate documents from one tool to another across work areas, resulting in multiple vendors?
If you answered “yes”, your organization may have a traditional reward structure which can accidentally incentivize managers to keep their solutions to themselves and fail to reward cooperation and facilitating others’ success. Ask yourself similar questions about differing expectations, tools, and procedures around communication, production, and the other aspects of your business. Finding ways to reward coordination across departments and finding global solutions frees managers to reduce redundancies in the organization as a whole.
Define Basic Change Vectors
Now that we have the global view of optimization, will we work on tools or methodology? Here lies the risk of another “localization”: making changes in methodology, or tooling, or baseline cooperation requirements without regard for how they affect the others. Risk isolation is an important concept, but when misapplied it can lead to false results. Ecosystems are not code. You can’t check in one piece at a time to reduce conflicts. Ecosystems are more like environments; any change must be planned and tested in relation to all others.
For example, an Agile transformation in a group where progress is still tracked on a local spreadsheet that gets emailed, edited, and returned to several people is not going to stick. Buying a great new cloud suite for project management without changing the way we manage is wasted money.
And so, our approach to global alignment has to have three dimensions: inter-departmental unity, methodology, and tools. Focusing on just one without regard for the others can create scenarios where value and efficiency and morale actually drop, rather than just fail to reach peak value... and the stakes are a little higher now that we’re on a company-wide stage. Every choice we make affects every other decision made, and with that in mind, it’s worth taking an Operations Design perspective.
Thanks for reading. In Part Two we’ll discuss how to implement these changes in the real world, with some success stories and some painful and valuable lessons. In the meantime, you can take a look at our Operations Design services, and share your thoughts about this post on my LinkedIn Profile!
Some suggested longer-form reading that inspired some of the thoughts in this blog post. I don’t necessarily agree with everything there, but they are interesting:
Again, here’s my LinkedIn Profile if you’d like to reach out!