Disciplined Agile

Process Goals

The Disciplined Agile® (DA®) tool kit takes a goal-driven approach (some people like to call this a capability-driven approach or even a vector-driven approach). The purpose of DA’s goal-driven approach is that it guides people through the process-related decisions that they need to make to tailor and scale agile strategies, given the context of the situation that they face, to achieve the outcomes that they desire. This supports the DA principle that Choice is Good. This is important because every team faces a unique situation. Teams vary in size, they vary in the way that they are geographically or organizationally distributed, they vary by the domain and technical complexity that they face, and they vary by the compliancy issues that are relevant to them. Furthermore, teams are made up of unique individuals, each of whom has a set of unique skills and experiences. In short, because each agile team finds itself in a unique situation the team must find a way to effectively tailor the way that they work to best face that situation—This reflects the DA principle Context Counts. DA’s goal-driven strategy is a lightweight approach to providing advice for such process tailoring.

The Process Goals of Disciplined Agile Delivery (DAD)

Figure 1 summarizes the delivery-oriented process goals of Disciplined Agile Delivery (DAD). There are twenty-four goals in total, each of which is described by a Process Goal Diagram (see Figure 2 below for an example). A disciplined agile team will consider how to address each goal in a manner that reflects the situation that they face. Sometimes a goal will be very easy to address, for example, an established development team may find that they need to do nothing else to fulfill the Form Team goal. A team that is building a solution via an architecture they are very familiar with will have very little work to do to fulfill the Prove Architecture Early goal whereas a team using technologies that are new to them may have a fair bit of work to do. Different situations require different approaches.

2021 Project Management Institute Explore Scope v5.3 Explore Purpose Ideathon Ideation board Impact map Mind map Modified impact map Outcome Really round robin Value proposition canvas Explore Usage Design sprint (User experience (UX)) Epic Persona Unified Modeling Language (UML) use case diagram Usage scenario Use case User story User story map Explore the Domain Domain/conceptual model Event storming Glossary Logical data model (LDM) UML class diagram Explore the Process Business process diagram Data flow diagram (DFD) Flowchart UML activity diagram UML state chart Value stream map Explore User Experience (UX) Design sprint (user experience (UX)) User interface (UI) flow diagram UI prototype (high fidelity) UI prototype (low fidelity) UI specification Explore General Requirements Business rule Context diagram Feature statements Impact map Mind map Modified impact map Shall statement Value proposition canvas Explore Quality Requirements Acceptance criteria Explicit list Technical stories Apply Modeling Strategy(ies) Agile Modeling (informal) sessions Open space Joint application requirement (JAR) sessions Interviews Choose a Backlog Management Strategy Lean backlog Agile backlog Requirements (product) backlog Unsequenced backlog None Level of Detail of the Scope Document Outcome driven Requirements envisioning (light specification) Detailed specification No document

Figure 2. The Explore Initial Scope Process Goal (click to enlarge)