Sunday, December 23, 2018

Process Alphabet: Information Rolling Wave

Draft Version 2

 

Intro


Life-cycle, practices, context, delivering value - all must fit together in our information rolling wave. Our subject of work is the information that is gathered, analyzed, produced, validated and used. Looking ahead and feedback dimensions should be both represented for all disciplines and all timing levels by appropriate practices   

Expected support from a method


·        Information states
  • Motivation: our primary work object is information and progress should be associated with specific states for “crafted” information
  • Subjects of states: requirements, design, implementation, working software, solution & its parts, etc
  • Types of states: conceptual, feasible, ready, done, consumable, production-ready etc
  • Most important: Waterfall considers states per each discipline, where for iterative & agile consider the main states must be consolidated at work level. Work items should be based mostly on working software and the progress should relative only the realization of Consumable Solution.
·        Adapt to Context
  • Roadmaps & Life-cycles - Motivation: we need a high-level evolution shape for information that we gather and produce
  • Process Goals - Motivation: across the life-cycle, we shape the information wave around process goals
  • Selecting practices - Motivation: we need to make the optimum decision in context ~ selecting the right practice. For selection, we need a library of practice and guidance about the tradeoffs of using different practices. Practices will shape our information rolling wave. TDD example: offers a direct trace from requirements, test cases and realization, an explicit & quick validation; by adding/removing TDD, our information rolling wave could change dramatically: from one-month potential release to one day or less.    
·        Collaboration
  • Motivation: Knowledge work has collaboration as a core component: people are the most important “repository”, “processor” and “channel” for information management. Collaborative work dramatically changes and improve the information rolling wave
  • Types of collaboration: Inside team, between development teams, between development teams & other teams
·        Core Practices shaping the rolling wave
  • Motivation: we need to give special care to practices that shape the information rolling wave, the ones related to Looking Ahead and to Validation & Feedback. We can dramatically optimize the work if we can use the Core Practices related to these aspects.
  • Look-Ahead practices: envisioning, look ahead, just-in-time
  • Validation and feedback practices: from reviews to automated tests
© Copyright Valentin Tudor Mocanu 2018
Rolling Wave in Scrum

·        Information states
  • Explicit state for work item at iteration level only: ready, done
  • Rather vague guidance for ready and done
  • Potentially Shippable concept does not explain well all aspects of a Consumable Solution
  • No states at the life-cycle level    
·        Roadmaps & life-cycles
  • See Process Alphabet: Life-cycles
  • Roadmaps - Product Backlog can be used as a development roadmap, but no other explicit support for roadmaps, life-cycle, and life-cycle types
·        Adapt to context
·        Collaboration between development teams
  • Scrum basic has nothing
  • Scrum core-extensions (from Scrum creators) offer only Scrum of Scrums option
·        Collaboration with other teams
  • Very short guidance about direct customer collaboration
  • Nothing about collaboration with other enterprise teams
·        Selecting practices that shape the rolling wave
o   Prescribed practices, without options
o   Only iteration, iteration meetings, daily meeting, product backlog, and product backlog items.
o   Looking ahead – vague description as “refining”. 
o   Too few guidance for envisioning and no guidance for just-in-time practices
·        Selecting practices for continuous validation and feedback
o   Prescribed practices, without options
o   Too few: iteration-level only + daily meeting. No just-in-time practices and no info about automatic tests, continuous integration, continuous deployment

Scrum advantages
  • Scrum allows and recommends (not explicit) to add other practices when do not displace its prescribed practices. Anyway, does not provide guidance for that
What is missing
  • You cannot replace Scrum prescribed practices (and still doing Scrum)
  • Continuous Delivery and Lean life-cycles with very small iterations are not supported by Scrum. Information rolling wave and validation ceremonial in Scrum has much higher granularity, starting at week level. Note: you can modify a Scrum based process to support these life-cycles, but the result it is no longer Scrum.
  • No support and guidance for low granularity validation and feedback that contribute to the effectiveness of “Done”
  • Progress toward a Consumable Solution has not enough support
  • Very few guidance in general and no guidance about full, end-to-end life-cycle rolling wave model  


Rolling Wave in XP


·        Information states
  • Explicit state for work item as a whole: ready and done (working software, integrated and tested by default)
  • Work envisioning at release/iteration level in release/iteration planning
  •  State of the product:  exploration, first release, maintenance
  • Progress toward a Consumable Solution is not so explicit, excepting the working software part 
  •  Feasibility & pragmatism of the states
    • Short releases with short and often internal cycles – offer pragmatism to the states
    • Product built-in quality
    • Simple Design avoids complexity & irrelevance of states
·        Roadmaps & life-cycles
  • See Process Alphabet: Life-cycles
  • Roadmaps: short guidance about product life-cycle: exploration, first release, maintenance and short guidance about quarterly planning 
·        Adapt to context
·        Collaboration between development teams
  • Very short guidance: “integrate frequently” and planning could help
·        Collaboration with other teams
  • Guidance about direct customer collaboration: On-Site-Customer and Real-Customer Involvement.  Nothing about collaboration with other enterprise teams
·        Selecting practices that shape the rolling wave
  • XP has a significant part of this kind of core practices: small releases, envisioning, iterations, weeks management, daily meetings, pair programming, TDD, continuous integration
·        Selecting practices for continuous validation and feedback
  • XP has a significant part of this kind of core practices: small releases, iterations, weeks management, daily meetings, pair programming, TDD, continuous integration, the whole team, informative workspace 
XP advantages
  • XP is fundamental guidance for managing the rolling wave: fundamental principles, values, and core practices. For some of them, XP is the main reference.
  • Great examples of how principles drive practice selection
  • Offer some process goals descriptions, especially for Inception
  • There are no incompatibilities between XP and any kind of rolling wave approach. XP strongly recommend some core practices but also tell the teams to discover what works for them   
What is missing
  • No explicit process goals beyond inception (goals ~ basic support for tailoring)
  • No real tailoring support, too few references about other options and practices beyond XP
  • Not enough guidance for roadmaps, and no explicit options for more Agile/Lean life-cycles (while implicit support and some useful references exist)
  • Progress toward a Consumable Solution has partial support 


Rolling Wave in DA


·        Information states
  • States are defined primarily at work level (iterative/agile/lean approach)
  • Life-cycle light milestones ~ real advance of the work state to the result, a Consumable Solution
  • “Ready” is a clear result of an iterative result of conception, envisioning, looking ahead, just-in-time modeling
  • “Done” is clearly defined as an advance to “consumable solution” with no debts, often feedbacks and validations at all needed levels: life-cycle, iterations, days, day or lower
  •  Integrate often - Continuous integration full cycle, daily if is possible;  
  • Continuous deployment
  •  A pragmatic and feasible approach
    •  Risks are shifted left
    • Decisions are shifted, not right, but to most appropriate moment, balancing looking-ahead with just-in-time
    • Short releases with short and often internal cycles ~ relevant states
    •  Built-in quality
    • Enhanced “Simple Design” - Barely Good Enough - avoids complexity & irrelevance of states
  • State of the product: enhancing the MVP concept & life-cycles evolution in the product life
·        Roadmaps & life-cycles
·        Adapt to context
·        Selecting practices that shape the rolling wave
  • Almost all core practices and reference to many others
  • All XP and Scrum options are referenced or can be used
·        Selecting practices for continuous validation and feedback
  • Almost all core practices and reference to many others
  • All XP and Scrum options are referenced or can be used
·        Collaboration between development teams
  • Guidance for large agile teams (team of teams)
  • Guidance for communities of practices
·        Collaboration with other teams
  • Significant guidance for the collaboration flows with DevOps, IT and Enterprise level teams
DA advantages 
  • in DA you can find almost anything you need to shape your Information Rolling Wave for your custom process, including the ones derived from XP or Scrum.

How to … my custom process


Information states
  • Scrum users – you cannot rely just on iteration & work item states with very vague guidance. 
  • XP users – you have some great guidance, but is incomplete
  • The main recommendation is to use DA guidance to adapt your method and your process to what you need.
  • Life-cycle milestones – use first DA guidance for Agile Basic Life-Cycle (later try to improve to more advanced life-cycles)
  • Ready – use DA guidance about the roadmap trough concept, vision, looking ahead and just-in-time modeling
  • Done – use XP and DA core practices that support Continuous Integration, Continuous deployment 
  • Consumable Solution - use XP and DA guidance for working software and complement with DA guidance about progress toward a Consumable Solution
  • Shift the risks to the left of the life-cycle (milestones, ready, done)
  • Balance looking ahead with just-time for optimum way to take decisions
  • MVP – use XP and DA guidance
  • Feasibility & pragmatism - use XP and DA guidance for often delivery, built-in quality, and simplicity
  • Build-in quality – if your product has technical debt, the root cause it a deteriorated, messy information inside the product
Roadmaps & life-cycles
Adapt to context
Selecting practices that shape the rolling wave
  • Complement Scrum and XP with other needed practices
  • Do not forget practices for: roadmaps, envisioning, looking ahead, just-in-time reactions
Selecting practices for continuous validation and feedback
  • Complement Scrum and XP with other needed practices
  • Use DA to gradually adopt practices for Continuous Integration, Continuous Deployment
Collaboration between development teams
  • Use DA guidance for large teams/ team of teams and for Communities of Practices
  • Use DA guidance for communities of practices
Collaboration 
with other teams
  • Use DA guidance for the collaboration flows with DevOps, IT and Enterprise level teams

References (draft) 



Saturday, December 22, 2018

Proces alphabet: Adapt to Context

Draft version  

See also Process Alphabet

Intro


The diversity of any real process goes beyond the reduced set of practices of Scrum and even beyond Core Agile Practices. In fact, a process is rather based on parts of Scrum/Core Agile Practices in order to optimize the work. Using practices from Agile methods (Scrum, XP) is always the subject of some amendments:
  • Different teams working on different products and in different contexts are facing different challenges and their process needs to be adapted
  • Core Agile Practices and agile practices, in general, does not cover all the process aspects
  • Some context scaling factors can make practices outside the Core Agile Practices the most useful in context. Or we will need to complement agile practices with others
  • Existent team skills do not include needed Core Agile Practices (as TDD)
Scaling factors
  • mentioned by XP: Number of people, Investment, Size of the entire organization, Time, Problem complexity, Solution complexity, Consequence of failure. [ See…]
  • mentioned by DA: Team Size, Geographic Distribution, Organizational distribution, Compliance, Domain complexity, Technical complexity.
Example:
  • In the case of Geographic Distribution, Organizational Distribution the highly desirable face-to-face conversation cannot be used on a large scale and should be replaced


Expectation support from a method

  • Support for Core Agile Practices, in order to directly address Manifesto values and principles and optimize the work. Core Agile Practices context is the software development domain in general, but any real case will have also a specific context.
  • Description of main Scaling/Tailoring Factors
  • Guidance for process tailoring in context:
    • how to select use life-cycles
    • context-agnostic process goals per life-cycle
    • selecting practices per process goals in the context
    • library of practices
© Copyright Valentin Tudor Mocanu 2018


Adapt to Context in Scrum




Support for Core Agile Practices

  • Reduced
  • See more on Process Alphabet: Core Agile Practices.
Support for Scaling Factors

  • Reduced
  • Some Scrum extensions try to manage (only) the size scale factor.
Guidance to adapt to the context

  • Reduced
  • Life-cycle selection: not available
  • Process goals coverage: only some Construction goals
  • Selecting practices in context – not available. Scrum it is prescriptive regarding its own practices. The only guidance in the basic Scrum is rather vague and it is based on the main principles: Transparency, Inspect and Adapt, where Inspect and adapt are related directly only to Scrum Meetings and Scrum iterations (Sprints)
  • Library of practices: not available
Comment
  • Beyond prescribed practices, Scrum allows to use any necessary other practice and let the team decide. Unfortunately, there is a very common misunderstanding (caused by bad coaching or missing knowledge) that Scrum by itself is the whole process. That is clearly specified as being false by Scrum authors. Their intention was to create a lightweight framework that is generic because does not have to cover the whole process and could be adapted


Adapt to Context in XP


Support for Core Agile Practices


Support for Scaling Factors

  • Partial: good, but very short about how to react to the scaling factors
  • XP acknowledge more scaling factors beyond the team size: Number of people, Investment, Size of the entire organization, Time, Problem complexity, Solution complexity, Consequence of failure. [ See…]

Guidance to adapt to context

  • Reduced.  XP is based on guidance for Core Agile Practices and some “corollary practices”, but with very few guidance to adapt to context

  • Life-cycles options 
    • Only one explicit option- Agile Basic Life-cycle - but with some guidance to achieve Continuous Delivery. 
    • There are release and iterations and the recommendation to take care also about weeks.
    • Continuous Delivery is rather poorly described as Daily Deployment corollary practices (while they specify that “has so many prerequisites “)
    • Excellent guidance about small releases

  • Process goals coverage
    • Some explicit guidance about Inception (planning game) goals.
    • Construction and Transitions are shortly addressed in these sections of the first Kent Beck XP book “Iterations to First Release”, “Productionizing”, where some goals are explained but are not “named”, for a better communication.
    • (in the same book) “Iterations to First Release”, “Productionizing”, “Maintenance” discuss mainly about the cycle of the first release and the readers can be confused about how to manage the next releases

  • Selecting practices in context

    • XP has a pragmatic approach. They have “core practices”,corollary practices” and strong recommendation for teams to discover what works for them. What is confusing is that the authors present two somehow different sets of core practices in the two main XP books.
    • XP problems in using goal driven approach
      • There are explicit process goals only for Inception
      • There is a rather small library of practices & too few guidance about options & trade-offs

  •  Library of practices – not available: only XP core and corollary practices

What is missing

  • No explicit process goals beyond inception (goals ~ basic support for tailoring)
  • No real tailoring support, too few references about other options and practices beyond XP
  • No explicit options for more Agile/Lean life-cycles (there is some implicit support and some useful references)  


Adapt to Context in DA


Support for Core Agile Practices


Support for Scaling Factors

  • Excellent: DA explicitly describe Scaling Factors and offers guidance about how the process is affected by them

Guidance to adapt to the context

  • Excellent. This is DA core: support for making process decisions in context.
  • Life-cycles options: more Agile/Lean agile life-cycle options are available. See more on Process Alphabet: Life-cycles
  • Process goals coverage: excellent. Process goals are explicit, cover whole life-cycle, have guidance and could be used to tailor any kind of Agile/Lean Process
  • Selecting practices along the life-cycles and roadmaps: This is the DA core: guidance to select practices in the life-cycle & context and the tradeoffs for different options. There is also Enterprise related guidance linking solution delivery with DevOps and Agile Enterprise. For development, Enterprise aspects are always part of the context and need to be addressed.      
  • Library of practices – Agile Basic life-cycle it is used as a model for distributing process goals and options as a library of practices. There is some great guidance about the tradeoffs of using different options per decision point and goal


How to … my custom process


Support for Core Agile Practices


Support for Scaling Factors


Adapt to context - Life-cycles selection


Adapt to context - Process Goals

  • Use explicit DA guidance about process goals distribution in Agile Basic life-cycle that also directly fit with Scrum and XP
  • XP practitioners could also use this method guidance for Inception goals (Release Planning Game)

Adapt to context - Selecting practices along the life-cycles

  • Use DA guidance to select practices in the life-cycle & context tradeoffs for different options
  • Use XP and DA guidance for Core Agile Practices and their principles-driven guidance
  • For Scrum and XP, using DA guidance, you can check if in current context you can preserve or replace the prescribed practices

Adapt to context – Library of practice  

  • Use DA library of practices (most XP and Scrum practices are already included) 
 

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