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 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) 


[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