Wednesday, January 2, 2019

Process Alphabet: Continuous Improvement

Draft Version



Development context is continuously changing. Technology is continuously changing. Competition is continuously improving. Continuously improving and adapting is a survival concern, not just something nice to have.     

A base for continuous improvement: collaborative work, retrospectives, current life-cycle/process awareness. Retrospectives are fundamental for improvement. Collaborative work is fundamental for retrospectives. 

What should be expected from a method/process approach
  • Continuous improvement goal must be explicitly described as fundamental
  • Support for improvement base should be running
  • Support for improving WoW with guidance for
    • Eliminating Waste: Core Agile Practices & Adapt to Context (selecting life-cycles, practices, shaping the rolling wave in context)
    • Explicit goals for Evolving WoW (short, medium and long-term)
How to improve: we need the base for improvement and then opportunistically change the WoW: learn new practices, tailor the process by shaping our information rolling wave. 

© Copyright Valentin Tudor Mocanu 2019

Continuous improvement in Scrum

Continuous improvement goal - it is explicit, in the definition, but with too few support in the content
Continuous improvement base: Collaborative work - Scrum help teams to start working collaboratively but do not provide real good engineering practices or guidance.  Iteration level meetings are a start for teams that do not collaborate but are too simplistic and too few for professional work.
Continuous improvement base: Retrospective – Scrum has retrospectives but will be better if the impediments will be also a goal of the team and not only for Scrum Master. 
Guidance for improving WoW – there very few and too generic, as selecting one problem to solve from the last retrospective. Mainly are just a few lines of text.

Continuous improvement in XP

Continuous improvement goal - it is explicit, but not “in the title”.
Continuous improvement base: Collaborative work – XP is based on collaboration.  Collaboration with the customer it is supported by several practices, while development is based on pair programming. Anyway, there is no guidance for pair programming alternatives.
Continuous improvement base: Retrospective – XP retrospectives are a kind o Cinderella. They use retrospectives, but they often forgot to mention it in method descriptions
Guidance for improving WoW – XP is good for learning about Core Agile Practices (see Process Alphabet dedicated section) and about principles related to improvement, but there are no options for life-cycle and for core practices alternatives (excepting few “corollary practices”). Here are some of their principles
  • Definition: “It means continuous awareness, responsiveness to feedback, and openness to improvement
  • Barely good enough: “The cycle is to do the best you can today, striving for the awareness and understanding necessary to do better tomorrow. It doesn't mean waiting for perfection in order to begin.”
  • Optimize the whole: “Micro-optimization is never enough. To improve our results, we must look at the whole situation before deciding what to change
XP has no adapt to process guidance and no concrete goals for evolving WoW (excepting the Core Agile Practices).

Continuous improvement in DA

Continuous improvement goal - it is explicit, and there is associated guidance.
Continuous improvement base: Collaborative work – DA offers more non-solo work practices (beyond pair-programming) and guidance.
Continuous improvement base: Retrospective – it is explicit, and the responsibility is associated in the right way with the whole team.
Guidance for improving WoW – this is the most of DA content, guidance for choosing and improving the WoW process goals decisions points, and guidance for Core Agile Practices. 

How to … my custom process

Continuous improvement goal – make this goal explicit.
Scrum users: Inspect & Adapt is a good thing but is too vague and too few to be used only on Iteration Reviews and Daily Meetings. Use Disciplined Agile guidance with concrete goals and options. Here the explicit goals: Identify improvements, Share improvements, Support teams, Organize Communities of Practice (CoPs), Organize Centers of Excellence (CoEs), Govern improvement.
XP users: XP guidance about Core Agile Practices is great, but in DA you can find also some missing core practices such as: Architecture Envisioning, Look Ahead Modeling and Planning, Model Storming.  Also, as in the case of Scrum users, the DA concrete improvement goals will help.
Continuous improvement base: Collaborative work – you will need good coverage for all fundamental collaborative practices: intra-team, inter-teams, and collaboration with stakeholders.
Scrum users: you need to complement the Iteration and Daily Meetings with Pair Programming and the DA practices for collaborative Looking Ahead and Just-In-Time clarifications. For stakeholders collaboration, you will need to complement Product Owner with Active Stakeholder Participations and eventually with On-Site-Customer. Inter-teams knowledge & experience sharing could be done with DA Communities of Practice (CoPs) and Centers of Excellence (CoEs) .    
XP users: as plus versus Scrum, XP has Pair Programing and has additional practices for the collaboration with stakeholders. Anyway, XP does not address well the Retrospectives. For retrospectives and inter-teams collaboration, I have the same recommendation from DA guidance as in the case of Scrum.
Continuous improvement base: Retrospective – must be explicitly defined as an improvement meeting with a Whole Team approach.
Scrum users - The remove impediments responsibility should be extended from the Scrum Master to the whole team. Also should be considered DA idea to invite the Product Owner in the Retrospective and also consider DA associate guidance.
XP users should consider the DA guidance about this subject that is neglected in XP.
Guidance for improving WoW – What you need to improve your WoW?

Core Agile Practices – See Process Alphabet: Core Agile Practices
  • Use XP and DA guidance
Adapt to Context guidance – See Process Alphabet: Adapt to Context
  • Use DA guidance
Explicit goals for evolving the WoW
Scrum users: again, Inspect & Adapt for Iteration and Daily meeting is useful but is too few. Should be used  the DA concrete goals for Evolving the WoW.
Here are some of the DA guidance subject of interest (you will recognize some of the process alphabet topics):
  • How will we collaborate within the team?
  • What lifecycle will we follow?
  • How do we explore an existing process?
  • What processes/practices will we initially adopt?
  • How will we identify potential improvements?
  • How can we reuse existing practices/strategies?
  • How will we implement potential improvements within the team?
  • How will we capture our WoW?
  • How will we share effective practices with others within our organization?
  • What digital/software tools will we adopt?


Sunday, December 23, 2018

Process Alphabet: Information Rolling Wave

Draft Version



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   

Expectation support from a method

·        Information states
  • Motivation: our primary work subject & 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
  • Very important: Waterfall consider states per each discipline, where for iterative & agile consider the main states must be consolidated at work level (work item, working software, 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 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
  • 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”
  • 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
  •  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 contex
·        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 about 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 exists)  

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 proces, 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
  • 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