Skip to main content

Fundamentals of Agile Transformation

Mike Cottmeyer
Reading: Fundamentals of Agile Transformation

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:

Post 1: Are We Solving the Right Problem?

Post 2: What Problems are Executives Trying to Solve with Agile?

Post 3: Is Your Business Model a Good Fit for Agile?

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 4: How to Make Commitments in the Face of Uncertainty

Post 5: Predictability Over High Performance

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 7: How Do Agile Teams Work?

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.

Next Post 500

LeadingAgile CEO and Founder, Mike Cottmeyer is passionate about solving the challenges associated with agile in larger, more complex enterprises. To that end, he and his team are dedicated to providing large-scale agile transformation services to help pragmatically, incrementally, and safely introduce Agile methods.

Comments (3)

  1. Eddie
    Reply

    Looking forward to the next post, very intriguing! One area I would love to see you cover is about organisational power structures and how an Agile transformation can impact these, and be impacted by them — I’m thinking along the lines that Professor Jeffrey Pfeffer has developed at Stanford University and written about in his various books.

    Reply
    • Mike Cottmeyer
      Reply

      Good topic, I’ll hit something close before we are done ;-). Thanks for the comment.

      Reply
  2. Ivan
    Reply

    The text and background color makes your blog a little less than easy to read. Just thought I’d share that with you, you have an otherwise great site with lots of good information!

    Reply

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

What is the Worth of a Good Product Owner? w/ Tim Wise

This week, on SoundNotes, we’re featuring another question from a student in one of our Certified Scrum classes. The question came from someone who’s working in an organization that doesn’t see value in the role of Product Owner and isn’t convinced that it’s needed as part of the Scrum Team. The question: What is the […]

How Do I Use Scrum on Data Warehouse Projects? w/ Dave Nicolette

In one of my recent Certified Scrum Master classes, I had a number of students who were working on projects involving migrating from a legacy data warehouse to new data warehouses. Figuring out how to apply Scrum to the work they were doing presented a number of challenges and left some open questions.  Here are […]

Maximizing the Amount of Work Not Done

One of the principles of the Agile Manifesto reads: “Simplicity – the art of maximizing the amount of work not done – is essential.” Okay. What does that mean? Does it mean we should avoid doing our work to the extent possible? Well, not exactly. Consistency Between Lean and Agile Principles Without coming at the […]

Prioritizing the Work to Maximize Return w/ Dennis Stevens

This week, on SoundNotes, we’ve got Part 3 of a trio of interviews with LeadingAgile Chief Methodologist and Co-Founder Dennis Stevens. The series focuses on how to build an organization that can embrace change. In the final episode of the series, Dennis and Dave cover how to prioritize work being done to maximize return. During […]