This is the governing body for certification in Disciplined Agile.
LIVE CHAT 24 HOURS PER DAY
Everyone, great feedback. As usual I'll go one at a time:
There is one Item that requires clarification from the "Develop Software" decision point. It indicates that BDD and ATDD is the same in the detailed description on pp. ; I have met some people that considers these as different items, and some saying is it the same. The same argument applies to SBE (Specification by example); Perhaps the option should be documented as "BDD/ ATDD/ SBE" instead of just "BDD".
Would it also not be useful to specifically mention refactoring as a separate option? or even mention it as part of the TDD option: "TDD and Refactoring"?
Then a note here: The Testing Quadrants and automation pyramid can also be used at this level. I would recommend considering some of the testing choices from the Initiate phase in this section as well as the tools mentioned in there will apply to a lower level as well...
Write Deliverable documentation: Gojko Adzic talks about "living documentation" where test scripts are used as the latest documentation. Would it be possible to look at multi-use documentation types? (such as using test scripts for doubling as test scripts AND user documentation)
Look Ahead Planning
IMPORTANT – as a trade-off for <Potential to be wasted effort if the work item is deprioritized or even removed …>
Look Ahead Modeling (Requirements/Solution)
VERY IMPORTANT - Imo in this part we need more trade-off guidance because Look Ahead it is the main instrument to eliminate waste!
“If the work item becomes a low priority and is not implemented the modeling work becomes a waste. The further ahead you model he greater the risk that the requirements will change, and your modeling will be for naught.”
Looking ahead could be a great instrument to eliminate the waste, but also could create waste if it is not adapted to the context and we do not follow some principles:
Again, Looking Ahead it is one of the main instrument to eliminate waste of waiting and getting a Lean, streamlined process! Looking ahead on development is similar with Looking ahead on driving.
Waiting is a disastrous kind of waste because will mess-up the next incoming work in cascade.
Plan The Work, Coordination meeting
Help to optimize the team collaboration needs and people inter-dependencies in that day. Looking ahead - will avoid waste of waiting for the current day.
Write Deliverable Documentation, Continuous documentation – Following iteration.
Ime it is not recommended when we do not validate the working software with automated tests. We cannot end the iteration without testing, and we cannot perform manual testing without documentation.
I propose another decision factor: “Managing the work and the work in progress”. Planning is just one aspect, TDD as development approach is also one aspect, but the first decision to make is how we will split the work. This is one fundamental aspect of Agile & Lean.
If our development work will be (or need to be) split in days, then we must choose and master appropriated practices for planning, requirements, solution, consumability. That mean decisions on all aspects must serve and make possible the selected work management approach.
In fact, this factor it is just a translation of the principle “Produce a consumable solution incrementally”: the first effect it is at work splitting level (and reducing WIP).
Managing work and work in progress
We just posted the excerpt for Produce a Potentially Consumable Solution.
Please post any feedback that you have for this goal here.
Thanks in advance!
© 2013-2019 Project Management Institute, Inc.
14 Campus BoulevardNewtown Square, PA 19073-3299 USA