This is the governing body for certification in Disciplined Agile.

Accelerate Value Delivery

  • 17 Sep 2018 4:46 PM
    Reply # 6673472 on 6375589
    Scott Ambler (Administrator)

    @Brent, good points.

    I'm thinking that these ideas should be spread out though, as some hit on architecture (so Identify Initial Architecture Strategy perhaps), some hits on process improvement (so Evolve Your WoW), and some here.  Need to think about this a bit.

  • 22 Aug 2018 2:10 AM
    Reply # 6633438 on 6375589

    Just a thought for completeness?

    Page 2 - support a DevOps strategy through automation

    This is great, however DevOps has mature now to include improve leaner processes to compliment automation.  My suggestion is to state "Support a DevOps strategy through streamlining and automation".  Why is streamlining  important, two fold:

    1. Because we are shifting a lot of stuff from right of the project to left, while we can't automate everything yet =).  

    2. Infrastructure as code is complemented by:

    • Serverless technologies using FaaS (function as a service) platform(s)
    • Immutable Infrastructure
    • Distributed DevOps
    Through exposing functions and services (APIs) over a framework.  While not trying to get to complicated here, I think it important to drive home yes DevOps teaches Automation is one important and key factor, the other is leaning out the processes for which new technologies are advancing to make DevOps more mature, repeatable, accessible and manageable.   Especially as we crank up the DevOps cycles we can add a lot of overhead, this has been seen with use of Open Source software and rapid development of the tools, plugins and platforms that support the DevOps processes and the applications that are created...

    maybe we can expand a bit more on this without getting off topic and I will spend more time reading this entire section...  
  • 21 Aug 2018 1:47 PM
    Reply # 6631967 on 6375589
    Scott Ambler (Administrator)

    I have just posted the update to this excerpt.

    My apologies for the delay.

  • 19 Aug 2018 8:06 AM
    Reply # 6582374 on 6375589
    Scott Ambler (Administrator)
    Thanks for the feedback.  Here are my thoughts:


    1. Release trains appears as an option in Release Management (the process blade) and has been added now to this process goal  (In Choose a Deployment Strategy).  Good catch.  And we had misalignment between the two goal diagrams, so I fixed that too!
    2. Applying Feature Toggles is certainly a heck of a lot easier with a Single Branch strategy, will mention that. 
    3. I think you're right about Validate.  It was originally about testing strategies but then a few testing types worked their way in.  I will split this up into two decision points as you suggest.
    1. Good point about the relationship of Lean and deployment strategy.  I've added some verbiage.
    2. Verify - Good point, we need to add a discussion about why this is important.  
    3. Verify - I'm renaming this decision point to Verify Quality of Work to make it a bit more clear. This is a general thing we intend to do: ensure that the name of a decision point is clear and action oriented.  Might not work out for every decision point, but will certainly work for most.
    4. Integration Tests first - Good point.  We actually covered this in Identify Initial Architecture Strategy but it needs to be here too. Will add.
    5. Maintain traceability - I'll link built-in to the two generate options.
    I hope to release a new version of this excerpt on Monday.  Stay tuned.
  • 21 Jul 2018 8:56 AM
    Reply # 6391474 on 6375589

    Validate: Integration tests first  

    This approach (a known supported is Walker Royce) works perfectly with DA Proven Architecture Milestone. In fact, this milestone requires more than integration of every new piece of working software with the existent one. Integration problems are by default architectural problems and we need to shift them left in the life-cycle.

    It is complementary with all other options but works better with automated tests.    


    Maintain traceability: Built-in traceability

    In my experience, the most efficient and effective way for traceability is the built-in traceability: if the product architecture and design follow the separation of concerns principle, we can easily find in the code the functional/business aspects that are decoupled from others. That works better with other practices like TDD, BDD, Clean Architecture. This approach is lean and reduce, but not exclude the need for the other options. 

  • 21 Jul 2018 8:39 AM
    Reply # 6391452 on 6375589

    Verify: Why  

    About this part: << We need to verify that our solution complies with appropriate regulations and organizational guidelines. As you can see in the following table, this can occur manually via reviews and non-solo work strategies or in automated fashion via digital tooling.>>

    We need to answer (up front) to the first question raised by the ones that receive the guidance: Why?

    In this case, regulation and guidelines are used to build and improve quality of our work through several aspects as design, built-in quality, consistency, desired style in context, non-functional requirements, preventing bugs and others.

    Verify: How  

    My proposal for complementing introduction:  quality and quantity analysis will bring better results if they will complement each other and the results will be interpreted together in context.

  • 21 Jul 2018 5:02 AM
    Reply # 6391347 on 6375589

    (i just updated)
    Choose a Deployment Strategy – Reducing WIP: Agile and Lean principles,

    Previously I have proposed to have more explicit trace between Lean (and Agile) principles and DA concrete guidance per goals

    "Our aim is to reduce the feedback cycle between the team and our stakeholders so as to identify potential changes as soon as we can, thereby reducing the average cost to make those changes."

    My proposal is to complement this part with more info about the benefits.

    INTRO COMMENTS (about smaller release)- This is important, it is a fundamental aspect of Agile/Lean and software development: reducing Work in Progress with smaller releases. Why we propose small releases approach (multiple benefits):

    • (above mentioned) reduce feedback cycle to identify changes asap and reduce costs
    • Lean principle: No Inventory/Reducing Work in Progress. We reduce the overall complexity and incertitude and that will boost any other aspect: cost, quality, speed.
      • it is also one (or even two) of the 12 Agile Manifesto principles
    • Incoming Changes Request will affect less the Work In Progress: in this smaller time will be fewer CRs and most of them could be planned to a next release
    • Reduced work in progress will allow a better management of the work (easy re-planning): long releases will block the team and re-planning for new emergencies are difficult, expensive and dysfunctional.     


    The most important thing related to reducing WIP at life-cycle level is to have small releases. Inside a release, we want to shift left the risks related to integration and deployment. Anyway, no matter how well we will integrate, validate and get feedback inside the release, the main source of complexity will remain the size of the release. The most important aspect of the WIP is the release. So, the principle "slice the work first" should consider this order

    • first make the release smaller
    • slice the work as much as possible inside the release and shift the risks to left in the life-cycle
     ~ optimization should consider the whole
    Last modified: 21 Jul 2018 4:51 PM | Valentin Tudor Mocanu
  • 11 Jul 2018 3:44 PM
    Reply # 6376794 on 6375589

    Hi Folks

    In Accelerate Value Delivery --> Automate Infrastructure you mention feature toggles.... I recall from watching the famous Spotify video that they use that in conjunction with Release Trains (we use both together at NZ Police)... Is this a pattern that will be utilised with Accelerate Value Delivery --> Choose an SCM Branching Strategy: Single Branch? or is "release trains" a missing option (but not necessarily for "Automate Infrastructure", perhaps "Deployment strategy"?)


    Then I had a look at Accelerate Value Delivery --> Validate, and I have some comments. 

    Is there a reason why there is a mix of testing strategies and testing types?

    I see Automated Regression testing, BDD/ATDD, Continuous Integration, Manual testing, Parallel independent testing, Test After development, and TDD as testing/ quality strategies.

    And I see Database testing, end-of-lifecycle testing and exploratory testing as testing types.

    One nuance that many people miss with the testing quadrants is that it applies to all levels: Product, Release, Feature, Epic and story. 

    I would instead perhaps utilise the Testing Quadrants (which contains the testing types; One can also add additional testing types to the quadrants if is there is a need for a given context) here to replace all the testing types, and utilise the testing quadrants as a strategy to the highest and lowest levels of detail of a product. 



  • 11 Jul 2018 7:01 AM
    Message # 6375589
    Scott Ambler (Administrator)

    We have just published the excerpt for the Accelerate Value Delivery process goal, formerly called Move Closer to a Deployable release.

    We're looking forward to your feedback!

    Thanks in advance.

© 2013-2020 Project Management Institute, Inc.

14 Campus Boulevard

Newtown Square, PA 19073-3299 USA

Powered by Wild Apricot Membership Software