Cooling before winter!

In February 2001 the Agile Manifesto was signed by 17 people. The Manifesto, comprised of four values and 12 principles, is the rallying point for what would become the agile movement.  It provided a new framework to think about how work should, or could, be approached. That framework challenged the standard thinking of how to develop, enhance, and maintain software. That challenge guaranteed disorder and energy; it created entropy that was harnessed for change. Nearly 18 years later, the excitement and focus which has been the hallmark of the agile movement is showing its age and begun to dissipate under a wave of prescriptive methods and a knee jerk reaction to control.  This is a pattern of change that has repeated over and over across history. The age of the cowboy and cattle drives was conquered not by the six-shooter, but by fences. The Capability Maturity Models (CMM and CMMI) spawned an industry of assessors who policed software development usage which helped to give birth to the agile movement. We are now at a similar inflection point.

The last 18 years have been a blaze of technical change – perhaps even faster than how people work.  For example, the iPhone did not exist when the agile movement began. The speed of change in the software environment makes the agile movement seem even older than a mere 18 years. No one in the industry should be shocked that both the rate of change in the definition of agile and the techniques that support agile across the myriad work environments have begun to slow their evolution.  That slowing is a form of heat death that is sapping the rate of change. Software development and maintenance approaches are impacted by two extremes, but common, process control approaches. Both of these sources stem from how leaders provide guidance and oversee how work is done within an organization.

The first form of behavior that saps entropy and induces heat death is overly proscriptive guidance.  Proscriptive guidance defines behavior that should not be performed and is often coupled with explicitly prescriptive guidance.  The manual for my new car has a list of things I need to do and a list of things I should not do to keep my warranty in place – the former is prescriptive and the latter is proscriptive.  This type of framework makes sense for my car’s warranty because it is a legal contract, but when overdone in software development and maintenance environment it is chafing because it curtails the ability to change, to inspect, and adapt based on context. Explicit checklists that govern what can and cannot be done don’t make sense in highly complex scenarios where learning and experimentation are required to solve the business problem.  Arguably, there are things that technically should not be done. For example, promoting open APIs that allow access to user’s personal data would be one. Whereas not allowing a team to hold a stand-up in the afternoon rather than the morning because the rules say to meet in the morning is problematic. Proscriptive guidance is often made worse when coupled with aggressive oversight (process police) which makes the term guidance an oxymoron.  Combat this form of energy dampening by adopting a loose framework with a set of principles along with coaching. Loose guidance will foster a find your own adventure approach provide teams the guidance needed to address complex problems while keeping the idea of self-managing teams intact. Coaching empowers teams to solve their own problems rather than relying on or blaming the process.

The second form of control contributing to heat death is the absence of guidance.  Everyone practices agile as and when they see fit. This a gray goo scenario in the number of techniques and approaches multiply until the agile movement inside an organization fades into oblivion. Laissez-faire leadership styles often allow individuals and teams to make their own decisions with little to no guidance.  While on the surface this type of management style seems conducive to self-managed and self-directed teams, without some form of guidance teams and individuals can wander far afield, which makes working together difficult. Here again, a loose framework with a set of principles and coaching can be leveraged to provide guidance. Having a framework also provides teams (or individuals) a platform to test their ideas or approach against before making a larger change that might hurt the organization.

Agile leaders care about control and how it is applied because it reduces an organization’s ability to dynamically change and be predictable. The trick is how much control to apply; too much and we get heat death and too little and its gray goo time. Predictability allows leaders to have at least a rough answer to the ‘when’, ‘how much,’ and ‘what’ questions that find their way into discussions with stakeholders and sponsors. Predictability is a precursor for introducing the subject of continuous improvement.  Trust is as important as predictability. Trust cannot exist when words don’t match actions (or are so nebulous as to be irritating). I was once asked by a software development firm I worked for to develop a course to explain to sponsors and stakeholders why “we” could not confidently tell them how much the work they want would cost or when we would deliver their request. This was even though we had a highly defined agile software development process with a change board to monitor usage. The level of control was not conducive to adapting work to the nuances of context faced with every customer. In the end, I tried to explain (with the support of the sales manager) why that presentation was probably not going to be helpful as part of the sales cycle. In response to what I perceived as a clear and present danger to my career, I found another job and I was not shocked when later I was told that the firm collapsed due to lack of clients. We had failed to find the balance between control and letting the teams do what they wanted to do.  

 

The answer back to the future (next)

Cooling before winter!