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

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.

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)