Archive for the ‘Complex Adaptive Systems’ Category
Many of us encountered situations in which the spread of Agile in an organization came to a halt. It was quite successful at the project level, but did not spread to the product line; it worked well for the product line, but did not get accepted by the business unit; or, it proved itself in the business unit, but success did not lead to adoption at the enterprise level.
… as a living entity, a company is always insecure, never stable, always subject to shifting relationships between the company and the outside world.
Furthermore, de Geus suggests a company has its own ladder of personae: Individual –> Team –> Work Group –> Division –> Company –> Corporation –> Society. According to de Geus, the persona of an organizational entity satisfies the criteria (cited by William Stern) for a living persona. Like live human beings, organizational entities:
… must find their place in the world; they must develop a sense of relationship between their own persona’s ethical priorities and the values in the surrounding world…. The Persona has an influence on the world around it as an example, a “role model,” but it can never equalize the world’s view with its own.
If you accepted this premise, implications with respect to spreading Agile are intriguing. A mismatch between the involved organizational personae might be the obstacle to broader acceptance of Agile. The mismatch might be related to Agile. Or, it could equally well be unrelated. For example, it might revolve around the need of one organizational entity or another to self-preserve itself.
I find it fascinating that Ken Schwaber has actually discussed Agile success and failure along somewhat similar lines, as follows:
I estimate that 75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it… The intention of Scrum is to make [their dysfunctions] transparent so the organization can fix them. Unfortunately, many organizations change Scrum to accommodate the inadequacies or dysfunctions instead of solving them. [AgileCollab interview of February 19, 2008]
The corollary from the observations of Stern, de Geus and Schwaber might seem counter-intuitive. If the spread of Agile in your company has stalled, providing qualitative and quantitative data on the benefits of Agile might not be the best way to win over support for broader adoption. Instead of hard sell of Agile benefits, focus on cross-organizational dynamics, pathologies and development.
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:
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.
- “All the evidence says that evolutionary processes work for systems large and small…”
- “… risk taking is the fastest route to fitness.”