Command and control in software development ? Divide by zero !

<sup>command and control - The exercise of authority and direction by a properly designate commander over assigned and attached forces in the accomplishment of the mission.  Also called C2.

That is a quote from DOD Dictionary of Military and Associated Terms, see this link.</sup>

^{Any endeavor will have an authority, a direction, and the forces. The key is that you can do that in many ways, Even in the military field you have options: a commando team will have another approach than a regular army platoon. Authority .. could result from a collaborative way of taking decisions. Direction should be the subject of adapting to context changes (could be very fluid for commando troops, for example).}   

<sup>Software development domain traits suppose contexts with high complexity and high incertitude. From math perspective that is a complex problem. For such problems we have only feedback based solutions. "By definition" you will need an approach that is adaptive, lean and that will be adapted to the context.  It is our choice to call this approach Agile (.. or not).

At a first view, Agile will solve the small parts (see Uncle Bob blog post In The Large; ... where I do not agree with <We, humans, are actually very good at building big projects>, and my post it is a kind of answer). Anyway, somehow we will always need to address also large problems: even with small releases, we will finally need to build and change and products that could be significant and large. The solution is not dummy, is not Flaccid Scrum ~ just adopting iterative development and basic collaboration. We could add (whenever is possible) small releases. We can add  <Agile engineering practices> such TDD.  We could also adapt our process to the context.</sup>

^{It is that enough ? What is the big picture ?}

^{We need to apply feedback-based "control" to all levels of the development. We need to balance the look-ahead approach with the just-in-time approach. Here is a proposed (Information Rolling Wave) model. A command and control approach with too few feedback for solving complex problems will suppose - concrete mathematics - division by zero. So, here is how will sound a too few feedback command and control approach to software development:}    

^{"I command you to divide by zero ... and then I will control you" :) :)}

What IS Agile, that is the question (essay)

AGILE MANIFESTO, FIRST DEFINITION - Agile was defined with this name in the Agile Manifesto, which was born from already existent experience, practices and methods. 

AGILE INVENTORY - briefly and simplified:

• Agile Manifesto
• Other manifestos and principles  
• Agile Methods, with contained practices 
• Agile Practices, where many of them are not part of any method
• ... and many other software engineering practices that could be aggregated in an “agile process”  

WHAT IS AGILE, THAT IS THE QUESTION - what is the meaning of this concept? “Agile” it is an interesting name, but it is not self-explaining.  Exploring the Manifesto and the “agile inventory”, we can give the first part of the answer.  Agile it is a process approach considering these aspects:

• Target domain:  software development
• Domain problem & traits: incertitude and changes, complexity, knowledge work
• Agile promise, from the Manifesto: software professionals has discovered “better ways” to address domain problems and traits

WHAT IS THE CONTENT OF AGILE PROMISE? The meaning of a process approach result from the capabilities for addressing domain problems and context problems, where capability supposes both understanding and deliberated practice. Which are capabilities provided by Agile?  Which is the Agile Promise?

AGILE PROMISE
The Manifesto explicit promise: to address software domain by “better ways” discovered “by doing it and helping others do it”, where its values and principles express HOW we can get these better ways.  From the start, Manifesto backup its promises:

• Conceptually – by its values and principles
• Concretely – by methods and practices that already exist at manifesto time 

The Manifesto implicit promise, included in values and principles is to provide these capabilities: 

• Adaptive – ability to respond to changes: quickly, often, even to late changes and continuously
• Lean – efficient, no waste 

 

The first step in being effective in software development is to be Adaptive. The first thing to be efficient is to be Lean.  Agile definition is Adaptive + Lean? It is not a simple answer.
Adaptive, not Lean:  that mean if I can respond to changes very well, but I have some sources of waste. It is possible to be adaptive with such source of wastes: defects, waiting, rework? It is possible to be adaptive using big pieces of work, in a domain with such complexity and incertitude?  No. it is not 

Lean, not Adaptive: Efficient process, but too slow to respond to changes. That is finally a waste.

Agile means

the capability of being adaptive while being lean &

the capability of being lean while being adaptive.

Agile means Adaptive-Lean.

THE SECRET OF AGILE – in a domain as software development you cannot really be adaptive without being lean and you cannot be lean without being adaptive. You cannot be adaptive without addressing complexity (both inherent and undesired), so you must be lean.  You cannot be lean without addressing incertitude, so you must be adaptive.  So, for software development domain, you must be Agile! You can be also something else, but you should care about agility!

 

A good software development approach need to be also Adaptive-Lean (Agile)

 

WHAT and HOW - What is the Agile promised capability and How it is realized? When people talk about Agile, are referring mostly the How part (explicit in the Manifesto): working software/iterative, people & interaction, test driven development, small releases, good design, retrospectives. “Responding to changes” (Adaptive) it is indeed an explicit What. Here is a larger view: Target & Problems/Agile What/Agile How:   

WHY AGILE? 

For domain problems: complexity, incertitude and changes, knowledge work,   
Agile as Adaptive-Lean capability 
having these means: people-oriented, iterative, adaptive, collaborative work, good design, lean validation, continuous improvement,
it is what works better. 

  

WHY CORE PRACTICES? - from hundreds or more valid practices in the software engineering, the main Agile contributors insist on the same similar set of common practices. There is a rather reduced set of practices that could provide the capability of being Adaptive-Lean. The same Core Agile Practices have an interesting trait: the same practice has multiple good effects/effectiveness in the process, and that is Lean!

THE 2^nd DARK SECRET OF AGILE – Tailoring to the context it is a forgotten aspect. XP describe the problem but does not offer enough guidance. Context needs Tailoring and Tailoring needs Guidance. And beware … 90% of valuable software engineering practices are outside Core Agile Practices and are necessary for context adaptation. 

THE 1^st DARK SECRET OF AGILE – too many teams that claim agility does not have the core capability to be adaptive, lean and steady. The root cause is the lack of the capabilities related to Core Agile Practices, especially for technical excellence. 

FULL EFFECTIVENESS – A full effective software development approach must provide capabilities to solve both domain problems and context problem. If domain main problems/traits – incertitude, complexity, knowledge work -  are solved being Adaptive-Lean (Core Agile: Values, Principles, and Core Practices), what about context problems?

WHAT IS AGILE SUPPORT FOR CONTEXT PROBLEMS?
Many of the domain or context problems will be directly solved by Core Agile. However, some of the problems cannot be addressed only with Core Agile or even with non-core Agile practices. The possible problems are induced by perturbation/scaling context factors. Typical problems: teams cannot apply Agile practices because of context constraints or you need to go beyond the 15-20 core practices to address the context.  

Expected response - I expect at least the following support from Agile and its methods:

• Support for Core Agile Practices, in order to backup Manifesto promises and generic domain problems
• Description of main Scaling/Tailoring Factors 
• Guidance for  process tailoring in Context

Manifesto address mostly the domain generic problems and not also the context.  Agile methods have different response/support for adapt to context problem (examples):

• partial support and only for Core Practices
• support only for size scaling factor (or for size and criticality) 
• very good support for Core Practices, scaling factors list, but no guidance for tailoring
• very good support for Core Practices, scaling factors description and guidance for tailoring

THE SWEET SPOTS VS CONTEXT
Alistair Cockburn said: “Part of getting to agile is identifying the sweet spots of effective software development and moving the project as close as possible to those sweet spots.” [b9]
When Core Agile does not fit to context, the first thing to try is to change the context to use Agile and, the second is to find other ways to solve the context beyond Core Agile (Adaptive-Lean).

MAIN PITFALLS IN USING AGILE

• Fail to address domain core problems
• Fail to address context problems 
• Dilution by some "modernization" attempts
  

You can read more here.

HISTORICAL DEFINITIONS OF AGILE - you can find some of the most interesting definitions of Agile here (from Agile Manifesto, Martin Fowler, Alistair Cockburn and Scott Ambler).


Bibliography and recommendations

[b1] Extreme Programming Explained: Embrace Change, Second Edition, by Kent Beck, Cynthia Andres, Addison Wesley Professional, November 16, 2004. Related sections

• Chapter 15 – Scaling XP (and Conclusion)
• Chapter 20 – Applying XP 

[b2] Disciplined Agile 2.X - A Process Decision Framework

• DA site -  www.disciplinedagiledelivery.com
• DA, Scaling Factors - http://www.disciplinedagiledelivery.com/agility-at-scale/scaling-factors/
• DA, The Software Development Context Framework - http://www.disciplinedagiledelivery.com/sdcf/

[b3] DA, Agile Modeling - http://www.agilemodeling.com/
[b4] Martin Fowler about Agile https://martinfowler.com/agile.html  
[b5] Scott W. Ambler About Agile http://www.agilemodeling.com/essays/agileSoftwareDevelopment.htm
[b6] Clean Coders series, by Robert C. Martin
[b7] Scrum Guide, EN version only - http://www.scrumguides.org/
[b8] Interview with Kent Beck, by Andrew Binstock – Java Magazine November December 2016
[b9] Agile Software Development: The Cooperative Game, Second Edition, by Alistair Cockburn, Addison Wesley Professional, 2006

• Chapter 5. Agile and Self-Adapting / Agile

[b10] Manifesto for Software Craftsmanship - http://manifesto.softwarecraftsmanship.org/
[b11] Disciplined Agile Manifesto - http://www.disciplinedagiledelivery.com/disciplinedagilemanifesto/