Disciplined Agile

Considerations for DAD Teams

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:

  • Analysis stories if needed
  • User stories for first feature
  • Validation criteria for stories are understood

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.

April 2023