Accidental Agility

Thought Exercise One

Let’s say for the moment that I am the CIO of a mid-sized company. I have a team of 100 or so people building software. Let’s also say that those 100 people are largely dedicated to 10-15 smaller products, there are few dependencies between those products, and we are currently using traditional project management to coordinate the flow of value across the organization.

Let’s also say for the moment that my traditional project management approach isn’t working so well and I seem to have as many Project Managers as I have developers. I hear about this new way of working called agile, send my Project mManagers to a CSM class, and when they come back, I reorganize my people to be dedicated to products.

I give each product a product owner, maybe let some of the project managers or team members play the ScrumMaster role, I start building backlogs, plan in releases and two week cycles, and do all the roles, artifacts, and ceremonies prescribed by Scrum. I’m wildly successful with this new approach and now I am a convert to Agile.

Thought Exercise Two

Let’s say I get bored in my old job because things are going so well, so I decide to get a CIO gig with a larger more established company in the area. As part of my department, I have 500 developers working on a large monolithic legacy COBOL system. I have one core product, several smaller products, and market offerings that are a mix of several different products.

Like in my first gig, my new team has been using traditional project management to build software and it isn’t working. Because I had so much success with agile in my last company, I want to try out agile in the new company. I break all 500 or so of my people up into small dedicated teams, I find Product Owners, and I turn my Project Managers into ScrumMasters.

We are meticulous about doing Scrum the right way. We’ve named people to the roles, we are doing all the ceremonies, we are doing all the artifacts. Even thought is seems we are doing everything right, we aren’t getting the same results we got last time. All the training, coaching, and executive support isn’t making any difference this time around. What changed.

So What Did Change?

It’s tempting to want to blame the people. It’s tempting to want to blame how well they followed the process. It might even be tempting to think that agile doesn’t work everywhere and just go back to the old waterfall way of working with renewed vigor. The reality is that agile worked in the first company by accident. It failed in the second company by accident too.

Why?

The processes associated with Scrum are designed to work when you have a small cross-functional teams that can operate independently from all the other small cross-functional teams in the organization. In the first scenario because you had products, with little or no dependencies between them, the environment was a natural fit for agile and it worked.

In the second scenario, you have a situation where the environment was not conducive to agile. You had a monolithic infrastructure, poor architecture, competing business goals, interdependent products, and the teams could not work with any degree of autonomy. Too much coordination was required and it was difficult to make an independent decision.

Accidental Agility

This is something I see sometimes when we are out talking to executives about agile. You see, most executives at this point are familiar with agile. Some like it and believe it works. Some have seen it fail and are not bought into it’s benefits. Some executives have had success in one company and have failed in others and aren’t sure why it didn’t work the second time.

I call this phenomenon accidental agility. Accidental agility is when the processes of Scrum are native to what you have in place and they work without everyone fully understanding exactly why. We learned Scrum and it was just awesome. The trick is understanding why Scrum works, and what conditions lead to it’s success.

If those conditions are in place, great. If they are not, you have to create them. Following a process outside the context it was designed to operate within is a recipe for disaster.