Agile Advisor

Road Rules for Agile Teams

Aaron Bjork talks about the importance of simplicity and clear rules in your software process.

• By Aaron Bjork
• 01/06/2012

When I leave my house each morning for work, my routine is to jump on Interstate 405 and make my way up the freeway to the Microsoft campus in Redmond. I live about 20 miles south of Redmond, and because of that distance, I endure a 30-45 minute commute into the office each morning.  When there isn’t traffic (which is becoming a rarer and rarer occasion), the drive is fairly pleasant.  I drive up the freeway at the posted speed limit with a cup of coffee in my handand something pleasant playing on the radio.

On a recent commute into work I reflected on how it is that I can drive a 4000 pound vehicle at a fairly high rate of speed with little to no anxiety or fear? It seems a tad bit crazy doesn't it? A car is a large piece of equipment, and something that can do a great deal of damage when not driven properly. And yet, I'm able to drive my car at high speeds just a few feet from others doing the same thing. How is this possible? The answer is trust. As a driver, I trust that every other driver on the road is adhering to the same set of rules. Those rules are designed to create an environment where everyone on the road can accomplish two things:

1. Quick arrival to a planned destination.
2. A safe and injury free trip.

The rules of the road are essential. They are what create the environment where all drivers can exist together. Take for example the white line that divides lanes on a freeway. It's nothing more than a strip of paint on the surface of a road. Yet, that little white line allows me to drive 60 mph just a few feet from other drivers. I'm able to drive fast because I trust that the car next to me will stay on the other side of the white line. Now, what if the rules didn't exist? What if there was no whiteline? Or even worse, what if everyone played by a different set of rules? Chaos would surely ensue, and I would have little success in accomplishing my goals.

The processes we follow on software teams are no different than these "road rules." They are designed to help the team and the business achieve its goals. They are created to help us move faster together. When organizations look to adopt agile practices, management usually has two goals in mind:

1. Speeding up.The organization wants to produce value for customers at a higher rate.
2. Improved efficiency. The organization wants to be more efficient and produce less waste on the road to value.

Having a clear set of "road rules" is necessary to achieve both of these things. When a team understands the rules, it can operate without fear and spend its energy producing working software. However, without a clear set of rules, or when a team is operating under a set of rules that is constantly changing, success is rare.

There's an obvious balance here. Rules are necessary to ensure the team can move forward, and move forward as fast as possible. But an absence of rules or an excessive number of rules have the opposite effect. Let's look back at our commuting example. We already established that no rules would lead to chaos. The white line painted between each lane on the freeway serves a clear purpose. However, imagine if the department of transportation decided they were going to install a traffic signal every 100 as a way to prevent accidents. While this measure would surely slow everyone down, and might produce fewer accidents, it would also prevent drivers from making any kind of progress. It would slow drivers to the point that people would stop using freeways altogether. It's counterproductive.

In the same way, we need to pay close attention to the "rules" handed down to our teams. On my own team here at Microsoft, I've found myself guilty many times of implementing new rules that did nothing more than place an unnecessary speed bump right in the middle of the lane the team was driving in. The rule didn’t help the team move faster, or make better decisions; instead it weighed them down with a bunch of busy work, none of which produced value for my customer.

Like many things in life, our software processes tend to snowball over time. They collect more and more "rules" until a point comes when it's almost impossible to get anything done. Have you stopped to examine how many rules are in place for your teams? Do the rules help your team produce more value at faster pace?  Or are the rules slowing your team down and creating waste in your process?