Process alphabet: Core Agile Practices

Draft Version 

See also Process Alphabet

Intro

It is not a coincidence that most of the main Agile contributors are referencing almost the same practices. The secret behind these practices is to contribute to the Lean aspect of the process that strongly enhances agility: Core Agile Practices have multiple benefits at the same time and address some of the main sources of waste. Again, it is not a coincidence that XP is based on some of them (also referred by Mary Poppendieck / Tom Poppendieck in “Lean Software Development”), Scott Ambler enhances them in Agile Modeling, and Disciplined Agile call them “Critical Agile Practices”.

Expectation from a method

      Reference and coverage

• Referring to the CAPs as critical practices and provide good coverage

      Lean & Eliminate Waste

• Explain CAPs multiple-benefits and how will help you to eliminate waste

      Context Usage 

• How and when can be used in the context and in specific life-cycles

Copyright © 2018 Valentin Tudor Mocanu

How to … my custom process

Reference and coverage

• The main references are XP and DA (“Critical Agile Practices” and Agile Modeling Practices)
• XP is a great source, but some practices are not explicit. For example, we can deduce Just-In-Time requirements clarifications from On-Site Customer.
• You will need explicit Just-In-Time practices, as DAD Model Storming 
• Idem for Look-Ahead practices: Requirements Envisioning, Requirements Envisioning, Look Ahead Modeling ( explicit in DAD )

  

Lean & Eliminating Waste 

• The main references are XP and DA. Both are explaining the benefits, the principles and how these practices will help you to eliminate waste.
• Especially for the Lean aspect, the benefits will occur after real experience and mastering of these practices. You need to experiment with them, collaborate with your colleagues and get help and guidance.

Usage 

• Generic usage – XP, DA and Scrum, each method will explain usage according to their coverage.  Anyway, effective & efficient usage is not possible without explaining the benefits and context trade-offs.  
• Context-based usage guidance, with alternatives and tradeoffs it is provided by Disciplined Agile. For XP and Scrum this aspect is somehow out of scope. XP mentions a list of context Scaling Factors, recommends adapting, but does not provide guidance.

Core Agile Practices in Scrum

Reference and coverage 

• Scrum offers a reduced set of Core Agile practices and does not explain (in the main content) too much which are the benefits. 

Context Usage 

• This kind of guidance is provided only for included practices and guidance is not differentiated by context. 

What is missing? 

• Scrum is just introductory for this aspect. From a Shu Ha Ri perspective, Scrum's main content is limited to Shu beginning.  
  
  
  
  
  
  

  Source	Core Agile Practices	Used	Comments
  Common	Working Software	Yes	Only as Iteration/Sprints, not also for lean working software
  Common	Iteration Modeling, Iteration Planning	Yes	As “Sprint Planning”
  Common	Retrospectives	Yes
  Common	Small Teams	Yes
  Common	Daily meeting	Yes	As “Scrum meeting”
  XP	Small releases	No
  XP	System Metaphor	No
  XP	Simple design	No
  XP	TDD (Test-driven Development)	No (*)	(*) Not in the Scrum Guide, only in Scrum authors recommendations
  XP	Refactoring	No
  XP	Pair programming	No
  XP	Collective ownership	No (*)	(*) Not explicit
  XP	Continuous integration	Yes	At Sprint level only
  XP	On-Site Customer	Yes (*)	(*) As Product Owner
  XP	40-hour week	No
  XP	Coding standards	No (*)	(*) Organization (generic) standards must be considered for the definition of Done
  XP	Exploration, solution spikes	No
  DAD	Proven Architecture Milestone	No
  DAD	Requirements, Architecture Envisioning	Yes (*)	(*) Briefly mentioned, but not in the Scrum Guide
  DAD	Active Stakeholders Participation	Yes (*)	(*) Insufficient: only in Sprint Review and optional
  DAD	Look Ahead Modeling	Yes (*)	(*) As “Refining”, but is Too vague
  DAD	Model Storming	No
  DAD	Executable Specifications (TDD as ...)	No
  DAD	Consumable Solutions	No (*)	(*) “Potentially Releasable” is a similar concept, but too vague and not explained
  DAD	Rolling Wave Planning	Yes (*)	(*) Not so explicit: refining Backlog, refining before Sprint.
  Free	Clean Code	No (*)	(*) Outside of Scrum Guide, Scrum authors mention the need for good design.
  Free	Clean Architecture	No

  

Core Agile Practices in XP

Reference and Coverage 

• XP has great coverage for CAPs, where many of them have XP as the main reference

Usage & Lean guidance 

• There is guidance about the reasons, benefits, and usage of these practices. A good part of them are already grouped in the chapter “How Could This Work?” (first edition of the book). 

What is missing

• Context guidance is rather absent
• There are rather few missing core practices, but these are significant ones, as Just-In-Time clarifications about requirements and design.
• The two main XP books […] have great content, but the approach for describing the XP fundamentals can be confusing: some great things from the first are forgotten in the second edition and some guidance is changed.   
•  Some fundamental practices are explained but the authors do not use a name and it is harder to distribute the concepts (as Architecture Envisioning, explicitly in Disciplined Agile)

Source	Core Agile Practice	Used	Comments
Common	Working Software	Yes	As Iteration or Daily Deployment
Common	Iteration Modeling, Iteration Planning	Yes	Defining as being similar to  Release Planning
Common	Retrospectives	Yes (*)	(*)  As “Reflection principle”
Common	Small Teams	Yes
Common	Daily meeting	Yes
XP	Small releases	Yes	With great guidance
XP	System Metaphor	Yes
XP	Simple design	Yes	With great guidance
XP	TDD (Test-driven Development)	Yes	With great guidance
XP	Refactoring	Yes	With great guidance
XP	Pair programming	Yes
XP	Collective ownership	Yes	Collective ownership, but also "Whole team"
XP	Continuous integration	Yes
XP	On-Site Customer	Yes
XP	40-hour week	Yes
XP	Coding standards	Yes
XP	Exploration, solution spikes	Yes
DAD	Proven Architecture Milestone	Yes (*)	(*) In the first iteration, create "the whole system," even if it is in skeletal form.
DAD	Requirements, Architecture Envisioning	Yes (*)	(*) Does not have names but are mentioned. For requirements it only the option of using stories (usage aspect).
DAD	Active Stakeholders Participation	Yes (*)	(*) “Real customer involvement”
DAD	Look Ahead Modeling	Yes (*)	(*) Weekly
DAD	Model Storming	No (*)	(*) Pair programming it is considered, but just-in-time collaboration can go beyond a pair.
DAD	Executable Specifications (TDD as ...)	Yes (*)	(*) Implicit by detailing stories with customer functional tests.
DAD	Consumable Solutions	No
DAD	Rolling Wave Planning	Yes (*)	(*) Implicit: quarter, release, iterations, weeks, days
Free	Clean Code	Yes (*)	(*) Some significant practices are mentioned
Free	Clean Architecture	No

Core Agile Practices in DAD

Reference and Coverage 

• DAD has a great coverage for CAPs, where many of them have DAD as the main reference (or Agile Modeling part of DAD).  Agile Modeling was developed as an extension to XP so any XP practices usage is natural.

Lean & Eliminating Waste 

• There is detailed guidance about reasons, benefits, and usage for some of these practices.

Context usage 

• Usage it is described also in the life-cycle context: how participates to the process goals, which other options are available, and which are the trade-offs  

What is missing?

• My expectation is that in the future to be a clearer reference to CAPs as an integrated ecosystem and clearer visibility for all of them in the overall guidance (no method has that)

Source	Core Agile Practices	Used	Comments
Common	Working Software	Yes	Improved concept: “Consumable solution” with explicit guidance
Common	Iteration Modeling, Iteration Planning	Yes	Explicit guidance
Common	Retrospectives	Yes	Explicit guidance
Common	Small Teams	Yes	Explicit guidance
Common	Daily meeting	Yes	Explicit guidance
XP	Small releases	Yes	Improvement roadmap guidance – smaller releases
XP	System Metaphor	Yes (*)	(*) In a form of Architecture Handbook and Envisioning
XP	Simple design	Yes	XP reference and principle explained
XP	TDD (Test-driven Development)	Yes	Explicit guidance
XP	Refactoring	Yes	Explicit guidance
XP	Pair programming	Yes	Also extended with Non-Solo Development
XP	Collective ownership	Yes	Explicit guidance
XP	Continuous integration	Yes	Explicit guidance
XP	On-Site Customer	Yes	As a variant of Active Stakeholders Participation
XP	40-hour week/Sustainable Pace	Yes	Explicit guidance
XP	Coding standards	Yes	as “Development Guidelines”
XP	Exploration, solution spikes	Yes	Explicit guidance
DAD	Proven Architecture Milestone	Yes	Explicit guidance
DAD	Requirements, Architecture Envisioning	Yes	Explicit guidance
DAD	Active Stakeholders Participation	Yes	Explicit guidance
DAD	Look Ahead Modeling	Yes	Explicit guidance
DAD	Model Storming	Yes	Explicit guidance
DAD	Executable Specifications (TDD as ...)	Yes	Explicit guidance
DAD	Consumable Solutions	Yes	Explicit guidance
DAD	Rolling Wave Planning	Yes	Explicit guidance
Free	Clean Code	Yes (*)	(*) Explicit guidance about technical debt and significant practices are explicitly mentioned
Free	Clean Architecture	No (*)	(*) No restriction to use it

Subjective assessment

Here my subjective assessment for Core Agile Practices supports in Scrum, XP, and DAD, using the above process alphabet guidance.   

  References (draft) 

[SG2017] – Scrum Guide - https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf

[XPE1] – Extreme Programming Explained First Edition, By Kent Beck, Addison-Wesley, 1999

[XPE2] – Extreme Programming Explained: Embrace Change, Second Edition, By Kent Beck, Cynthia Andres, Addison-Wesley,  2004