Sunday, October 23, 2016

Core Agile capability - responding to changes - with XP and DA

Core Agile Capability – responding to changes – it was stated by Agile Manifesto values and principles and has a primary backup a set of Core Agile Practices that already realize these principles at Manifesto time. Most of them were part of the XP – Extreme Programming (See [Biblio – XP1]):    
  • Small releases
  • System Metaphor
  • Simple design
  • Testing First Development
  • Refactoring
  • Pair programming
  • Collective ownership
  • Continuous integration
  • On Site Customer
  • 40-hour week
  • Coding standards
  • Exploration, solution spikes

The beauty of this initial set of core practices is that each practice will add multiple values and also will support the use of the others.  More: with this small set, we can backup the full Agile promise: a good and adaptive process with the capability to respond to changes: quick, often and even late in development.



What will we need more?

We can extend these practices to fill the possible gaps and/or make their usage more robust on achieving the Core Agile Capability – responding to changes. Please find above such extensions using the good help of Agile Modeling and Disciplined Agile practices.


Exploration, Solution spikes – extension
  • Proven-architecture milestone - solution main decisions are proven with an end-to-end exploration skeleton, based on spikes and other working code, early in the release construction
  • Multiple-models – develop and use skills related various techniques for explorations     
  • Requirements Envisioning, Architecture Envisioning – envisioning over requirements and solution it is what need to cover during the explorations and are necessary before Release Planning 


On-Site Customer – extension
  • Active Stakeholder Participation – we need to involve the customer beyond on-site participation: not all customer side stakeholders could be on site and there are also other involved stakeholders beyond customers. Also, this it is a more robust approach, that does not depend on a single product owner. Note: One of the first XP projects (C3 Project) had big problems because of “customer representative” bottleneck (see [Biblio – XP2]).  


Collective ownership – extension
  • Collective ownership it is not possible without spreading the knowledge and the skills around the team
  • In order to spread the knowledge around the team, some of the enumerated XP practices are very useful: Test-first encourage work and refactoring on others code by offering knowledge (tests as requirements specification) and a safety net for quality; Pair-Programming (and move people around) help a lot on information distribution; System-Metaphor – high-level information it is available to the whole team
  • Anyway, using only above enumerated practices we will not cover all the needs of spreading knowledge and skills inside the team. It is very important to involve the team members in key moments of the developments with other non-solo work practices: Envisioning, Look Ahead Modeling. More, Model Storming, opportunistically used, could cover the remaining gaps in both knowledge and skills
  • The DA Architect Owner, acting as a coach, can help making this collective ownership possible    

Refactoring – extension
  • For significant amount of Technical Debt, where Test-First is not available, we will need more help, in order to make refactoring possible
  • High Technical Debt usually comes together with missing knowledge about functionality, knowledge needed for tests (normal approach of "reading" the code is very hard). More: recovering this info from refactored code is difficult because debt hide buggy functionality (... and the recovered info it also distorted). We will need to involve others in order to validate this recovered info and DA practices could help: Model Storming – go beyond pairing and discuss with more persons from your team; Active Stakeholders Participations - discuss with customers, domain experts, and others.     


From Working software to Consumable Solutions
  • Working Software and Potentially Shippable as concepts and practices will help have the work Done in an incremental/iterative manner that is a fundamental condition for being adaptive and responding to the changes
  • Consumable Solution it is an enhanced/improved concept versus the above mentioned: product it is really Done if is consumable: functional, usable, and desirable to its end users.


TDD as Executable Specification
  • In fact, XP are using TDD as Executable Specifications but in is not so explicit in its intentions
  • In Scott W. Ambler, Agile Modeling and in Robert C. Martin work this intention was made clear and explicit
  • Executable specification and TDD can support the strongest Agile promises related to responding to changes       


Changes in product life-cycles
  • In XP books, Kent Beck has noticed that Exploration it is more important in the early period of the product life. Recently he makes that more clear in Explore, Expand, Extract concepts
  • Responding to change it is different during the product life (because of incertitude and complexity differences) and we should act accordingly. DA offer clear agile delivery life-cycles variants, that could be associated with these product life phases. A start example: when a product is born (and it is in its Exploration phase) we can use Exploratory (Lean Start-up Life-Cycle)  


Add other practices
  • There are other outstanding Agile practices like (Robert C. Martin) Clean Code and Clean Architecture that are fundamental to Core Agile Capability – responding to changes. With DA it is easy to include them in the team & product process
  • Example: Clean Architecture goal could be discussed in the Envisioning and also using various form non-solo work (Look Ahead Modeling, Model Storming) and then will become strong support for TDD (strategic testable design) 


Summary of Disciplined Agile/Agile Modeling mentioned practices:


Bibliography and references
Posted by at
Labels: , , , , , ,

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)