Saturday, December 8, 2018

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 the 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 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 it is a great source, but some practices can be rather deduced, are not explicit. For example, we can deduce Just-In-Time requirements clarifications from On Site Customer. Anyway, that is not enough because you maybe also need inside team collaboration, so Model Storming DA explicit Just-In-Time practice is fundamental. The same logic could be applied to look-ahead practices: Requirements Envisioning, Requirements Envisioning, Look Ahead Modeling: in Disciplined Agile are explicit core practices. 
  
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 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 is somehow out of scope. XP mention a list of context Scaling Factors, recommend 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 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 of a good design.
    Free
    Clean Architecture
    No


  

Core Agile Practices in XP


Reference and Coverage 
  • XP has a great coverage for CAP, where many of them have XP as the main reference

Usage & Lean guidance 
  • There is guidance about 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 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 a 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 Participations
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