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.