Agile Advisor

Road Rules for Agile Teams

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

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?

About the Author

Aaron Bjork is a Principal Program Manager at Microsoft working on Agile experiences and tooling within Team Foundation Server (TFS). Prior to joining TFS in 2008, Bjork worked as a software engineer and development lead in Visual Studio. He is passionate about Application Lifecycle Management solutions and has a strong desire to see teams improve their software engineering practices. Follow Bjork on his blog at blogs.msdn.com/aaronbjork.

comments powered by Disqus

Featured

  • GitHub Copilot for Azure Gets Preview Glitches

    This reporter, recently accepted to preview GitHub Copilot for Azure, has thus far found the tool to be, well, glitchy.

  • New .NET 9 Templates for Blazor Hybrid, .NET MAUI

    Microsoft's fifth preview of .NET 9 nods at AI development while also introducing new templates for some of the more popular project types, including Blazor Hybrid and .NET MAUI.

  • What's Next for ASP.NET Core and Blazor

    Since its inception as an intriguing experiment in leveraging WebAssembly to enable dynamic web development with C#, Blazor has evolved into a mature, fully featured framework. Integral to the ASP.NET Core ecosystem, Blazor offers developers a unique combination of server-side rendering and rich client-side interactivity.

  • Nearest Centroid Classification for Numeric Data Using C#

    Here's a complete end-to-end demo of what Dr. James McCaffrey of Microsoft Research says is arguably the simplest possible classification technique.

  • .NET MAUI in VS Code Goes GA

    Visual Studio Code's .NET MAUI workload, which evolves the former Xamarin.Forms mobile-centric framework by adding support for creating desktop applications, has reached general availability.

Subscribe on YouTube