Overview of Disciplined Agile Delivery (DAD) Framework And Its Comparison with Scaled Agile Framework (SAFe) For Scaling Agile

1

Disciplined Agile Manifesto: Values

Our Values

We value:

Individuals and interactions over processes and tools

Consumable solutions over comprehensive documentation

Stakeholder collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, disciplined

agilists value the items on the left more.

2

Disciplined Agile Manifesto: Principles1. Our highest priority is to satisfy the stakeholder through early and continuous delivery of valuable

solutions.

2. Welcome changing requirements, even late in the solution delivery lifecycle. Agile processes harness change for the customer’s competitive advantage.

3. Deliver consumable solutions frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale.

4. Stakeholders and developers must work together daily throughout the project.

5. Build teams around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a delivery team is face-to-face conversation.

7. Consumable solutions are the primary measure of progress.

8. Agile processes promote sustainable delivery. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity – the art of maximizing the amount of work not done – is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

13. Leverage and evolve the assets within your enterprise, collaborating with the people responsible for those assets to do so.

14. Visualize work to produce a smooth delivery flow and keep work-in-progress (WIP) to a minimum.

15. Evolve the enterprise to support agile, non-agile, and hybrid teams.

3

Disciplined Agile: Introduction

Not a scaling framework as such but effective from single

small team to Agile at scale.

NOT a prescriptive method with step-by-step guidance. Rather

a process framework which you can adapt to the unique

aspects of your project and organization.

Extends Scrum and includes strategies from Agile Modeling

(AM), XP, and Unified Process (UP).

Addresses areas not thoroughly covered in existing small-

scale frameworks.

Recommended 3 phases: Inception, Construction, Transition.

Construction phase is similar to Scrum. (However, some DAD

teams that have also adopted lean strategies may not have

iterations. )

4

Disciplined Agile Delivery: Lifecycle

5

DAD Process Framework: Characteristics

People first

Learning-oriented

Agile

Hybrid: Adopts strategies from Scrum, XP, AM (Agile

Modeling), UP (Unified Process), AD (Agile Data), Kanban

IT Solution Focused

Full delivery lifecycle

Goals driven

Risk and value driven

Enterprise aware

6

Disciplined Agile Delivery: Roles

Primary roles:

• Team member

• Stakeholder

• Architecture Owner

• Team Lead

• Product Owner

Secondary roles:

• Domain expert

• Specialist

• Technical Expert

• Independent Tester

• Integrator

7

Mapping DAD terminology to Scrum and XP

DISCIPLINED AGILE SCRUM XP

Team Lead ScrumMaster Coach

Iteration Sprint Iteration

Coordination meeting Daily Scrum Daily standup

Product Owner Product Owner Customer

Team member Team member Extreme Programmer

Architecture Owner - -

Work item list Product/Sprint

backlog

-

Spike - Spike

Development

guidelines

- Coding standard

8

Practices adopted from Scrum

■ Work item list (Product backlog)

■ Value-driven lifecycle: In addition, DAD adopts risk-value-driven lifecycle

■ Coordination meeting: Primary question people should address is whether they foresee any upcoming problems.

■ Release planning: Levels of scope to consider: portfolio, solution, release, iteration and day.

■ Iteration planning

■ Iteration review and demonstration

■ Retrospective : Experienced teams can hold retrospectives whenever it makes sense to do so.

■ User story-driven development : DAD follows usage-driven development as it is less prescriptive where the primary requirements artifact is usage focused, such as a user story, usage scenario, or use case.

9

Disciplined Agile: Milestones

■ Stakeholder Vision: Address each of the DAD inception goals. Review a short set of slides with key stakeholders at the end of the Inception phase to ensure that everyone is on the same page with regard to the project intent and delivery approach.

■ Proven Architecture: Build an end-to-end skeleton of working code that implements technically risky business requirements. As a result, early iteration reviews/demos often show the ability of the solution to support NFRs in addition to, or instead of, functional requirements.

■ Project Viability: Optional milestone. A checkpoint to ensure that the project is progressing consistent with the vision agreed to at the end of Inception.

■ Sufficient Functionality: at the end of Construction

■ Production Ready: ensure solution is consumable before you deploy it.

■ Delighted Stakeholders : when the initiative is officially over.

10

Inception Phase: Goals

11

Inception Phase: Initial Release Planning Choosing the right scope for the plan (The agile planning onion)

Choosing a general planning strategy: Recommendation is to combine agile

release planning (predictive –light) with adaptive – detailed, if team is

relatively new to agile, else agile release planning with adaptive – light with

an experienced team.

Choosing cadences: It is recommended to aim for release cadence of no

more than 6 months, with a goal of getting it down to 3 months or shorter.

Formulating an initial schedule

Estimating the cost and value ( using planning poker and educated guesses

by the team)

Identifying risks

12

Inception Phase: Patterns

■ Short and sufficient: Inception phase shouldn’t take >1

month (with the exception of research or ground-breaking

projects). Ideally, this should be completed in 2 weeks or

less.

■ Ranged estimates: It is highly desirable to provide ranged

cost and schedule estimates to provide sufficient flexibility

for the development team to deliver a good solution.

■ Minimal but sufficient documentation: Documentation

should include some basic models (diagrams) of the

envisioned architecture and other views of the solution and

additionally, concise vision statement and a work item list.

Also, there will be other critical diagrams resulting from

requirements and architecture envisioning efforts which are

actively used by team to guide their efforts.

13

Construction Phase: Goals

14

Construction Phase: Patterns

■ The team can be reliably depended on to demonstrate

increments of software at the end of each iteration.

■ Team members finish their tasks ahead of schedule and ask

to help others with their tasks.

■ Iteration dates never move.

■ Any stakeholder can walk into the common work area and

request to see a demonstration of the working software as it

currently sits, at any time.

15

Transition Phase: Goals

16

Transition Phase: Activities

Ensuring Production Readiness

• Transition planning (detailed implementation plan)

• End of lifecycle testing and fixing

• Deployment testing

• Data migration preparation

• Pilot/beta of the solution

• Finalize documentation

Preparing Stakeholders for the Release

• Communicate deployment to stakeholders

• Train/educate stakeholders

• Prepare/support environment stakeholders (Helpdesk, Disaster recovery)

17

Transition Phase: Activities

Deploying the solution: High-level activities might include:

• Running of any batch jobs against the existing system

• Backup of existing system

• Migrating source data to new formats or even to new

technologies

• Deployment of solution artifacts to target environment

• Execute deployment testing: “smoke testing”

• Back up the new solution

• Make the new solution available to customers : make

the system “live”.

• Enable your support system

• Communicate successful deployment

18

Transition Phase: Patterns

■ Short and sufficient

■ Multiple iterations e.g. scaled rollout in several iterations for

geographically dispersed set of users

■ Proven deployment/installation

■ Choose your release patterns

19

Agile Scaling Model (ASM)

■ Core agile development

• Small teams (<15 member teams)

• Co-located

■ Agile Delivery

• Small-to-medium size teams: Up to 30 people

• Near-located (within driving distance)

■ Agility@scale : This is where one or more scaling factors apply. Scaling factors include team size, geographical distribution, regulatory compliance, cultural or organizational complexity, technical complexity, and enterprise disciplines (such as enterprise architecture, strategic reuse, and portfolio management).

20

Factors to be considered when scaling DAD

Team size

Geographical distribution

Domain complexity

Organizational distribution

Technical complexity

Regulatory compliance

CMMi compliance

21

Team Organization in DAD : Medium and large-sized teams

■ Medium-sized team : 10-40 people

■ Large team : 30 or more people

■ Team organization strategies:

Feature teams : used in 80-90% of situations

Component teams: used for another 10-20%

Internal open-source : 1-4%

22

Agility at scale

23

Scaled Agile Framework (SAFe)

Based on Lean-Agile principles

Prescriptive approach to scaling Agile

Suitable for scaling agile in large teams working in

programs or portfolios

24

DAD vs SAFe

Disciplined Agile Delivery Framework Scaled Agile Framework

Provides guidance (Not too much guidance, so not

overly prescriptive)

Prescriptive (tells what to do)

Easier to implement (due to similarities with basic

Agile frameworks, methods)

Needs a specific expertise for implementation;

May not fit in some situations

Evolving (Disciplined Agile 2.0) Evolving (SAFE 4.0)

Lightweight compared to SAFe Heavyweight compared to DAD

Provides foundation for scaling. Suitable for small

to large teams

Scaling framework

Levels: Day, Iteration, Release, Solution, Portfolio Levels: Team, Program, Value Stream, Portfolio,

Team size: 30 or more (in large team) Team size : 50-125 per ART

25

DAD vs SAFe: Roles

Disciplined Agile Framework Scaled Agile Framework

Team Lead Scrum Master

Product Owner Product Owner/Business Owners

Architecture Owner System Architect / Engineer

Team member Team member

- RTE (Release Train Engineer), VTE (Value Train

Engineer)

Stakeholder Customer

Product Management Product Management

26

Disciplined Agile Certification path (Shu-Ha-Ri)

27

Links:

■ http://www.disciplinedagiledelivery.com/blog/

■ http://www.disciplinedagiledelivery.com/agility-at-

scale/large-agile-teams/

28