Pitfalls using Agile

Fail to address domain core problems – do not cover core capability: adaptive & lean (with undesired results as slowness, low quality, expensive). Example: if your product is fragile, rigid and have a lot of technical debt (a symptom for Flaccid Scrum), there is no way to be Agile, and there is no way to have a good software economics. Example: if there is no collaborative work, there is no room for process improvement.  The first step toward a solution is to develop core capabilities around Agile Core Practices (as the ones recommended by XP and DA, beyond Scrum offer).  

Fail to address context problems – each context could have different kinds of risks and problems. The main pitfall is to copy-paste the process from one context to another. That is a common risk when are used “prescriptive” methods, with too few guidance for tailoring.  Example: we cannot copy-paste a process from a product with a lower complexity to another one with a bigger complexity. Example: releasing a whole new product is very different that a small release with a delta for an existing product. Example: An Agile scaling approach that does not have options per context.

Too small set of practices – When teams are relying only on practices existent in lightweight methods (as Scrum or XP), and the rest process has severe skill gaps or, it is too ad hoc. So, both domain and context problems could not be addressed well.  You cannot excel in managing software development only with 10-15 practices.

“Modernization” by dilution – any approach could evolve, but regression it is also possible. There are many attempts to modernize or enhance or “scale” Core Agile (Manifesto and Core Agile Practices). Everything is fine if the agility itself it is not diluted until disappearance. Any enhancement is good if will address the domain and context problems and offer responses for core needed capabilities: adaptive-lean and tailoring /context. 

Recommended readings

The Land that Scrum Forgot, by Robert C. Martin

• https://www.scrumalliance.org/community/articles/2010/december/the-land-that-scrum-forgot

 Flaccid Scrum, by Martin Fowler

• https://martinfowler.com/bliki/FlaccidScrum.html

Agile support for context problems

Many of the domain or context problems will be directly solved by Core Agile (Manifesto and Core Agile Practices). However, some of the problems cannot be addressed only with Core Agile or even with non-core Agile practices. 

What is the Agile response for adapting to context? 

 
The possible problems are induced by context related perturbation/scaling factors. 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 directly backup Manifesto values and principles
• Description of main Scaling/Tailoring Factors 
• Guidance for  process tailoring in Context
  

Manifesto response – it has an indirect response: if you manage very well generic domain problems, you will maximize the remaining resources to address the context. Also, the generic development strength will be high.

Methods responses – each method try to address in some way the “adapt to context” problem. Their solutions are, anyway, quite different.

Scrum response – Scrum offer a very lightweight framework, with very few practices. For the rest of the process, it is supposed that teams/organizations will figure out what they need. The only guidance in the basic Scrum are the main principles: Transparency, Inspect and Adapt. Some Scrum extensions try to manage (only) the size scale factor.

XP response – XP offer a lightweight framework and a good coverage in overall Core Agile Practices. That mean XP is effective/efficient for solving core domain problems. What about context? Here are some XP solutions for context:

• XP recognize Scaling Factors (beyond team size)
• Offer some very short, but good guidance for dealing with the scaling factors
• XP main support for scaling it is its robustness and resilience on solving the core domain problems
• Recently Kent Beck describes its refreshed experience with software at scale: You Aren’t Going to Need It (YAGNI) could become, at scale, “You Are Going to Need It” [b8].

Scaling XP, Conclusion: “With awareness and appropriate adaptations, XP does scale. Some problems can be simplified to be easily handled by a small XP team. For others, XP must be augmented. The basic values and principles apply at all scales. The practices can be modified to suit your situation.” [b1]

Disciplined Agile Response – DA offer support for both aspects: a lightweight core of principles/practices /guidance to address the domain specific problems (as XP does), plus a guidance about how to adapt to context by offering a map of choices from important software engineering practices. In addressing core domain problems, DA add some few outstanding practices (as Agile Modeling practices) to core XP and Scrum, making the adaptive/lean support much more robust. In addressing the context problems, DA choose to offer guidance and not recipes:

• DA explicitly describe Scaling Factors
• Offers robustness and resilience on solving domain core problems
• Offers process tailoring guidance: options available per decisions points per generic process goals
• Offers Agile life-cycle options: basic, continuous delivery, advanced lean, exploratory lean startup
• Offers enterprise aware guidance: linking solution delivery with DevOps and Lean Enterprise.

Remember that Enterprise aspects are always part of the context and need to be addressed.     

Free-methods practices – there are outstanding Agile practices that are not part of the methods such as Clean Code, Clean Architecture, Adaptive Programming (Law of Demeter) that offer support for both domain generic and context problems. 

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:  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] Clean Coders series, by Robert C. Martin

[b5] Scrum Guide, EN version only - http://www.scrumguides.org/

[b6] Interview with Kent Beck, by Andrew Binstock – Java Magazine November December 2016

[b7] Agile Software Development: The Cooperative Game, Second Edition, by Alistair Cockburn, Addison Wesley Professional, 2006

[b8] Making Your Methodology Crystal Clear and More, by Alistair Cockburn

• http://alistair.cockburn.us/get/3606