The Agile Dichotomy

WARNING: There is an immense dichotomy in agile, and it is infiltrating companies throughout the world! C-Suite executives perceive agile adoption as a means of delivering quality software solutions faster for customers and business partners. Whereas, engineering teams point to the cornerstone principles of the agile manifesto, especially, the emphasis on delivering working software.  The obvious problem here is that delivering working software in no way means that software solutions will be produced faster.  Hence, the dichotomy is between corporate executives who interpret the Agile Manifesto as promising something for nothing, whereas the engineering organization is focused on strategies that mitigate risk, reduce project failures and ultimately benefit the engineers.  The fundamental problem is that C-Suite executives need to justify the cost of their agile initiatives to their investors.  There is a significant bottom-line cost to transition to agile and stakeholders are interested in the return on investment for the "Agile Adoption" thingy that the company is spending so massively to adopt.  

In concept, Agile adoption may lead to greater velocity; however, it is noteworthy that the word "velocity" appears nowhere in the agile manifesto.  There are also 12 principles that the Agile Alliance adopted and  "velocity" is not found amongst those principles.  The principle that most closely suggests anything that may be interpreted as "velocity" is the following principle:

Simplicity--the art maximizing the amount
of work not done--is essential.

This notion of simplicity is anything but simple.  There is tremendous art in simplicity. By analogy, simplicity cannot be achieved by simply speeding up a conveyor belt.  Each of the tooling stations in the assembly line must be capable of adapting to the underlying velocity.  Perhaps we can eliminate or combine assembly operations to improve the efficiency of the product assembly?  In some cases this is feasible, but in software engineering, removing steps from the process can be catastrophic.

There is an underlying premise that much of the assembly-line process can be automated to ensure that the software is produced more efficiently and that less work is done to achieve quality software.  But will this result in greater velocity, and is that velocity improvement quantifiable?  This is an important question!  

Thus the dichotomy between Executives or managers and software engineers may persist for a very long time, thus undermining the agile adoption.  This dichotomy is insidious and even dangerous to the adoption of agile. In fact, all of the questions that surround agile adoption must be vetted within the teams within an organization that have decided to adopt agile.  We must ask the following questions as well:

1) What operational processes within our organization tend to derail agile adoption?

2) What organizations have successfully adopted agile and what choices helped  in their adoption?

Finally, we need to consider this question: 

Does agile actually produce velocity, or higher quality software or both or neither? 

If it doesn't produce velocity, is there still a value proposition for agile adoption? If it doesn't produce higher quality software is there still a value proposition for agile adoption? If this analysis appears as syllogism, it is not trivial or wasteful.  Agile adoption must be done with stated objectives and the adoption must adhere to the identified set of objectives.  Otherwise, what priorities shall we use to guide us in determining how exactly to maximize the work not done? A bottom-line question is: How can we measure if agile adoption is successful? Only if we have a specific criteria for success can we tune agile adoption to meet the success criteria.