Okay…I think this is the 5th post (or so) we have in our series on the Fundamentals of Agile Transformation. You might ask yourself… wait, Mike hasn’t said anything about the Fundamentals of Agile Transformation… and, you know what, you’d be right. What I’m trying to do here is lay the foundation for a different kind of conversation on Transformation than you’re used to having.
I believe that many of us are solving a problem we think our customers have. We might even be trying to solve a problem our customers really do have. The challenge is that our customers don’t always see it that way. They aren’t trying to be more emergent, adaptive, and empowering. They are trying to be more predictable and bring value into market earlier.
I believe that most organizations are very broken… they were never built to be agile and getting them there is going to require a major refactoring. I don’t think this can be done by giving everyone Scrum training and letting them self-organize. That’s like explaining the virtues of service orientation without teaching the skills to untangle their tightly coupled code base.
My belief is that leading an agile transformation with cultural indoctrination may result in pockets of success, but is ultimately doomed to failure. The predictive-convergent organization will always see the budding adaptive-emergent agile teams as a threat. Most organizations need a top-down, bottom-up strategy to ultimately refactor into an agile enterprise.
The first pass through a predictive-convergent company almost never results in a complete adaptive-emergent ecosystem. The first pass often results in ‘agile-like’ team based organizational structures, tight coordination structures and dependency management, and iterative and incremental delivery across all the teams in the system.
I’ve started referring to it as a pre-agile pattern. It’s the first step for an predictive-convergent company to move further down the path to agile. They may never be able to fully achieve the same level of performance of the adaptive-emergent companies, but they’ll be better off and achieve many of the shorter term goals the executives seek
Every company wants to be emergent, adaptive, and empowering… but not if it means they don’t get what they need when I need it. Our goal is to figure out how to build an ‘agile-like’ delivery foundation without disrupting the controls current in place in the organization. Once that foundation is in place, the cultural side of the transformation can begin to emerge.
So let’s take a look at where we are and where we are going:
These three posts were designed to setup the idea that the agile community is disconnected with the goals of many executives and that different companies have different goals with regard to delivery. We called these two kinds of companies adaptive-emergent and predictive-convergent.
Post 6: Fundamentals of Agile Transformation
I wish these three posts were a little more cohesive, but blogging for me is as much learning how to tell my story as it is me telling you my story. I had fully intended to tell you about my house building project, but I felt the need for a little more context setting.
I think we managed to lay a foundation for how adaptive-emergent and predictive-convergent companies look at managing time, cost, and scope and the expectations of each regarding project delivery, and then made a case for why predictability was the first order goal over high-performance.
Here are some topics I think we’ll explore in the next three posts.
Post 8: How Do Agile Teams Fail?
Post 9: Patterns For Forming Teams in Large Organizations
What I want to do here is talk about the failure modes we see in most of the agile companies we engage with. There are a lot of folks doing agile that have it totally screwed up. These next posts will also give some insight into how to properly form teams and what it takes to lay the foundation for success.
After that we’ll either fork into a discussion on the structures of agile organizations or how to coordinate the efforts of many teams having to produce integrated deliverables. We’ll get to both eventually, but not sure exactly what we’ll do next.
I’m going through great pains to untangle some complex thinking here, but I think it’s essential for helping many of you (and maybe me) understand my point of view regarding agile transformation at scale. I tell this story on whiteboards all the time, but writing it is an interesting exercise.
Also… not promising we won’t have a detour or too along the way. Writing on a cadence is hard, and sometimes you have to follow the muse ;-)
Check out the previous post, Post 5: Predictability Over High Performance.
Check out the next post, Underlying Mechanisms of Team Based Scrum.