Agile Removes Limitations—You Must Now Change the Rules

If you're practicing agile methods but continue to reach back to the rules and structures your organization used before adopting agile, you might be asking for more trouble than you know. In this article, George Schlitz discusses the mingling of old and new rules in organizations in different phases of agile adoption and offers a four-step method to help sort out the confusion.

Have you introduced a major process change like one of the agile methodse.g., Scrum, XP, etc.? Have you spent any time thinking about the existing rules and other structures in your organization that may need changing?

If not, you may run into trouble when agile teams bump into existing processes such as:

  • Separate build and deployment processes
  • Formal audit or compliance processes
  • Other development teams using more traditional methods
  • Centralized teams and their architecture, infrastructure, design, etc.
  • Human resources-related policies and processes like career tracks, evaluation criteria, and more

Agile Is a Change for More than Just the Development Team
Agile methods are described as software development methods. Most introductory material, like the Agile Manifesto, describe how agile teams are organized and act but don't describe some of the things that happen outside the development teams.

When your teams start using new methods, they will act in a drastically different way from the norm, especially in an organization that has not otherwise changed. There is bound to be some conflict.

When you bump into existing processes or rules that seem to get in the way of your agile teams, you will have an important choice to make: ignore the rule, follow the rule, or try to change it.

Option 1: Ignoring the RulesI Hope You Have Good Air Cover
This is perhaps the simplest option but one I do not generally recommend. If you have sufficient leadership support, you can be exempt from following the rules. Though this will allow you to make progress in the short term, it may cause big problems in the long term, such as:

  • Breeding distrust between development teams and other groups or teams when they are excluded and ignored
  • Making it easy to say that agile is just for [insert your generalization heresmall, collocated, simple, unregulated, etc.] projects and doesn't scale
  • Deferring big problems, potentially allowing them to fester and build up resistance to agile in the organization
  • Not utilizing the greatest source for change potentialpeople!

Option 2: Following the RulesProliferating Local Optimization
The organization created rules and processessurely for a good reason. Shouldn't we be good corporate citizens and follow them? In doing so, other groups and teams will take agile teams more seriously and will allow your teams to slip in alongside teams using other methods, nearly unnoticed. Depending on the rule we are dealing with, just following may be the right approach for the time being. However, before you choose to go along with the existing process or rule, consider the shortcomings of this approach:

  • It introduces a high potential for local optimizationimproving one part of the process while leaving other parts of the process in place. Though your teams may get more stuff done, delays will still exist in other parts of the process, possibly resulting in little or no overall improvement to the organization.
  • It increases work for your teams to meet the requirements of the existing process or rule. You might find yourself creating artifacts or taking steps that don't add value or reduce risk just to follow the process or rule. (See the example below, which focuses on an existing audit process.)
  • It gives the impression that agile is only about the development teams and has no implications for the rest of the organization.

About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.