The ubiquitous employee handbook is filled with rules, regulations, and descriptions of how employees are expected to behave. The larger the organization, the thicker the handbook. Handbooks and associated policies like this have been described as “corporate scar tissue.” Someone somewhere at sometime made a serious mistake, whether intentional or not, and so a policy was created to prevent that something from ever happening again. The same effect can be seen with many consumer products that have lengthy warning labels and manual pages stating things like “This toaster is not suitable as a flotation device in the event of a boating accident.”
In an effort to prevent a re-occurrence, the policies effectively limit – much like physical scar tissue – the ability of people within the organization to adapt, improvise, and innovate. They limit an employee’s range of motion within the organization’s solution space. In an effort to save the organization from human error and create the perfect business machine, excessive policies condemn the organization to a slow but certain death.
Anyone who has worked within a large organization recognizes this. For some, it’s a comfort. Knowing the rules. Knowing where the fences are. And knowing where to place blame. The less ambiguity around how a situation can be interpreted the better. For others, maybe after an attempt to change things, the environment becomes too stifling and they leave for greener, wider pastures.
Given enough time, the policies become the document of record for the organization’s culture. Any attempts to change the way work gets done within an organization that has deep scar tissue will have to confront Shalloway’s Corollary:
When development groups change how their development staff are organized, their current application architecture will work against them.
I’ve learned this corollary is not limited to software companies. In every case I’ve experienced, whether in a software company or not, the system will push back. Hard. Every Agile practitioner needs to know and respect this. Riding into work on a unicorn with a bag of rainbows and pixie dust is a gig that will not end well. At best, the organization will have made an incomplete effort at implementing Agile and “Frankenagile” will be roaming the halls – a collection of project management methodological parts that by themselves served a valuable purpose in a larger or different context, but have been stitched together to form a monster in Agile form only.
In a small company, particularly if they are working to create a software product, the monster may be small. So performing corrective surgery, while still a lot of work, is quite possible in a relatively short amount of time. For larger organizations, particularly those with deep roots in traditional project management, it can be a scary sized beast indeed. Something not to be trifled with, rather something that needs a well thought out strategy and plan of action.
It is the latter scenario I’d like to address in this series of posts (this being Part 1, the introduction) over the next several week. What I’d like to present is a method I’ve used quite successfully over the past 10+ years for assessing the extent to which Conway’s Law and Shalloway’s Corollary are in play. It is a method for determining both team and organization health within the larger management context. The extent to which Agile can be successfully implemented in an organization is dependent on how aware management, the Agile coach, and scrum masters are of the system dynamics driving organizational behavior.