Skip to main content

Agile Is Supposed To Be Simple…

Mike Cottmeyer
Reading: Agile Is Supposed To Be Simple…

I was reading about the new iteration of SAFe that came out a few days ago. I appreciate what Dean is doing with SAFe and totally get the problem he is trying to solve. That said, it makes me wonder how folks receive the ever growing complexity of the model.

Fundamentally, we have two choices as leaders of companies.

We can model and manage the complexity inherent in the system, or we can reduce that complexity. What we can’t do is pretend the complexity doesn’t exist and fail to do something about it. So often I see agile implementations that want to ignore what’s really going on.

This is too complex, agile is supposed to be simple.

True, but agile is also supposed to be 6-8 people sitting in a room with an onsite customer. Teams are supposed to have autonomy. Teams are supposed to have the power to decide. Teams are supposed to have the ability to change direction when they learn new stuff.

You can’t have your cake and eat it too.

It’s naive to think that three roles, three ceremonies, three artifacts are going to fix everything in your organization. It’s naive to think that you can self-organize the complexity away. It’s naive to think that companies are going to stop caring about when and how stuff is going to get done.

So again, we come back to two fundamental choices for making all this work. Model and manage the complexity in the system, or make the system less complex. It’s your call.

Next Is Your Program Team Just a Messin’ an a Gommin’?

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 (5)

  1. David Bishop
    Reply

    Very well said. That’s exactly what comes to my mind everytime I look at the SAFe model…. just too complex.

    Reply
  2. Bob Marshall
    Reply

    Keen observations. I’ve been focused for at least the past twenty years on making things simpler. “Natura valde simplex est et sibi consona”. How much simpler could it get than the one #AntimatterPrinciple?

    – Bob

    Reply
  3. Craig Buchek
    Reply

    It’s becoming apparent to me that Kaizen (continuous improvement) is more important than any other Agile practice or principle. It doesn’t matter so much *how* you improve, as much as the fact that you *are* working to improve.

    Agile methodologies have a lot of practices that you can adopt in your improvement process, but the practices should be seen as stepping stones in the path, not as an end state.

    That said, simple will generally beat complex, and starting simple is a necessity.

    Reply
  4. Gianpaolo Baglione
    Reply

    One of the reasons SAFe is appealing because it aligns agile teams to money and power in a way that the people with the money and power can understand.

    Reply
  5. Jay Conne
    Reply

    Well said Mike, model the complexity or reduce it.

    Or perhaps, try to reduce it first and then model it.

    SAFe, like all approaches to large scaling, including yours, provides a lot of tools, thinking tools, to address typical complexity of large organizations. One can use the ones needed in one’s context and benefit from the documented relationship between them. Asking the comprehensive set of questions os the question – for leadership and the empowered individual contributors.

    The whole process around releases is the challenge that is served by the second level with multiple teams’ work being integrated.

    The higher layers of the business goals driving mission charge and funding needs to all be made coherent. That’s the WHY driving the rest – the WHAT and HOW.

    Any approach that achieves this is worthy of consideration. A big advantage of SAFe is the extensive, graphically integrated, documented and freely available content.

    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 […]