This is the governing body for certification in Disciplined Agile.
LIVE CHAT 24 HOURS PER DAY
@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.
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:
I have just posted the update to this excerpt.
My apologies for the delay.
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.
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.
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.
(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):
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
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.
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 BoulevardNewtown Square, PA 19073-3299 USA