This is the governing body for certification in Disciplined Agile.

Evolve Way of Working

  • 10 Oct 2018 5:49 PM
    Reply # 6716686 on 6638715
    Scott Ambler (Administrator)

    We just released an updated version of Evolve WoW based on the great feedback we've received.  Here is a summary of the changes:

    1. We fleshed out the Select Lifecycle section with some key diagrams and added LeSS and Nexus.
    2. We explained the Lean Change and guided continuous improvement concepts in greater detail.  This is straight out of Chapter 1.
    3. We left the discussion, mostly, of evolving WoW at different levels beyond the team to Chapter 1.  Our focus here is on the team.  The Continuous Improvement blade gets into issues beyond the team.
    4. We introduced the "Reuse Known Strategies" decision point to address where ideas for potential improvements come from.
    5. We refactored Choose Collaboration Styles into two decisions points, one for Communication and the other for Collaboration.
  • 07 Oct 2018 4:56 PM
    Reply # 6711048 on 6638715
    Scott Ambler (Administrator)

    Great feedback!  I will respond with greater detail on Tuesday but as you can see in Chapter 1, which we just posted, we've already acted on some of the feedback below.  We're going to update and repost this goal in the next day or two, likely Tuesday given that Monday is Thanksgiving here in Canada.

  • 22 Sep 2018 11:26 AM
    Reply # 6687453 on 6638715

    If we consider the product life-cycle stages proposed by Kent Beck: Explore, Expand, Extract the overall WoW strategy will also change in time. 

  • 22 Sep 2018 11:24 AM
    Reply # 6687451 on 6638715


    imo for Management level, it is important what we have to manage. Examples

    • release versus the sequence of releases for a product
    • program management - more products that need to be managed together  
    The work on more products it is addressed somehow by "enterprise awareness" aspect.
    The work related for one product is less explicitly addressed. We have roadmaps, we have MVP-like concepts. In the same time, the process decisions are taken for each release but will be re-used/adapted in the next release for the same product & team. We will have in fact common WoW aspects per product, not only per one release.

    Here are some possible aspects:
    • Life-cycle evolution - The product will start with an Exploratory approach, and then we will have an evolution. Example: Exploratory -> Agile Basic -> Continous Delivery  (with intermediate hybrids)
    • Life-cycle differences per releases: we could still have different life-cycles for the same product per different releases depending on the context
    • Choice improvement and re-use - in the next releases we can reuse or improve the process decisions

    It is important to make this aspect clear because the work for tailoring the Wow for a release is not so expensive because of this experience re-use.  

    In fact, we should have a Lean Exploratory Startup not only for the product, but also for the process. I have used the term Minimum Viable Process that will be born in the same time with the MVP.

    The WoW will evolve at the same time as the product.

    Last modified: 22 Sep 2018 11:24 AM | Valentin Tudor Mocanu
  • 12 Sep 2018 4:45 PM
    Reply # 6666737 on 6638715

    Hi Folks,

    Was evaluating this goal of WOW, and was wondering if we mention a dimension around the scale of WOW or perhaps think in terms of layers/ levels in the organisation. All of these WOW elements applies to all layers/ levels/ scale in the organisation. 

    So perhaps think about identifying the different layers/ levels/ Scale where this could apply:

    • Executive
    • Middle Management
    • "Doers"/ Trenches
    Perhaps another way to think about layers/ scale/ level are:
    • Strategic
    • Tactical
    • Operational
    Or even think about (in terms of layers/scale/level in the organisation):
    • Single Team
    • Multiple coordinated teams (Programme?)
    • Multiple coordinated areas of the business (Portfolio?)
    • Whole division
    • Organisation wide

    These WOW elements will have varied strategies depending on the layer it is applied to....

    Then, under the "Select Lifecycle" SAFe is mentioned, but what about LEss, Nexus, etc? Are these lifecycles or just scaling strategies?



    Last modified: 12 Sep 2018 4:49 PM | Aldo Rall
  • 27 Aug 2018 12:33 AM
    Reply # 6639935 on 6638715

    Identify Process Improvements - "Ad-hoc process improvement."

    This is, in fact, a very powerful Agile tool and the Leanest (!), used for continuous improvement. As I have mentioned before, stand-alone practices cannot provide the optimum. To be effective should be combined with other practices as controlled experiments, retrospectives, and collaborative work. That means we should treat them as some kind of experiments that should be the subject of JIT and periodic retrospectives. 

    Kent Beck first XP team that works for CCC projects has used this technique and that allowed to shape the XP as it is now. One example was "dedicated integration computer".

    My proposal is to rename as JIT process improvements and add some of the above comments.  In fact, in many cases, we have dome such kind of improvements after Pair Programming, Model Storming, and opportunistic Look Ahead

  • 26 Aug 2018 9:29 AM
    Reply # 6639242 on 6638715

    Identify Potential Improvements – “Core Agile Practices” instead of “Best practices”

    There are no such things as best practiced (... where a lot of practices with such label can be very useful). We have instead a very valuable thing “Core Agile Practices” (named by DAD “critical” practices). There is a specific value of this practices.  Maybe are not the best options in our current context, maybe we do not have the skills, but this is the value:

    • CAP will help to implement (or get close) the most effective/efficient life-cycles as Continuous Delivery  
    • Idem – will help to make the team performant: “whole team” and “collective ownership”

    Adoption of Core Agile Practices must be opportunistic:

    • Start with what will bring you more value with less effort
    • Adopt them on short, medium and long-term according to the context needs

    IMPORTANT – Core Agile Practices are already a significant part of DAD guidance but what is missing is exactly this: to explain their contribution to WoW improvement & how to use them. Imo It is the most severe missing part from DAD guidance.


    Identify Potential Improvements – Local “Best practices”

    Instead of industry best practices (... do not exist), we can have some “local” best practices, resulting from the experience in the local organization, product or team context. Yes, it is about “Leverage and Enhance Existing Infrastructure process goal (Chapter XX)”.  To be effective, we need to be used as any other existent knowledge/experience:

    • Must be classified by categories of contexts
    • Must be used opportunistically – we can decide to select & adapt  
  • 26 Aug 2018 9:01 AM
    Reply # 6639238 on 6638715

    Choose Collaboration Styles vs Communication style

     I  rather use here the title – Choose communication style. Collaboration style should rather talk about how we really collaborate (ordered):

    • Opportunistic Non-Solo development (combination of all others)
    • Pair programming/Pair Development  
    • Meetings
    • Standalone work with handoffs

    Collaboration style is fundamental. You can asses how likely is the improvement (... and the start of improvement!) only by this aspect that will dramatically affect all the others.

  • 26 Aug 2018 8:46 AM
    Reply # 6639220 on 6638715

    Principles - Collaboration with other teams will always help

    About this part <<Principles - The other teams we collaborate with are evolving.

    “Very few agile teams are “whole” in practice they must collaborate with others to achieve their mission.”>>

    The main problem here is that if we have only “whole” teams, collaboration it is still a must (same thing as for senior skills individuals inside a team). The real “whole” - involved in optimizations & improvements - is not the team, but the union of teams.

    I propose this kind of reformulation:

    Collaboration with other teams will always help. Very few agile teams are “whole” in practice – they must collaborate with others to achieve their mission.  More: two “whole” teams that collaborate and share experience will get better results than working as “local” teams. The other teams are evolving their WoW over time anyway but evolving together will give an optimum result for all teams.

  • 25 Aug 2018 5:24 PM
    Message # 6638715
    Scott Ambler (Administrator)

    I'm very happy to announce that we've released the excerpt for Evolve Way of Working (formerly Improve Team Process and Environment).  In many ways this captures the key thinking behind the new book.

    Looking forward to hearing your feedback.

© 2013-2019 Project Management Institute, Inc.

14 Campus Boulevard

Newtown Square, PA 19073-3299 USA

Powered by Wild Apricot Membership Software