The Agile Executive

The most frequent misconception I encounter in preliminary stages of Agile adoption is about the exact “pain” Agile addresses. Time and again I witness the surprise of executives, who are not deeply versed in software engineering, when I point out to them that poor technology and packaging choices often manifest themselves as process pains.  In many ways it is like the way pain “travels” in the human body. The back muscle I pulled yesterday during a long flight led to contraction of my neck muscles at night, giving me a headache today. A couple of  Tylenol caplets might help some, but a muscle relaxant is likely to be much more effective.

Three Dimensions to Consider

Following Jim Highsmith’s teachings on coping with uncertainty versus coping with complexity, the conceptual framework I use to frame the subject in the context of Agile engagements has three dimensions, as follows:

• Uncertainty
• Complexity
• Correctness

I literally ask the person with whom I am discussing a project to characterize the nature and status of his project for me, and more importantly for himself, in terms of these three dimensions. Once the project has been characterized in such a manner, our discussion progresses to how each of the three project dimensions could be addressed.

Uncertainty versus Complexity versus Correctness

Agile is all about effectively addressing uncertainty, I say. I stress that Agile does not address complexity per se. It might indirectly help with complexity if it leads you towards deeper thinking about Complex Adaptive Systems. For example, you might consider evolving the product architecture in the course of your Agile project instead of pre-defining it. However, Agile is not a “medicine” for complexity pains.

Nor is Agile about correctness. A hyper-productive Agile team could actually go fast nowhere implementing a poorly conceived product. The “real time” feedback  loops of  the project team might help uncover that a product is mis-conceived. However, independent of the team feedback, you still need to determine what correctness means to you and how you would assess it as the product evolves.

Levels of Correctness

An intriguing question for enterprise level Agile deployment is at what level you should “measure” correctness:

• Product level?
• Solution level?
• Service level?
• Business process level?
• Strategy level?
• Policy level?
• All of the above?

I will address this important question in length and depth in forthcoming posts on Agile Portfolio Management.