DAD 3 Hour Tutorial PDF

Disciplined
Agile Delivery Tutorial
Disciplined Agile Delivery

-‐ A Tutorial
Mark Lines
mark@sco7ambler.com
Mark_Lines
© Sco7 Ambler + Associates 1
ObjecEves of this Workshop

•  The book is 500 pages
•  We have 3 hours
•  My assumpEon is that you have basic knowledge of mainstream agile
methods such as Scrum
–  Valid assumpEon?
•  So let’s focus on
–  What is Disciplined Agile Delivery (DAD)?
–  Why do we need it?
–  How does DAD compare mainstream agile methods?
–  How to learn more

Disciplined Agile Delivery Tutorial
IntroducEons
•  A big group so we won’t do individual introducEons
•  Does anyone have something specific that they want to learn about
Disciplined Agile Delivery today?
Criteria for a Disciplined Agile Team

Business Produce a working soluEon on a regular basis
value which provides quanEfiable value to stakeholders

Valida-on Do conEnuous regression tesEng, and be7er yet
take a Test-‐Driven Development (TDD) approach

Collabora-on Work closely with their stakeholders, or a
stakeholder proxy, ideally on a daily basis

Self Are self-‐organizing and work within an
organiza-on appropriate governance framework

Improvement Regularly reflect on, and measure, how they work
together and then act to improve on their findings
in a Emely manner

Exercise: How Agile Are You?

•  Get back into your teams
•  For 5 minutes, rate yourself and your organizaEon on a scale of one to five for the
following criteria:
–  Business value (1 = Infrequent releases, 3 = Quarterly Releases, 5 = Weekly or
be7er releases)
–  ValidaEon (1 = Separate testers do the tesEng, 3 = Developers do some
regression tesEng, 5 = test driven approach)
–  CollaboraEon (1 = We mostly see stakeholders at beginning and end of
project, 3 = We have weekly stakeholder contact, 5 = Daily stakeholder
contact)
–  Self OrganizaEon (1 = Management plans, 3 = The team plans, 5 = The team
plans and is governed in an agile manner)
–  Improvement (1 = We have a project post mortem, 3 = We have regular
retrospecEves, 5 = We have retrospecEves and measure our progress)
Agenda •  A Disciplined Agile Manifesto

•  An Overview of Disciplined Agile Delivery (DAD)
•  DAD Roles
•  The IncepEon Phase
•  The ConstrucEon Phase
•  The TransiEon Phase
•  Governing Disciplined Agile Teams
•  Comparing the DAD and SAFe Frameworks

The Agile Manifesto

We value:
Individuals and interac/ons over processes and tools
Working so4ware over comprehensive documentaEon
Customer collabora/on over contract negoEaEon
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the leh more.

Source: www.agilemanifesto.org
But… DAD Extends Agile Thinking
SoluEons, not just sohware
Stakeholders, not just customers
The organizaEonal ecosystem,

not just development teams

Agenda
•  A Disciplined Agile Manifesto

•  DAD Roles
Disciplined Agile Delivery (DAD)

Disciplined Agile Delivery (DAD) is a process
decision framework

The key characterisEcs of DAD:
–  People-‐first
–  Goal-‐driven
–  Hybrid agile
–  Learning-‐oriented
–  Full delivery lifecycle
–  SoluEon focused
–  Risk-‐value lifecycle
–  Enterprise aware

DAD is a Hybrid Framework
DevOps …and more

Extreme
Outside In Dev. Agile Data
Programming
Unified Process Agile Modeling
Scrum Kanban Lean
DAD leverages proven strategies from several sources,

providing a decision framework to guide your adopEon and
tailoring of them in a context-‐driven manner.
Full Delivery Lifecycle: A High-‐Level View
cru m-‐fall!!
er-‐ s
i s NO T Wat
DAD

DAD Lifecycle: Basic/Agile
DAD Lifecycle: Advanced/Lean

The Phases Disappear Over Time
First release: IncepEon ConstrucEon TransiEon
Second release: I ConstrucEon T
Third release: I ConstrucEon T

.

.

Nth+ releases:
. C C C C
Comparing DAD and Scrum Terminology
DAD Term Scrum Term

IteraEon Sprint
Team lead ScrumMaster*
CoordinaEon meeEng (Daily) Scrum meeEng
RetrospecEve Sprint retrospecEve
Demo Sprint demo
* These roles aren’t completely the same, but close

DAD is Goal-‐Driven
Goal Driven Approach
Advantages
* * OpEon
Goal Issue Disadvantages
Default Op/on
ConsideraEons
Source
Team size
Team structure
Form the Co-‐located
Team members
IniEal Team ParEally dispersed
Geographic distribuEon
Fully dispersed
SupporEng the team
Distributed subteams
Availability

Goal: Develop Common Vision
Context Counts – Tailoring and Scaling Agile

Disciplined agile delivery with one or more complexity factors:
§  Large teams
Agility §  Geographically distributed teams
at §  Compliance
Scale §  Domain or technical complexity
§  Cultural/organizaEonal issues
§  OrganizaEonal distribuEon
•  Delivery focus
Disciplined •  Risk-‐value driven lifecycle
Agile •  Self-‐organizaEon with appropriate governance
Delivery •  Goal driven
•  Enterprise aware
•  ConstrucEon focus
Agile •  Value driven lifecycle
•  Self-‐organizing teams
•  PrescripEve
•  Project team aware

Agenda

•  DAD Roles
Scrum Roles
Scrum Product Team

Master Owner Member

Disciplined Agile Delivery (DAD) Roles
Primary
Roles
Team Lead Product Team Stakeholder Architecture
Owner Member Owner
Secondary
Roles
(for scaling) Independent Specialist Domain Technical Integrator
Tester Expert Expert
Stakeholder
•  Stakeholder is more than a customer
•  Anyone impacted by the outcome of the system
•  Types of stakeholders
–  End users: Users of the system
–  Principals: Decision makers that pay for and put the
system to use
–  Partners: People who make the system work in
producEon
–  Insiders: Members of the development team and people
who provide business and technical services to the team

Product Owner
•  The Stakeholder “proxy”
•  Go-‐to person for informaEon on the soluEon requirements
•  PrioriEzes all work for the team
•  ParEcipant in modeling and acceptance tesEng
•  Has access to expert stakeholders
•  Facilitates requirements envisioning and modeling
•  Educates team in business domain
•  May demonstrate soluEon to key stakeholders
•  Monitors and communicates status to stakeholders
•  NegoEates prioriEes, scope, funding, and schedule
Team Member
•  Is a cross-‐funcEonal, generalizing specialist
•  On small teams every team member is typically a developer,
but on larger teams non-‐developers may appear
•  Volunteers to do any work that allows the team to most
efficiently delivery the work commi7ed to for the iteraEon
•  Seeks to both learn about other specialEes as well as coach
others on their own specialty
•  Goes to the product owner for domain informaEon and
decisions
•  Works with the architecture owner to evolve the
architecture
•  Follows enterprise convenEons and leverage and enhance
the exisEng infrastructure

Team Lead
•  Responsible for the effecEveness and conEnuous improvement
of the team’s process
•  Facilitates close collaboraEon between team members
•  Keeps the team focused on the project vision and goals
•  Removes impediments for the team and escalates
organizaEonal impediments
•  Protects the team from interrupEons and external interferences
•  Maintains honest communicaEon between everyone on the
project
•  Coaches others in the use of agile pracEces
•  Prompts the team to discuss and think through issues when
they are idenEfied
•  Facilitates decision making (but does not make decisions or
mandate internal team acEvity)
Architecture Owner
•  Guides the creaEon and evoluEon of the soluEon’s
architecture
•  Mentors and coaches team members in architecture
pracEces and issues
•  Understands the architectural direcEon and standards
of your organizaEon and ensures that the team
adheres to them
•  Ensures the system will be easy to support by
encouraging appropriate design and refactoring
•  Ensures that the system is integrated and tested
frequently
•  Has the final decision regarding technical decisions,
but doesn’t dictate them
•  Leads the iniEal architecture envisioning effort

InteracEng with Other Teams

•  Other agile delivery teams
•  Other non-‐agile development teams
•  Quality Assurance (QA) and tesEng
•  Technical writers
•  User Experience (UX) experts
•  Enterprise architects
•  Governance body
•  Project Management Office (PMO)
•  Data management/administraEon
•  Reuse engineers
Agenda

•  DAD Roles

The IncepEon Phase
IncepEon Phase Goals

•  IncepEon Phase
–  Form iniEal team
–  Develop common project vision
–  Align with enterprise direcEon
–  Explore iniEal scope
–  IdenEfy iniEal technical strategy
–  Develop iniEal release plan
–  Form work environment
–  Secure funding
–  IdenEfy risks
•  Ongoing
–  Fulfill the project mission
–  Improve team process and environment
–  Grow team members
–  Leverage and enhance exisEng infrastructure
–  Address risk

The IncepEon Phase
Industry Data: IncepEon AcEviEes
IniEal Requirements Modeling
IniEal Architecture Modeling
JusEfy Project
IniEal EsEmate
High-‐Level Release Schedule
65% 70% 75% 80% 85% 90% 95%
Source: Ambysoh 2009 Agile Project IniEaEon Survey


Goal: Align With Enterprise DirecEon
IniEal Requirements

Goal: Explore the IniEal Scope
Choosing the Appropriate Level of IniEal Detail

•  BRUF (detailed specificaEons)
•  Requirements envisioning (lightweight specificaEons)
•  Goals driven
•  No modeling at all

Work Item Management:

Work Item Stack – Ordered by Risk and Value
Goal: IdenEfy IniEal Technical Strategy

IdenEfy Technical Unknowns/Risks

•  As you idenEfy your iniEal technical strategy you are likely to idenEfy
issues or complexiEes that you don’t know the answer for
•  For example:
–  You believe you can access data from a legacy system, but aren’t sure
of the details
–  Will a new technology pla{orm will work as the vendor claims?
–  You have a requirement for a given level of throughput, e.g. 5,000
transacEons a second
–  Your team has never worked with your organizaEon’s web services
framework before
•  You will want to explore these risks early in ConstrucEon by:
–  Proving the architecture via working code
–  Architecture spikes to explore an aspect of your soluEon
IniEal Release Planning

•  The vast majority of agile teams invest some iniEal Eme in planning their release
•  ConsideraEons:
–  Schedule
–  Cost
–  Work allocaEons
–  How many releases and Eming of each?
–  Length of iteraEons?
•  73% of agile teams produce an iniEal high-‐level esEmate, and 18% of agile teams
produce a detailed one*
•  77% of agile teams produce an iniEal high-‐level schedule, and 12% of agile teams
produce a detailed one*
* Source: Ambysoh 2009 Agile Project IniEaEon Survey


Goal: Develop IniEal Release Plan
DepicEng your Release Schedule with a Gan7 Chart

Examples of Release Pa7erns
Goal: IdenEfy Risks

Choosing IteraEon Lengths

The average construcEon iteraEon length is 2.3 weeks*
1 week or less 15%
2 weeks 51%
3 weeks 15%
4 weeks 10%
> 4 weeks 2%
HeurisEcs:
•  Shorter is generally be7er than longer
•  Teams at scale may require slightly longer iteraEons
* Source: Ambysoh November 2010

Agile State of the Art Survey
IncepEon
Goal: Form
the IniEal
Team

Goal: Form Work Environment
Organizing Physical Work Environments
•  Dedicated space •  Large table

•  Significant whiteboard space •  Wall space to a7ach paper
•  Digital camera •  Projector
•  Reference books
•  Agile modeling supplies •  Food, toys…
•  A bookshelf or storage cabinet

Examples of Room Layouts
Infrastructure/DevOps
Team Lead Architecture Owner

Task Board
Independent Testers
Product Owner
Project ‘A’ Project ‘B’
Milestone: Bringing Stakeholders to Agreement

around your Vision
•  IncepEon is complete and you can enter the ConstrucEon phase when:
–  Your stakeholders agree that it makes sense to proceed based upon the
achievable scope, schedule, budget, constraints, and other criteria related to
your business case
–  The risks have been idenEfied and seem tolerable
–  There is agreement on using a minimalist and agile process for building the
soluEon
–  The team and environment have been set up or are in the process of being so,
that supports collaboraEve teamwork
–  The process and governance strategies have been agreed to by both your
team and your stakeholders

Goal: Secure Funding
Goal: Develop Common Vision

What’s in a Project Vision?

•  Also known as project charter or business case
•  Typically outlines:
–  Goals of the project team and who is on it
–  High-‐level scope of the current release
–  Technical overview of the soluEon
–  Outline of the plan to do the required work
–  Could include feasibility informaEon
•  Could also describe:

–  DescripEon of business problem being addressed
–  High-‐level schedule and esEmates
–  key milestones
–  Stakeholders
–  Funding models
–  Project risks and constraints
–  Process/method used (eg DAD), governance strategy
–  Key assumpEons
IncepEon Pa7erns and AnE-‐Pa7erns

•  Pa7erns that can increase your likelihood of success
–  Have a short but sufficient IncepEon phase
–  Ranged esEmates
–  Minimal but sufficient documentaEon
•  AnE-‐pa7erns
–  No support for skills development
–  No support for dedicated faciliEes
–  AutocraEc project management pracEces
–  Jumping into ConstrucEon
–  Overly detailed work products
–  Analysis paralysis

Agenda
•  DAD Roles
ConstrucEon Phase Goals

•  ConstrucEon Phase
–  Produce a potenEally consumable soluEon
–  Address changing stakeholder needs
–  Move closer to deployable release
–  Improve quality
–  Prove architecture early
•  Ongoing
–  Address risk

The ConstrucEon Phase
The ConstrucEon phase

A ConstrucEon IteraEon
A Typical Day of ConstrucEon

IniEaEng a ConstrucEon IteraEon

•  Agile planning is different from tradiEonal
planning
–  Detailed planning occurs throughout
the project, typically an iteraEon at a
Eme
–  The team self organizes and plans its
own work
–  Team coordinaEon occurs daily
–  The high-‐level release plan is updated
appropriately throughout the project
•  The iteraEon starts with a short planning

workshop
–  IteraEon planning
–  IteraEon modeling
Visualizing Your Plan

Goal: Prove Architecture Early
The Risk-‐Value Lifecycle

CriEcal Agile PracEces

•  ConEnuous documentaEon
•  Non-‐solo work
•  IteraEon burndown charts
•  Change management
•  ConfiguraEon management
•  Architectural spikes
•  Test-‐driven development (TDD)
•  ConEnuous integraEon (CI)
•  ConEnuous deployment (CD)
•  Look-‐ahead planning
•  Look-‐ahead modeling
•  Parallel independent tesEng
•  Reviews

EsEmaEng: Ranged Release Burndowns

•  A ranged esEmate of number of iteraEon required to complete work
•  Range of uncertainty decreases as project progresses
Demonstrate the SoluEon to Key Stakeholders
•  IteraEon demonstraEon
•  On-‐demand demonstraEons
•  All hands demonstraEons
•  None

Learn from Your Experiences

•  RetrospecEves
•  Structured surveys
•  Measured improvement
•  Project post mortem
•  Ad hoc process improvement
•  None
Deploy your Current Build

•  Deployment to appropriate environments:
–  DemonstraEon
–  Pre-‐producEon tesEng
–  ProducEon

Determine Strategy Moving Forward

•  Sources
–  Input from your iteraEon demo
–  The team
–  Usage staEsEcs
•  How to proceed?*

–  Persevere with the current strategy
–  Run a split test
–  Pivot in a new direcEon
–  Cancel the project
•  Deciding how to proceed

–  Team meeEng
–  Lightweight milestone review
–  Formal milestone review
* From ‘The Lean Startup’, Eric Ries

ConstrucEon Pa7erns
•  The team can be reliably depended on to
demonstrate increments of sohware at the end of
each iteraEon
•  Team members finish their tasks ahead of schedule

and ask to help others with their tasks
•  IteraEon dates never move
•  Any stakeholder can expect to see a demonstraEon of

working sohware at any Eme

ConstrucEon AnE-‐Pa7erns
•  A work item list that is too big to easily manage and comprehend
•  Ina7enEon to risk miEgaEon
•  Assuming that the architecture will work without proving it with
code
•  Assuming that an iteraEve approach alone ensures that you will
build the right soluEon in an effec%ve manner
•  One or more of your team members are working on other projects
in addiEon to yours
•  A work item isn’t done
•  Last iteraEon we planned for X points but delivered Y (less than X),
but we sEll commit to X this iteraEon
•  During the iteraEon we missed some tasks when iteraEon planning
•  During the iteraEon we realized we missed a requirement that
another depends on
•  During iteraEon planning sessions, the product owner is
reprioriEzing the backlog or is uncertain of requirement details
•  Defect counts are increasing in each iteraEon
Agenda

•  DAD Roles

The TransiEon phase
The TransiEon Phase

TransiEon Phase Goals

•  ConstrucEon Phase
–  Ensure the soluEon is consumable
–  Deploy the soluEon
•  Ongoing
–  Address risk
Planning for the TransiEon Phase

•  Some pre-‐planning acEviEes during Construc-on ensure that the team is
prepared going into TransiEon
–  Is paperwork required prior to deployments?
•  E.g. Request For Change (RFCs)
–  Do elements of producEon infrastructure need to be procured and
setup?
–  Are there final user acceptance tesEng tasks to be done?
–  Do disaster recover plans need to be updated?
–  Do changes need to be coordinated with other projects?
–  Is there support documentaEon required?
–  Are sign-‐offs required?
–  Does your team need to be on call?

Goal: Ensure SoluEon is Consumable
Goal: Deploy the SoluEon

TransiEon Phase AnE-‐Pa7erns

•  Thinking TransiEon is a “hardening” phase
•  Not having a producEon like environment for integraEon,
acceptance, and deployment tesEng
•  Not having an agreed upon set of entry criteria for going “live”
•  Requests for new funcEonality
•  Release the system to unprepared users
•  Lengthy integraEon and user acceptance tesEng (UAT) cycle in
TransiEon
•  Transferring responsibility for maintaining the system to a
maintenance group
•  Moving all of your developers to another project at the end of
ConstrucEon
•  Not invesEng in stakeholder training
•  Believing that installaEon is going to be easy
Agenda

•  DAD Roles

Governance Should Address a Range of Issues

•  Team roles and responsibiliEes
•  Individual roles and responsibiliEes
•  Decision rights and decision making process
•  Governing body
•  ExcepEons and escalaEon processes
•  Knowledge sharing processes
•  Metrics strategy
•  Risk miEgaEon
•  Reward structure
•  Status reporEng
•  Audit processes
•  Policies, standards, and guidelines
•  ArEfacts and their lifecycles
Aspects of EffecEve Agile Governance

•  Trust and respect are the foundaEon of effecEve governance
•  Be stakeholder driven
•  CollaboraEvely define your governance strategy
•  Be transparent
•  MoEvate, don’t dictate
•  Enable, don’t enforce
•  OpEmize the “IT whole”, not the “governance part”
•  OpEmize corporate performance
•  CollaboraEvely set reasonable guidance
•  CollaboraEvely define rights and responsibiliEes
•  Be suitable to task
•  Automate wherever possible

DAD Milestones
Milestone Fundamental Ques-on Asked
Stakeholder consensus Do stakeholders agree with your strategy?
Proven architecture Can you actually build this?
Project viability Does the project sEll make sense?
Sufficient funcEonality Does it make sense to release the current soluEon?
ProducEon ready Will the soluEon work in producEon?
Delighted stakeholders Are stakeholders happy with the deployed soluEon?
DAD PracEces that Support Governance

•  “Standard” agile pracEces:
–  CoordinaEon meeEng
–  IteraEon demonstraEons
–  All-‐hands demonstraEons
–  RetrospecEve
–  InformaEon radiators/Visual management
•  Disciplined pracEces:
–  Explicit light-‐weight milestones
–  Follow enterprise development guidelines
–  Work closely with enterprise professionals
–  Development intelligence via automated
dashboards

Measuring Agile Teams

•  Talk to people; don’t manage to the metrics
•  Measure teams, not individuals
•  Collect several metrics
•  Trends are be7er than scalar values
•  Empirical observaEon is important but limited
•  Prefer automated metrics
•  Some metrics must be gathered manually
•  Prefer pull versus push reporEng
•  Beware scienEfic facades
•  Measure the value of your metrics program
•  Be prepared to educate people
•  The value of many metrics diminishes over Eme
•  If you collect no metrics at all you’re flying blind
•  If you collect too many metrics you may be flying blinded
PotenEal Metrics
•  AcceleraEon •  Lifecycle traceability

•  AcEvity Eme •  Net present value (NPV)
•  Age of work items •  Ranged release burndown
•  Blocking work items •  Release burndown
•  Build health •  Return on investment (ROI)
•  Business value delivered •  Risk miEgaEon
•  Change cycle Eme •  Stakeholder saEsfacEon
•  Code quality •  Team morale
•  Defect density •  Test coverage
•  Defect trend •  Time invested
•  Effort/cost projecEon •  Velocity
•  IteraEon burndown

Agenda
•  An Overview of Disciplined Agile Delivery
(DAD)
•  DAD Roles
Scaled Agile Framework™ Big Picture
Con
IncepEon

ConstrucEon Tr. ConstrucEon TransiEon

Sco7 Ambler + Associates
Por{olio and Program

management with SAFe
Team success through

“Disciplined” agile
delivery at the project
level

© Scott Ambler + Associates 94


Disciplined Agile Delivery (DAD) is a process
decision framework

The key characterisEcs of DAD:
–  People-‐first
–  Goal-‐driven
–  Hybrid agile
–  Learning-‐oriented
–  Full delivery lifecycle
–  SoluEon focused
–  Enterprise aware
DAD Lifecycle: Basic/Agile

DAD is Goal-‐Driven
Domain
Scaling/Tailoring Complexity Factors Complexity

Straightforward

Geographic Team
Very complex
Distribu-on Size
motivates
mo Technical
Co-located 2 %va
tes
Complexity
Global

1000s
Straightforward

mo
va
rie
Very complex
%
mo%vates
va
s b
tes
y
Organiza-onal Team
Compliance
Distribu-on Culture
affects

Single varies by Agile
None

Outsourcing Rigid
Life critical

s
ect
s
ect
aff
aff affects
Project Type
Organiza-onal

Culture
Multiple Release

Single Release Agile

Rigid


Disciplined Agile Delivery:

The FoundaEon for Scaling Agile
OrganizaEonal OrganizaEonal Domain

Team Culture
DistribuEon Culture Complexity
Geographic Technical
Team Size Compliance
DistribuEon Complexity
Outside In Dev. “TradiEonal” And more…
Unified Process Agile Modeling
Scrum Kanban Lean
DAD leverages proven strategies from several sources,

providing a decision framework to guide your adopEon and
tailoring of them in a context-‐driven manner.
Discussion: What SEll Puzzles You?
•  This tutorial has potenEally

presented you with a lot of
new ideas
•  It can be incredibly difficult to
take in all of this material at
once
•  So… is there anything that sEll
puzzles you about Disciplined
Agile Delivery (DAD)?

Disciplined Agile CerEficaEon

www.DisciplinedAgileConsorEum.org

Disciplined Agile Yellow Belt
–  IndicaEon that the person is new to disciplined agile but eager to learn
–  Beginner cerEficaEon
Disciplined Agile Green Belt

–  IndicaEon that the person is striving to be a professional
–  PotenEal to be a junior coach
–  Intermediate cerEficaEon
Disciplined Agile Black Belt

–  IndicaEon that the person is an expert
–  Ohen a senior coach, instructor, or agile transformaEon lead
–  Expert cerEficaEon
Give Feedback on the Sessions
1 Sign In: www.eclipsecon.org
2 Select Session Evaluate

3 Vote
102
© Sco7 Ambler + Associates

Thank You!
mark@sco7ambler.com
@mark_lines

DisciplinedAgileDelivery.com
DisciplinedAgileConsorEum.org
Sco7WAmbler.com
Recommended Resources

DAD 3 Hour Tutorial PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DAD 3 Hour Tutorial PDF

Uploaded by

Copyright:

Available Formats

Disciplined

Agile Delivery Tutorial

Disciplined Agile Delivery

© Sco7 Ambler + Associates 1

ObjecEves of this Workshop

© Sco7 Ambler + Associates 2

© Sco7 Ambler + Associates 1

© Sco7 Ambler + Associates 3

Criteria for a Disciplined Agile Team

© Sco7 Ambler + Associates 4

© Sco7 Ambler + Associates 2

Exercise: How Agile Are You?

© Sco7 Ambler + Associates 5

Agenda • A Disciplined Agile Manifesto

© Sco7 Ambler + Associates 3

The Agile Manifesto

But… DAD Extends Agile Thinking

SoluEons, not just sohware

Stakeholders, not just customers

The organizaEonal ecosystem,

© Sco7 Ambler + Associates 8

© Sco7 Ambler + Associates 4

• A Disciplined Agile Manifesto

© Sco7 Ambler + Associates 9

Disciplined Agile Delivery (DAD)

© Sco7 Ambler + Associates 10

© Sco7 Ambler + Associates 5

DAD is a Hybrid Framework

DevOps …and more

Scrum Kanban Lean

DAD leverages proven strategies from several sources,

© Sco7 Ambler + Associates 11

Full Delivery Lifecycle: A High-­‐Level View

© Sco7 Ambler + Associates 12

© Sco7 Ambler + Associates 6

DAD Lifecycle: Basic/Agile

© Sco7 Ambler + Associates 13

DAD Lifecycle: Advanced/Lean

© Sco7 Ambler + Associates 14

© Sco7 Ambler + Associates 7

The Phases Disappear Over Time

First release: IncepEon ConstrucEon TransiEon

Second release: I ConstrucEon T

Third release: I ConstrucEon T

© Sco7 Ambler + Associates 15

Comparing DAD and Scrum Terminology

DAD Term Scrum Term

* These roles aren’t completely the same, but close

© Sco7 Ambler + Associates 16

© Sco7 Ambler + Associates 8

DAD is Goal-­‐Driven

© Sco7 Ambler + Associates 17

Goal Driven Approach

© Sco7 Ambler + Associates 18

© Sco7 Ambler + Associates 9

Goal: Develop Common Vision

© Sco7 Ambler + Associates 19

Context Counts – Tailoring and Scaling Agile

© Sco7 Ambler + Associates 20

© Sco7 Ambler + Associates 10

• A Disciplined Agile Manifesto

© Sco7 Ambler + Associates 21

Scrum Product Team

Agenda •  A Disciplined Agile Manifesto

•  A Disciplined Agile Manifesto

Full Delivery Lifecycle: A High-‐Level View

DAD is Goal-‐Driven

•  A Disciplined Agile Manifesto

•  A Disciplined Agile Manifesto

High-‐Level Release Schedule

•  Dedicated space •  Large table