Uncharted Waters

Dec 1 2015   9:27AM GMT

Why Agile Doesn’t Scale

Justin Rohrman Justin Rohrman Profile: Justin Rohrman

Tags:
Agile
Scaling

Agile came about as a response to the extreme standardization of software development process that was popular through the early 2000s. That standardization mostly came in the form of waterfall and Rational Unified Process (RUP).

The principles of agile suggested the exact opposite of processes like RUP and waterfall. Instead of a one size fits all approach, we now have extreme customization. There is no common starting place and every team applies the principles just a little different — some use scrum, some use kanban, some TDD here, and a CI system there.

Managers noticed that loosening up on standardization got software done faster and want to spread that goodness through their company.

There is a problem though, agile doesn’t scale.

My first encounter with agile (and scrum) was in 2006. There were around a hundred developers working at that company and a small group, I think it was 4 or 5 people, did an experiment based on some crazy stuff they read on the internet.

That group started delivering prod ready code once a month or so. That seems slow now, but it was a big change from the every three to six months the rest of the company was at. They also started doing a daily meeting we later learned was properly called scrum.

They were the A Team, and they were way more productive and efficient than the rest of us.

The team I was on was working on a brand new product. We had a pilot running at one facility but no paid customers yet. The experiment that the A Team was running looked like a way to get things done faster, so a week later our development manager had us transitioning into trying to release software faster, and doing daily stand ups exactly as the A Team had.

My team was much larger, we were over ten people. So while we replicated almost exactly what the other team did, our results weren’t so smooth. Our daily scrum took 45 minutes to finish and since there were now two scrums running, managers had to meet after for a scrum-of-scrum to get the full picture. Developers ended up getting only parts of work done each release cycle which caused problems for everyone on that dependency chain. Some of the people that had been around much longer than I had were just frustrated and biding their time till management went on to the next hot fad.

409px-Infographic_of_scaling_up

We stumbled through that mess for months. A few other teams joined the confusion along the way.

Scaling is the problem of finding the right amount of tension between standardization and customization. It is the question of how much of what we do can be exactly replicated everywhere, and how much needs to be done differently for each team and each context that we find in our company.

There are a few frameworks, SAFe for example, that claim to be able to take agile and spread it through a company making everyone faster and more efficient. Scaling frameworks mostly do this through standardization. They are prescriptive and identify specific roles, processes, and names for everything you need to do. Generally, they also require a coach to come in and show how to implement the framework.

I’ll let you guess what usually happens when the coach leaves the building.

Agile can’t scale because there is too much tension between standardization and customization. The principles are just that. They give direction, but not method. Teams I have seen that focus too much on practices — TDD, BDD, kanban, scrum — and implementing them across the board usually end up saying that they are “…doing agile, but….” I have seen examples of this working on small teams, even small groups of small teams, but once the word ‘enterprise’ enters the discussion things get tricky.

Customization and constant drive to improve make half of a company feel like they never know what is going on. Standardization makes the other half (I’m sometimes in this half) feel like restrictions are keeping them from getting real work done.

Next week, I’ll go  deeper into the scaling problem and talk about the book Scaling Up Excellence.

 Comment on this Post

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: