Showing posts with label Collaboration First. Show all posts
Showing posts with label Collaboration First. Show all posts

Sunday, December 23, 2018

Process Alphabet: Information Rolling Wave

Draft Version 2

 

Intro

Our subject of work is the information
Information rolling wave is the model of what we do

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 ...
  • Waterfall versus Iterative/Agile
    • Waterfall consider states per each discipline (e.g state of requirements)
    • Iterative & Agile consider the consolidation of the states at the 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 the 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
Value stream shaping the rolling wave 
  • Motivation: Value-stream mapping - “Material and Information Flow Mapping” at Toyota - in the case of software development is mainly information flow mapping. Value stream helps us to identify the useful types of work and subsequently the needed practices
  • Core practices (see below) are proven domain-level instruments that fit the development value stream; for each particular situation we still need to adapt practices, life-cycles & to context      
  • Value stream support examples: pragmatic product-oriented practices or better consumable solution support. Focusing on the final output -  the product - helps to avoid unnecessary work. Focusing on the final outcome - a consumable solution is even better.   
  • Clear support for information states
·        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
 
Rolling Wave in Scrum

·        Information states
  • Explicit state for work item at iteration level only: ready, done
  • 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
Value stream support 
  • Product backlog, product increments oriented practices (the spring main goals is to produce value via product increment)
  • What is missing
    • alternative variants for different situations (e.g missing parts on Life-Cycles)  
    • focusing on the outcome (Consumable Solution) versus focusing on the output (working software) 
·        Selecting practices that shape the rolling wave
o   Prescribed practices, without options
o   Only iteration, iteration meetings, daily meetings, product backlog (and 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 adding other practices when it does not displace its prescribed practices. Anyway, Scrum 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 a much higher granularity, starting at the week level. Comment: you can modify a Scrum-based process to support these life-cycles, but the result 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 the work item: 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
    • 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  
Value stream support  
  • Small releases with often adaptation on the changing business needs
  • Implicit support by strongly use of the core practices
·        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 a 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 except the ones for Inception
  • No real tailoring support, too few references about other options/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 the work level (iterative/agile/lean approach)
  • Life-cycle light milestones ~ real advance of the work states toward 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 
  • 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
Value stream support  
  • Work focused on the product as Consumable Solution 
  • Explicit value stream based-approach 
  • Process goals as one of the VS foundations
  • Lightweight milestones 
  • Guideline to streamline the work
 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 the optimum way to make 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 
  • Value stream support -  see life cycles, Consumable Solution, information states
Roadmaps & life-cycles
Adapt to context
 Value Stream
  • See Information States and Core Practices
  •  
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) 



Posted by at No comments:
Labels: , , , , , , , , , ,

Sunday, November 4, 2018

Take care about your impact!

CIVILIZATION & SOFTWARE – There are some common things between human history and software development: the fundamental things in evolution are the people, their collaboration and how they are creating, managing and distributing knowledge.  


“REACT BEFORE DISASTER” – several days ago I have discussed with a younger friend about what we need to improve a country or city status-quo, dealing with an ineffective evolution. Things are stopped improving, groups of interested have now a well-oiled political machine and propaganda that allow them to act discretionary and people seems to be anesthetized. It was interesting that this candid viewpoint seems to be very similar to what really works in human organizations in history, but also in software.  

Until the people do not reach a desperate situation, morality remains just for coffee discussions. More, when people start doing something, they do not agree with each other ... they are hampered in detail and forget the purpose.

Maybe politics is not for us, and that’s it…

Maybe we can ... probably with more patience. The politics is also part of life you do not have to join a political party to do your civic duty ... just that there's the problem that how to communicate well enough to convince people that needs to be involved. Instead of being stuck in some blind principles we can do something against what it is worse.  

There are some macro level things that could be done: if healthy economic interests are growing, something will change.

Let think to the micro level, where we are now: I should ask myself what I can do for my own little community. That is also indispensable.  


“BEFORE DISASTER” IN SOFTWARE  - In software development instead of malefic groups of interests we have specific problems more similar for us with some “natural disasters”. Technical debt is accumulating and will deeply affect our products and business. We are unable to deal with the complexity of software variants. We are unable to produce, manage and effectively transmit the knowledge. The status quo is similar to the one from above dialog:

  • Professional ethics is just a discussion at coffee break until a disaster will strike us
  • We think that we can do nothing because some forces beyond our powers are influencing our context
  • We are stuck in some “local” ideas and principles without collaborating to optimize the whole
  • The “global goods” as the product design healthy are the responsibility of no one

What is really happening: we do not react when the problems are small, we let these problems to accumulate, we do not speak loudly about them. It is not our responsibility, it is a “Deux ex Machina” job. We are expecting for formal responsibilities delegation instead of acting according to implicit professional responsibilities (~political vs. civic)  


WHAT GIVE US A CIVILIZATION – “Flexibly cooperate in large numbers” it is the argument of Yuval Noah Harari [Biblio- Harari 1]. What I did not find in Harari book Sapiens [Biblio- Harari 2] it is what always work better regarding this cooperation. It is not the religion, or the empire.  The best advances in civilization were made by “entrepreneurial societies”, where there was (some) liberty, especially liberty of action, and people could directly participate in political decisions. Here are some examples:
  • Minoan civilization – beginning of the European civilizatio
  • Classical Greek – people are entrepreneurs in science, arts, commerce but also in the military. If the Mycenaeans have only palaces and big defense walls, in Classical Greek, the first most important construction in a city-state will be the Agora. 
  • Roman Republic (the Empire just inherited anything that the Republic has built)
  • Medieval Renascence in all domains
In human history and even earlier, we can find and observe various ways of human organizations and their specific result. History starts with the first large communities, where people could start “Flexibly cooperate in large numbers”. Anyway, in modern society with a lot of small, medium and large communities, we can find us again isolated as individuals and even as teams.  


LEVEL OF INVOLVEMENT – to have a society that evolves and improve, we need the active involvement of its members. We have modern states where this level is low and ancient states where this level was high.  Consequently, there are modern states with no evolution and there were ancient states with outstanding evolution. Modernity by itself it is not a guarantee for evolution, but our behavior. 
We will go back to the software to see how it is possible to be responsible not only for good ideas but also to have an impact on the community and society.


KENT BECK:  FROM IDEA TO IMPACT (ON COMMUNITY) - There is a kind of specificity for great contributions in software development. These contributions are not some lab researches first published in scientific papers and latter applied in production. This kind of contributions are made for production and it is re-evaluated again and again. More: bright ideas and implementations are not enough. You need to do some hard work to distribute them in a good form.  Kent Beck [Biblio- Idea to Impact]:  

“Here are the stages:
1.      Adopt personally
2.      Find the totem
3.      Repetitively broadcast”

Kent Beck “Idea to impact” it is the road from micro to macro level, nurturing and validating a good idea, then trying to distribute and making an impact.

“When I have convinced myself by personal experience that an idea has the potential for impact, I start talking about it.”
“These conversations help me find the spirit of the idea. I know the mechanics and maybe the theory of the idea, but I don't know the intellectual and emotional hooks that will interest and motivate other people to try what, if I'm doing it right, sounds pretty crazy.”
“Along the way I pay attention to what other people are saying about the idea. When I hear someone repeat the idea to someone else without referring to me, then I know I have won.”


“TEAL IS THE NEW BLACK” – Scott Ambler propose (inside Disciplined Agile) the same parallel with the civilization progress [Biblio – Teal Orgs]. He uses the model of the author of Reinventing organizations, Frederick Laloux, where the most advanced forms of organization are [Biblio – Teal Orgs]:  

Teal: Self-organizing/Adaptive
  • Cellular. living organism
  • Awareness, fulfillment
  • Evolutionary purpose

Green Post Modern/Information
  • Consensus/Participative style
  • Value based motivational culture

You can see here that evolution it is strictly related with (direct) Participation and Awareness.

For effective, efficient (Agile) teams, Ambler recommends a Teal-like organization or at least a Green one. He specified, that most likely “Your Organization is Probably a Rainbow” and your strategy should be adapted to the context [Biblio – Teal Orgs].


WE HAVE IDEAS, REFERENCES, AND GUIDANCE!  

What we do in each second will have an impact. Longer period with no improvements it is also a kind of (negative) impact in evolution. As Yuval Noah Harari said [Biblio- Harari 1] humans have done also horrible things while they have collaborated in large numbers.  For a positive impact we need not only to collaborate, but also we need to be aware and “civically”/”ethically” involved both at work and as citizens.

Some find references from history as in “Reinventing Organization” [Biblio – Teal Orgs].  According to others, even the newest organizational types are not so new, and are proved or not by the history. “If we don’t learn from our successes as species, in the course of reinventing organizations we will spend a lot of time reinventing the wheel.” [Biblio- Jessica Prentice].

We have references and guidance in the software industry. Kent Beck has told as a story about how to go “From Idea to Impact”. Robert C. Martin writes about “responsibility of the programmer”. Discipline Agile (Scott Ambler and Mark Lines) offer guidance about how developers and other stakeholders could be actively involved and collaborate at team, enterprise and community level.

Last, but not least, we have “the next Jedi”, young people with the same good intuition and common sense as their predecessors.

Take care about your impact!   


REFERENCE AND BIBLIOGRAFY

[Biblio- Idea to Impact] - Idea to Impact, Kent Beck· Wednesday, July 8, 2015
[Biblio- Harari 1] - Why humans run the world - Yuval Noah Harari
[Biblio- Harari 2] - Sapiens: A Brief History of Humankind Hardcover
  • February 10, 2015, by Yuval Noah Harari
[Biblio – Teal Orgs] - Teal is the New Black, Scott Ambler
[Biblio – Jessica Prentice] - The Most Dangerous Notion in “Reinventing Organizations” by Jessica Prentice

Posted by at No comments:
Labels: , , , , , , ,
Subscribe to: Posts (Atom)