Being Agile and Procrustean Don’t Mix

procrusteanScaling agile software development techniques to enterprise levels has plenty of challenges. Getting a small team — say 5 to 7 people — working together and building great software solutions happens regularly. Getting large teams — say 500 to 700 people — to do the same is an engineering feat that challenges our human abilities.

Breaking up large projects into small chunks of work and handing-off those chunks to small teams makes a lot of sense. Of course, there’s a new challenge in defining the chunks. It requires some up-front software architecture planning that agile development purists won’t like but let’s examine this scenario more closely.

For the sake of discussion, let’s say we have a large, complex system. We’ve broken it down into components and assigned the components to agile development teams. Now the fun begins.

  • How do we synchronize the teams and keep them in sync?
  • How do we compare team performance so we can get all teams to the same level?
  • How do we enforce engineering standards across teams?
  • How do we get the teams to deliver simultaneously?
  • How do we … STOP!

Don’t answer those questions. The teams cannot and should not operate uniformly. Demanding conformance and uniformity is procrustean and anti-agile. Getting development teams to march in unison is an enormous amount of work. You’ll spend more time synchronizing and standardizing than getting real work done. Even worse, the slowest, poorest performing teams will set the pace. Everyone else will have to slow down!

Learn to Let Go

Being agile means going with the flow — letting teams determine what works best for them and giving them the freedom they need to be the best they can be. (Flow — that’s why Kanban is often viewed as an agile technique even though it’s not inherently so but that’s a subject for another day.) Obviously, some rules, guidelines and limits are needed but don’t get too picky.

Great agile development teams self-organize. That’s not the same as self-manage. To self-manage means to pretty-much do whatever you want. To self-organize means to accept initial conditions and make adjustments based on continuous feedback. One of the keys to making this work well is to keep the initial conditions minimal and make the feedback general.

Too many initial conditions result in command-and-control hidden within an agile framework. Feedback that is too specific also results in command-and-control as the team members learn to follow instructions rather than think for themselves.

Agile development can be scaled up to enterprise heights but only if the organization gives up its procrustean ways and learns to accept diversity in the way agile teams operate. Focus on deadlines and quality not individual features and functions. Deliver minimalist solutions and make them the best they can be.

Because in the end, it’s about the customer not the development process.

Updated: August 20, 2013 — 9:57 pm