These lists of considerations are useful reminders for DAD teams to help them consider the practices of DAD and agile/lean during the various phases of the life cycles.
Use these lists of considerations as starting points. You should adapt them to fit your own local context and terminology.
Many of these considerations are most appropriate for software development teams. You may be able to adapt them to other types of contexts.
Considerations for Construction Phase
Iteration Planning
Activity |
Description |
Roles |
Product owner and architect owner assigned |
Team |
Team identified with all of the needed roles: dedicated to the release, funded, and colocated as much as possible. The team is staffed with all of the needed roles, funded dedicated to the release, and colocated as much as possible. Team has received required training: Lean-Agile software development, Test-Driven Development, Engineering practices |
Environment |
Review and define workflow. Review and define visual board. Review policies for stories. Establish logistics for meetings, locations, times, frequency, participants. Tools for testing, coding, integrating, building are selected and installed. Established logistics for daily coordination meeting (time, location, conference call information, website). Agreed to the ground rules for team life. Organized (and clean up) the team work space: physical, communication, collaboration. Set up the team’s project board. Established the test and build environment. |
Vision |
Release vision statement is prepared. The team understands and agrees to the vision, drivers, and expected outcomes for the release. |
Backlog |
MBIs introduced and reviewed with team. Refine description, scope, validation, and done criteria. Identify risks, issues, dependencies, uncertainties, and known impediments. Rank, prioritize, and represent these with stories. |
Architecture |
Review and define the high level architecture and design. Architectural goals and approach identified, visible. Dependencies and risks Identified, visible. Conceptual design completed. |
Technology components |
Identify technology components. Input technology features and/or stories into team backlogs. |
Feature sequence |
Finalize feature sequence by business value and technical dependencies. |
Iteration backlog (if iterative life cycle) |
Iteration length is set. Iteration backlog established, populated, and visible. Stories are assigned to the first few iterations Input items into appropriate tools. Team has committed to iteration 1 plan. |
Story estimation |
Review and define complexity factors that will be used for relative sizing in story points. Stories decomposed and right-sized:
Stories are estimated for first few iterations’ work. |
Continuous improvement |
Intentionally incorporate lessons learned from previous releases. |
Testing agreements |
Definition of Done established and documented (Unit, Integration, Acceptance). Testing approach (Unit, Integration, and Acceptance) is committed to and visible. |
Reporting and metrics |
Book of Work program backlog. Top-line story points. Feature burn-up. |
Artifacts |
Identify product documentation that must be maintained. |
Iteration Planning Meeting
Activity |
Description |
Vision |
The team understands and agrees to the iteration vision. All members of the team have a common interpretation of the various terms used in the vision statement. |
Learning from the past |
For the kind of work we are going to do in this iteration, are there lessons learned or good practices that we incorporate from anyone on this team, on other teams in the organization, or in the literature? Invite a “Second Set of Eyes” from outside to think through the plan. |
Story estimation for iteration |
Initial estimate of story points for iteration. Stories decomposed and right-sized. Validation criteria for stories are understood. Stories are estimated for first few iterations’ work. |
Dependencies and risks |
Dependencies and risks identified as stories. Impediments identified, posted on team board, assigned. |
Iteration backlog |
Stories are assigned to the iteration backlog. Tasks are identified for the stories in the iteration backlog. Team has committed to iteration plan. |
Commitments |
Commit to demonstrating the product to key stakeholders at the end of the iteration. Commit to conducting a retrospection at the end of the iteration. Commit to conducting retrospectives as appropriate during the iteration. |
Testing agreements |
Definition of Done established and documented (unit, integration, acceptance). |
Team |
The team is staffed with all of the needed roles, dedicated to the release, and colocated as much as possible. Team has received required training in process, testing, and engineering practices. Artifacts and deliverables determined (and visible). |
Team environment |
Tools for testing, coding, integrating, building selected and installed. Established logistics for daily coordination (time, location, conference call information, portal, etc.). Agreed to the ground rules for team life. Organized (and clean up) the team work space: physical, communication, collaboration. Set up the team’s project board. Established the test and build environment. |
Iteration Execution
Activity |
Description |
Input tests / code until tests pass |
Unit test has been completed and documented. Defects clearly defined, resolved and tested. |
Run functional tests |
Functional tests have been completed, documented. Defects clearly defined, resolved, and tested. |
Run user tests |
User tests have been completed, documented. Defects clearly defined, resolved, and tested. |
Update business processes and conduct training |
All impacted business processes have been assessed. Appropriate changes have been made. Training has been developed and executed. Participants have been certified. |
Product owner / analyst acceptance |
Product owner or analyst has formally validated that the story has been completed and is ready to be promoted to production to support the MBI. |
Product Demonstration and Review
Rule |
Description |
Demonstrate the product as it is |
The demonstration is always done with the product as it is. Avoid using slides or other artificial “demo-ware.” This is possible because the product should always be tested (perfected), usable, and completed by the end of the iteration. |
It is a conversation |
The demonstration is a conversation between the whole team, the product owners, and the stakeholders. They collaborate on what has been done, what has not been done or could not be done, and what the current needs are. It is not a presentation. |
Blame-free environment |
The team has done what it could do and is forthright about what it could not do. It is not a time to assess blame but to describe the facts about what was really done. |
Everyone is present |
Everyone has a viewpoint to share. Many ears help to maximize communication. As much as possible, avoid redundancy (waste) in meetings. |
Considerations for Transition Phase
Release
Rule |
Description |
Vision |
Product manager and product owner have prepared the product vision and release vision. |
Essential stories |
Release planning team has identified the essential stories for the next release. |
Release plan |
Release planning team has populated releases and prioritized MBIs. |
Demonstration |
Team demonstrated product to key stakeholders. |
Retrospection |
Retrospection of the release is planned. Retrospections are conducted as appropriate during the release plan. |
Iteration Implementation
Activity |
Description |
Ready for production |
Code is potentially ready to be released. |
Promote |
Release has been successfully executed. |
Value extracted from feature for business |
Feature has been successfully executed and the business value has been achieved. |
Retrospection |
Meeting has been conducted to evaluate success of work effort and ways to improve the process. |
May 2023