Monday, September 25, 2017

Modeling the process: Rolling Wave and Practices



WATERFALL MODEL - One-dimensional: use disciplines for both content and time in a waterfall-like sequence.

ITERATIVE MODEL - Two-dimensional: content and time are two distinct dimensions. We can work in one iteration in “parallel” for all disciplines.

AGILE MODEL (SIMPLIFIED) -  Compatible with the Iterative model, but introduce practices as basic “brick” for the content part. Practices have also a “parallel” distribution in time, many of them are repeating for each iteration. 

SCRUM MODEL  Content: only a small subset of Agile practices. Time: iteration only. Release it is rather out of scope (... and there is a gap between iteration and product backlog). See [B2].

XP MODEL - Content: contain a solid set of core agile practices & others (also recommends to address the scaling factors). Time: iteration and release milestones. Inside iteration: day, week. Beyond release: Quarter, Product Life-Cycle. See [B1]

DISCIPLINED AGILE MODEL - Enhance the XP model and offers more variants of lean and agile delivery life-cycles. Content: enhanced set of core agile practices and guidance to select industry from practices depending on context factors. Time:  offers more variants of lean and agile delivery life-cycles [B4]. We can obtain different forms of a Rolling Wave by adapting/selecting the practices and the life-cycles. Explicitly, DA recommend the Rolling Wave for planning and roadmaps, but implicitly the whole process description is based on rolling wave model: practices are distributed per different types life-cycles, where these practices are associated with process goals & decision points (not use the traditional activity-based viewpoint, that it is still valid, but not to describe too well the process structure) - see [B5].  
Why I expect from Disciplined Agile? To make more explicit the fact that use the Rolling Wave (with practices) model to describe the process.

“ESSENCE” MODEL – It is in some parts conceptually similar to Unified Process (Jacobson, one of the  “Essence” creators, was also one of the UP creators): it describes the process starting from activities. In also defines the practices as something that “provides guidance to deal with some dimensions of software development” [B3 – Chapter 17], and associates practices with an activity as “A requirements elicitation practice” [B3 – Chapter 17]. This model will not be so effective for Core Agile case, where each practice will contribute to more dimensions of development (and to more “activities” from traditional process description).
Another problem of the “Essence” is the definition of the method as a “composition of practices” [B3 – Chapter 18] (also Jacobson write/tweet about freeing the practices from methods prison). This definition it is incomplete for all the methods and for some of them it is inaccurate. Incomplete: all the methods are mentioning first some principles and only then the practices. Also, some methods have explicit description of development life-cycles. So, we have at least principles, practices and possible a life-cycle. More, in the case of Disciplined Agile, we cannot describe that method as a composition of practices, because beyond the recommendations of some Core Agile Practices, DA it is mainly a guidance to compose a kind of custom method in a specific context by selecting from the industry practices.  

SPECIFIC AGILE CONTENT: CORE PRACTICES - Core Agile Practices have a specific Lean trait: one practice has multiple benefits, in various content aspects. These practices cannot be classified inside one discipline: design, implementation, testing etc. Modeling the content by encapsulating one core practice inside one discipline is a deeply misunderstanding of Agile.

INFORMATION RELATED WORK: ROLLING WAVE - In software development, the work it is mostly related to information: we gather information, build information, we distribute, validate and get feedback about information. The progress of this work could be modeled as a Rolling Wave. The wave could address high granularity aspects as product roadmaps and release, medium granularity aspects as iterations and days, or low granularity aspects as TDD or Pair Programming. We cannot separate these levels because are influencing each. 

ROLLING WAVE -  Rolling Wave is not only about planning or milestones, buy about how the information related to the work and its results evolve or could evolve:
  • The problem - Understand and clarifying the problem to solve
  • The solution – prove your solution iteratively
  • Risks – resolve the associated risks in decreased impact order
  • Generic development aspects: knowledge, complexity, incertitude
It is a wave of information that could be gathered, created, distributed and validated (via feedback). Our process it is effective and efficient if we apply the “right wave” model in our context.  Waterfall propose an unrealistic model about the wave: gathering and building up front and precisely a lot of information. That it is mathematically impossible: complex problems can be solved only via repetitive feedback, and these kind of problems have rather a short range of prediction.  Iterative model and Agile have introduced many feedback based practices as: small releases, iterations, retrospectives and continuous integration.   
Important: any model process propose kind of rolling wave, but only in Disciplined Agile, this model it is explicitly used, where also the process guidance follow this model.

ROLLING WAVE - EXTENDING THE DEFINITION

Standard definition for "rolling wave planning" is <<plan things that are near in time to you in detail and things that are distant in time at a higher level>>. Practically, we will always have a rolling wave: we will always know less about the distant time things, no matter what it is our wishful thinking or not. 
Extending the definition, we will always have a rolling wave and the rolling wave it is applied also to the execution of the plan. The real model of a process suppose continuously enhancing the information and knowledge.   

ROLLING WAVE AND CORE AGILE PRACTICES

Core Agile Practices have a fundamental contribution to rolling waving the work, where their multiple benefits (per practice) will address many aspects related to the main domain issues: complexity, incertitude and knowledge. Each of these practices has multiple contributions in information-based work to: create, gather, distribute, slice, validate (and get feedback) information.  That mean we can have a feasible, effective rolling wave/work.      
You can find more information about their contribution in the post Core Agile Practices and Rolling Wave process model. Some of the Core Agile Practices: Small Releases, Iteration, Retrospectives, Pair Programming, Envisioning, Look Ahead Modeling, Just in time modeling, Continuous Integration, Clean Code

THE RIGHT ROLLING WAVE

We have two main drivers to build/adapt the right rolling wave:
  • Domain specifics - the problems that are specifics to software development domain.
  • Context specific – the problems that are specific to our context
Domain specifics: Core Agile Practices will allow to build an effective & efficient rolling wave.
Context specific: We need guidance to select/adopt the proper practices and guidance in context   

THE RIGHT PROCESS MODEL

The right process model:
  • Will be represented as a rolling wave, with practices distributed in a life-cycle 
  • Will consider the adapt to the context : will be a specific rolling wave with life-cycle and specific practices. We will need guidance to be effective/efficient in this adaptation.  
  • Will consider also the Core Agile Practices - whenever it is possible - in order to increase adaptability and leanness
A good example for distributing practices in the life-cycle is usage of process goals and decision points used by Disciplined Agile.  


Bibliography and References


[B1] Extreme Programming Explained: Embrace Change, Second Edition
  • By Kent Beck, Cynthia Andres, Addison Wesley Professional, November 16, 2004
[B2] Scrum Guide
[B3] The Essence of Software Engineering: Applying the SEMAT Kernel, Addison Wesley 2013, by Ivar Jacobson, Pan-Wei Ng, Paul E. McMahon, Ian Spence , Svante Lidman
  • Chapter 17 – Zooming In to Provide Details
  • Chapter 18 - Reaching Out to Different Kinds of Development
[B4] Disciplined Agile –  Full Delivery Life Cycles (agile and lean)
[B5] Disciplined Agile –  Rolling Wave related articles
[B6] Disciplined Agile –  Process Goals




Core Agile Practices and Rolling Wave process model



Core Agile Practices have a fundamental contribution to the rolling waving the work, where their multiple benefits (per practice) address many complexity, incertitude and knowledge aspects. 
Each of these practices has a contribution in information-based work: create, gather, distribute, slice, validate (and get feedback) information.  That mean we can have a feasible, effective rolling wave/work.      

Here are some examples.

Small Releases – key role – reduce the overall size of the wave. Transform a big wave (big release) in more smaller waves. Fundamental on dealing with complexity, incertitude and knowledge management. Affect all other aspects. Most important feedback loop is deployment and working in production. See [B1]

Iterations – similar with small release: slice the work, make the work easier. Slice the release and advance with validated releases and feedback.

Retrospectives – Apply feedback on all aspects of the work: correction and improvement feedback loop.

Daily meetings – slice the work more and make the day a unit for coordination and feedback. 
  
Pair Programming – build better product (information), good and in-time feedback, distribute knowledge.  Multiple roles on low granularity parts of the information rolling wave.  See [B1].

Solution Spikes & Proven Architecture Milestone – eliminate risks related to the solution giving a real progress of the wave. See [B2].

Envisioning – initial release look ahead. Big up front initial wave it is not feasible, but an envisioning (requirements, solution and others) it is useful and pragmatic.  Whenever it is based on solution spikes will be better. See [B2].

Look Ahead Modeling – fill the gaps between envisioning and iteration modeling. Prepare the iteration modeling. Fill the gaps between iteration modeling and just-in-time. See [B2].

Model Storming (Just in Time modeling) - When information gathering/creating or validating become accessible and whenever it is necessary. See [B2].

Active Stakeholders Participation – involve and collaborate with the stakeholders in the whole life-cycle. You cannot rely only in a Product Owner approach if you want a robust approach on gather/build and validate the rolling wave information. See [B2].

TDD (Test Driven Development) – similar benefits with Pair Programming: better product, in-time feedback and validation, distribute knowledge as Executable Specification. See [B1], [B2].

Continuous Integration – working software produced with small granularity/cycles. That mean ones of the feedback loops are very short and the whole rolling wave will be more robust. Usually suppose that many other Core Agile Practices are in place (such TDD, Model Storming, Pair Programming, Solution Spikes)

Consumable solution – it is a much strong condition than just working software for validating the work and the rolling wave evolution. See [B2].
Clean Code, Clean Architecture – these set of practices are enabling TDD, refactoring and effectively, efficient product change (rolling wave progress).  Also, CC and CA are enabling information low complexity and easy distribution. See [B3], [B4].

Important – any of these practices have multiple contributions to a pragmatic, effective, efficient rolling wave of work/information.  Eliminating one of these practices could cause serious problems and a much significant effort. If you want to improve your process in context you will need guidance about how practices could be distributed in the life-cycle using process goals and decisions points,

Read also


Bibliography and references


[B1] - Extreme programming explained: embrace change, Kent Beck, Addison-Wesley Professional; US ed edition (October 5, 1999). Note: I strongly recommend this first edition for understanding Core Agile, over 2004, 2nd edition.   
[B2] - Agile Modeling
       www.agilemodeling.com
[B3] - Disciplined Agile: Prove Architecture Early
-        http://www.disciplinedagiledelivery.com/prove-architecture-early/
[B4] - Clean Code, Prentice Hall, 2008, by Robert C. Martin
[B5] - Clean Architecture, Prentice Hall, 2017, by Robert C. Martin