So, what's the problem?

It is becoming more and more recognized that iterative development, specifically those using agile methods, offer a significant advantage to those companies trying to achieve both higher throughput in their project organizations and better alignment with the business organizations. Historically, these types of methodological shifts have been initiated by either the business or director levels within the development organization. Many times, these individuals can initiate an entire organizational transformation with the graces of senior management by referring to successful case studies documented in industry literature . Overcoming the immediate concern that Agile is merely cowboy development with barely more controls than the loose code of conduct rules that go with the cowboy activities, IT has begun to embrace the methodology principally because it has indeed been able to deliver on its hype.

The collection of these documented success stories are swelling and are driving Agile into the mainstream of software development. However, in the past several years, we have also begun to see an interesting phenomenon whereby successful transformations begin to devolve fairly rapidly, even to the point where projects begin to slide and even fail. We are also seeing a number of companies contracting in services to re-enable their agile transformation with the hope of recapturing their early successes and perhaps making the transformation stickier this time around.

Thinking back to 9th grade brings to mind the old Newtonian adage: things in motion tend to stay in motion unless acted upon by an outside force. Although it is certainly possible that in any of these situations where the transformation has deteriorated there may be active resistance to the change that acts as the outside force, but typically a process change is not deemed successful until there is consensus amongst the team members. This suggests that active resistance would have been weeded out prior to declaring the methodological shift successful. If we throw in to this mix another adage, this one from my early university aspirations, I think we can begin to understand what the crux of the issue is. From thermodynamics, we understand that entropy suggests that systems deteriorate into disorder if there is no continuous containment forces. Thought of like this begins to offer some clarity to the forces at work (or not). Clearly there are outside forces that are causing the transformation to slow or even stop – if we believe that at least one of these forces is entropy, which makes sense, can it be reversed?

Continuous containment is an odd term to use with a process or even a methodology, so let’s take some liberties here and refer to is as encouragement or positive reinforcement. Do the agile projects in your organization get positive reinforcement, negative reinforcement, or neither? And, what form does this reinforcement take, if it exists? In most Development and IT organizations, there is a responsibility that belongs to the Program Management Office (PMO) to provide checks and balances on each project. They offer an independent review of budget and schedule for senior management as well as a periodic critique for the project managers. It is this critique that is the reinforcement, the containment force, for the transformation.