Have you introduced a major process change like one of the agile methods—e.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 Rules—I 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 here—small, 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 potential—people!
Option 2: Following the Rules—Proliferating Local Optimization
The organization created rules and processes—surely 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 optimization—improving 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.
Option 3: Changing the Rules—Becoming the Agile Organization
Congratulations, you have decided to take the road less traveled and help your organization become better! Despite the difficulty of doing so, this approach will foster trust, gain additional support for the change, and leverage the great skills and knowledge of people in other teams and groups. It will also enable your teams to get more done when they aren't burdened with process for the sake of process.
I use a fairly methodical technique for this type of situation. It is proposed by Eliyahu Goldratt [1] in his various writings. Goldratt says that organizations make rules to operate in the presence of limitations. By rules, I mean rules, processes, structures, and other arrangements and things. Technology improvements remove limitations. For a change to truly take hold and succeed, the rules that were made to operate in the presence of the old limitations must be eliminated or changed, and new rules created to deal with new limitations. [1]
How can we do this? Follow these steps:
- Determine which old limitations the new process eliminates. For any process step or rule that you encounter, determine why the rule exists. Techniques such as the "Five Whys" and others can help you do this. Sometimes, documentation or experts in said process can help you do this even more quickly. Consult them if possible!
- Remove the rules that existed in the past to overcome the old limitations. Agile methods provide us with principles and practices that overcome many limitations of the past. Validate that the limitations the existing process or rule was made for are handled by the new method. Ensure that those who need the existing process understand this and adapt appropriately, and help them to do this.
- Determine potential new limitations. With any new improvement comes the need to focus on different limitations. This is what continuous improvement is all about. Identify the new, important limitations and adjust your processes and rules to deal with those.
- Repeat! Repeat this process and combine it with frequent retrospection. You'll soon be on your way to embodying continuous improvement in your organization.
All the rules that were made when older limitations existed, if they continue to be your modus operandi, will sap away the ability to improve continuously and embody the change you are trying to make, leech away energy from your change agents, and eventually result in a transition that is mediocre at best. This situation makes it appealing to create a hybrid method, such as combining the Unified Process with agile.
There are other aspects of agile transitions that are important to consider, but changing the rules is a major one that is often neglected due to how difficult it is. Any time you feel like customizing your agile process with something from your former processes, ask yourself if it is because you have found a rule that needs changing!
References
[1] Goldratt, Eliyahu. Beyond The Goal. Your Coach in a Box; unabridged edition (September 1, 2005).
