Skip to main content

That’s Not Agile!?

Mike Cottmeyer Chief Executive Officer
Reading: That’s Not Agile!?

Agile at the Enterprise Level is not about the two-week inspect and adapt cycle… it’s about small batches and flow.

You may have noticed that LeadingAgile is growing… and we are growing fast. Why? A large part of our approach to selling involves deeply understanding what our customers need and helping them craft solutions that meet them where they are. Some of the companies we work with are inventing new markets and creating emergent new products. Many of them though are desperately trying to figure out a way to deliver against defined commitments to existing customers. They desperately need some ability to do what they say they are going to do.

Businesses need to be predictable… they need to be able to regularly and reliably make and meet commitments. If you talk to these companies, many of them will tell you that they need to be predictable 12 to 18 months out. Personally… in most markets… I don’t think that is a reasonable expectation. For one… it is tough to really know how you are going to build the system that far out, and two… it is VERY unlikely that what a company thinks it needs 18 months from now is actually what it is going to need in 18 months. Needs are changing and markets are changing too fast.

For most companies we work with, the sweet spot is 3 to 6 months. If the product development organization can reasonably hit a 3 month commitment and have at least a high level idea what things will look like 6 months out… that is something we can work with. Even if a team is sprinting two weeks at a time… if they don’t know where they are headed 3 to 6 months into the future… chances are the organization is thrashing and the team will get frustrated. Even agile teams don’t like getting yanked around.

Getting Predictable

So… how do we get predictable 3 to 6 months out? First of all… let’s apply a principle that we know from team-level Scrum. For a team to make and meet a sprint commitment, the team must have some idea of what it will take to deliver the stories. If there is no acceptance criteria… if the stories are too big… if the team has no idea how to approach the work… we pull out one or more spikes to go figure that stuff out. A spike is simply a user story the product owner includes to help the team do the discovery and mitigate implementation risk and uncertainty.

The lesson here is that we can’t commit… even at the sprint level… to things that we don’t understand. There needs to be some prep work… in the case of a single user story… for a single team… for a single sprint… that is a spike. If we extend this metaphor up to the release level, that means that we shouldn’t commit to a release when we don’t have any idea how we are going to deliver that release. For a team to have a stable release plan… they need to know the Epic/Feature/User Story decomposition AND they need to have most of the release level spikes completed.

Release Spikes

What is a release level spike you ask? It is a slice of the product we build during the current release to mitigate risk and uncertainty in an upcoming release. We build the minimum set of user stories we can possibly build to understand the problem, prove the architecture, and define the backlog… so that when we exit release planning… we have not committed to work that isn’ well enough understood. It’s the same thinking we use at the sprint level, just applied one level up at the release level. Don’t commit to what you don’t understand.

So here is the rub… that means at any given time I need to have a well articulated backlog three months out… and a pretty good idea of what the backlog looks like three months after that. I usually refer to this as a three-month rolling wave plan. When I talk to folks about planning a well groomed backlog 3 to 6 months out… to many, that starts to feel like Big Up Front Planning… frankly it starts to feel like Waterfall. So… how do we plan forward… how do we mitigate risk… how to we get predictable without creating a big Waterfall Gantt chart?

3 Month Backlog?

The trick to establishing a rock solid agile release cadence and creating an organization that is able to make and meet commitments 3 to 6 months out… while staying agile… is all in how you write your requirements. It’s in how you define your projects. It’s how you schedule work in your organization. Frankly though… it’s not at the team level… it’s at the program and portfolio level.  Enterprise agility is about loose coupling between projects, and Epics, and Features… it’s about loose coupling at all levels of the organization. Remember that line in the Manifesto that says ‘we value responding to change over following a plan’?

That line doesn’t mean we don’t plan… it just means that we create plans that are resilient to change.

Small Batches and Flow

If at every level of the organization we focus on smaller batches… we focus on flow… we focus on limiting work in process… we focus on getting work done… we always maintain the ability to inspect and adapt. We always have the ability to change our mind as we learn new things about our product. We always have the ability to respond to change as we learn new things about our customers. Planning is how we mitigate risk… planning is how we define what we are going to do. We don’t throw up our hands and give up on planning… we look ahead and create plans that are resilient to change.

I’ll tell you… if you are having problems selling agile to your leadership team… it’s probably because the messaging you are using doesn’t resonate with them. Again… most of the folks that use our services care deeply about predictability. Do what you say you are going to do when you say you are going to do it. When things change, our plans will be resilient, and we’ll communicate and manage expectations accordingly… but leading with a message that says we can’t make and meet commitments is a non-starter. 3 to 6 months of well groomed back log helps that.

Enterprise Agile is more than Sprints

The point I’m really trying to get across here is that for most enterprises, agile isn’t about the two week inspect and adapt cycle… it’s more about smaller batches and flow at the program and portfolio level. It’s more about limiting work in process of major initiatives. It’s more about establishing a predictable and reliable delivery cadence that gives executives options for managing their business. Being agile isn’t about making it up as you go and not writing anything down… it’s about reliably and consistently putting products into market that your customers will use.

Next What is a User Story?

Comments (6)

  1. Sridhar

    Hey Mike

    Great post! One of the challenges I often see for product teams is that when marketing decides what features go into releases (this is small, but influential number of IT projects). Marketing folks, while being intelligent and hard working, become fickle-minded when given such freedom (conflicting customer demands, competing products, need to differentiate etc) and start to make changes to the well-understood backlog.

    Another challenge are the dependencies of some user stories on other stories – without understanding dependencies and establishing a “platform” of basic features, it becomes very hard for the project team to deliver in a cadence. A DSM can help resolve some (not all, of course) of the dependencies and can contribute to the analysis of the product backlog, thus enhancing the knowledge of the team.

  2. Mike Cottmeyer

    Thanks Sridhar. It’s a funny balance… if we want to be predictable…. we have to be able to look ahead. If we want to accommodate constant change… agile can deal with that too… it’s just a different problem. What I find is that leadership wants teams to be predictable but change everything all the time. Those two competing needs work against each other and we have to make a strategic decision what kind of organization we want to run… you CANNOT have it both ways.

  3. Matt Block

    Great post as always Mike! I have to agree. With the last company I worked with this predictability 3-6 months out was the largest benefit we got from agile. Prior to moving to agile we had no predictability in releases and couldn’t meet any commitments. Releases were constantly delayed and we never really had great confidence in when a release would happen more than 2 – 4 weeks out. After we adopted agile we consistently met our release commitments and had high confidence in our dates 3+ months out.

  4. Laurence Wheway

    YES! You describe the nirvana of well oiled agile machine… but this is exactly how it should work, and I have seen it working beautifully well on my projects in the past.

    It upsets me that people dirty the name of agile by using it as an excuse for not planning!


Leave a comment

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