Disciplined Agile Delivery: Extending Scrum to the Enterprise

MK
PM Half day Tutorial
11/11/2013 1:00 PM

"Disciplined Agile Delivery:
Extending Scrum to the
Enterprise"
Presented by:
Scott Ambler
Scott Ambler + Associates

Brought to you by:

340 Corporate Way, Suite 300, Orange Park, FL 32073
888 268 8770 904 278 0524 sqeinfo@sqe.com www.sqe.com

Scott Ambler
Scott W. Ambler + Associates
Scott Ambler works with organizations worldwide to help them improve
their software processes. Scott is the founder of the Agile Modeling, Agile
Data, Disciplined Agile Delivery, and Enterprise Unified Process
methodologies, and creator of the Agile Scaling Model. A senior
contributing editor with Dr. Dobb’s Journal, Scott is the coauthor of twentyone books, including Refactoring Databases, Agile Modeling, Agile
Database Techniques, The Object Primer 3rd Edition, The Enterprise
Unified Process, and Disciplined Agile Delivery. Visit his home
page ScottAmbler.com and blog.

Disciplined Agile Delivery: Extending Scrum to
the Enterprise
Scott W. Ambler
Senior Consulting Partner
scott [at] scottambler.com
@scottwambler
© Scott Ambler + Associates

1

We’re going to cover a
lot of ground

2

Ask questions
at any time!


3

Agenda
•
•
•
•
•
•
•
•

Disciplined Agile Delivery (DAD)
You Have Choices
What it Means to Scale Agile Delivery
Governing Agile Teams
Agile People at Scale
Agile Practices at Scale
Enterprise Agile
Parting Thoughts


4

Disciplined Agile Delivery


5

Group Exercise: Sharing Agile Experiences
•
•
•

•
•

Organize into teams of 4-6 people
Take a few minutes to introduce yourselves to one another
For 5 minutes, discuss within the team:
– Practical experiences on agile teams
– What types of activities you do to initiate the project? (e.g. Did you do any
initial modeling or planning? Did you need to get provide estimates go get
funding? Other activities?) How long did it take?
– What activities did you do during construction? (e.g. How did you approach
documentation? Planning? Testing? Architecture?)
– What did you need to do to deploy/release your solution into production?
How long did it take?
Someone needs to be a spokesperson for your team
A spokesperson will share a few key learnings with the larger group


6

Important, Empirical Observations

Solutions, not just software

Stakeholders, not just customers

The organizational ecosystem,
not just development teams

7

Disciplined Agile Delivery (DAD) is a process
decision framework
The key characteristics of DAD:
– People-first
– Goal-driven
– Hybrid agile
– Learning-oriented
– Full delivery lifecycle
– Solution focused
– Risk-value lifecycle
– Enterprise aware


8

DAD is a Hybrid Framework

SAFe

DevOps

…and more

Outside In Dev.
“Traditional”
Agile Data
Extreme
Unified Process
Agile Modeling
Programming
Scrum
Kanban
Lean

DAD leverages proven strategies from several sources,
providing a decision framework to guide your adoption and
tailoring of them in a context-driven manner.


9

A High Level Lifecycle


10

Scrum Construction Lifecycle

A good start…

11

A Scrum Delivery Lifecycle

…but this is how agile teams actually work…

12

Unbranded Agile Delivery Lifecycle

…and it’s time to abandon the branding.

13

Governed Delivery Lifecycle

Disciplined agile teams are guided by senior management…

14

Disciplined Agile Delivery: Basic Lifecycle

…and realize they work in an organizational ecosystem.

15

Disciplined Agile Delivery: Lean Lifecycle

DAD doesn’t prescribe a single lifecycle…

16

The Phases Disappear Over Time
First release:

Inception

Second release:
Third release:

I
I

Construction
Construction
Construction

Transition
T

T

.
.
.

Nth+ releases:

C T C T C T C T

…and promotes continuous learning and improvement.

17

Disciplined Agile Delivery: Lean Continuous Delivery
Lifecycle

A good
end goal

18

Primary Roles on DAD Teams
•

Team Lead
– Agile process expert, keeps team focused on
achievement of goals, removes impediments

•

Product Owner
– Owns the product vision, scope and priorities of the
solution

•

Architecture Owner
– Owns the architecture decisions and technical
priorities, mitigates key technical risks

•

Team Member
– Cross-functional team members that deliver the
solution

•

Stakeholder
– Includes the customer but also other stakeholders such
as Project Sponsor, DevOps, architecture, database
groups, governance bodies


19

Governance is Built Into DAD

•

Governance strategies built into DAD:
– Light-weight milestone reviews
– “Standard” opportunities for increased visibility and to steer the team
provided by agile
– Enterprise awareness
– Robust stakeholder definition


20

DevOps Through the DAD Lifecycle
O&S staff
stakeholders in
initial modeling
sessions

Inception

Initial release
planning
includes
deployment

O&S staff key
Dev team
decision makers
implements O&S
regarding production
oriented
readiness
requirements

O&S staff
stakeholders
throughout
construction

Construction

Transition
planning
throughout
construction

Transition

Deployment into
production

Support staff
observes
stakeholder
satisfaction levels

O&S = Operations & Support

21

DAD Teams Are Enterprise Aware
•

DAD teams strive to leverage
and enhance the existing
organizational eco system
wherever possible

•

Implications:
– Work closely with
enterprise groups
– Follow existing roadmap(s)
where appropriate
– Leverage existing assets
– Enhance existing assets


22

What Does it Mean to Be
Disciplined?
•

•

In general, it requires discipline to
follow many agile practices and
philosophies
But, it also requires discipline to:
– Reduce the feedback cycle
– Learn continuously
– Deliver solutions incrementally
– Be goal driven
– Streamline Inception and
Transition efforts
– Adopt agile governance strategies


23

You Have
Choices


24

Strategies for Initial Estimating
•
•
•
•
•
•

Formal point counting
Planning poker (wide-band delphi)
Similar sized items
Educated guess by the team
Educated guess by an experienced individual
Cost/schedule set by the stakeholders


25

Strategies for Funding Projects
Fixed price/cost

Stage-gate
funding
Time and
materials (T&M)
Low T&M
plus delivery
bonuses
Continuous/Drip

26

Group Exercise: Exploring Project Funding
• Choose one of the funding strategies
from the previous slide

For five minutes, discuss the implications of the strategy:
• How will the team behave regarding changing
requirements?
• How will the team behave regarding schedule slippage?
• How will quality of the end product potentially be
affected?
• What risks are being placed on IT?
• What risks are being placed on the business?


27

Disciplined Agilists Take a Goal Driven Approach

Goal

*

Issue

*

Option
Default Option

Advantages
Disadvantages
Considerations

Indicates a preference for
the options towards the top
Explore the Initial
Scope
Form the
Initial Team
Address Changing
Stakeholder Needs

Source
Team size
Team structure
Team members
Geographic distribution
Supporting the team
Availability


Co-located
Partially dispersed
Fully dispersed
Distributed subteams

28

Goal: Secure Funding


29

Goal – Secure Funding


30

Goal – Secure Funding (cont.)


31

Strategies for Capturing Requirements Detail
•
•
•
•

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


32

Strategies for Functional Requirements


33

Goal: Explore the Initial Scope


34

Strategies for Change Management

Formal Change Management


35

Goal: Address Changing Stakeholder Needs


36

DAD is Process Goal-Driven


37

Scaling Agile

38

What Does it Mean to Scale Agile?
Team Size
Two

Hundreds
Geographic Distribution

Co-located

Global
Organizational Distribution

Single division

Outsourcing
Compliance

None

Life critical
Domain Complexity

Straightforward

Very complex
Technical Complexity

Straightforward

Very complex
http://disciplinedagiledelivery.wordpress.com/2013/03/15/sdcf/

39

Scaling Requires…
•

•

•
•

•

•

A disciplined approach
– Full delivery lifecycle
– Enterprise awareness
– Goal-driven approach
A bit more up-front thinking
– Explore the initial scope a bit
deeper
– Identify the initial technical
strategy in a bit more detail
More sophisticated coordination
– Individuals and interactions
More sophisticated governance
– The greater the risk, the greater
the need for effective
governance
More sophisticated validation
– Teams at scale are typically
tackling harder problems
More sophisticated tooling


40

Scaling From a Solid Foundation is Easier
•

With a DAD-based approach, scaling becomes straightforward because a handful
of process goals take the brunt of the tailoring:
– Explore initial scope
– Identify initial technical strategy
– Move closer to a deployable release
– Coordinate activities


41

Governing
Disciplined
Agile Teams


42

Some Bold Claims Regarding Governance
Claim #1: Agile teams are being governed today
Claim #2: In many organizations the governance strategy is badly
misaligned with agile
Claim #3: You deserve to be governed effectively
Claim #4: When you provide a coherent governance strategy to
senior management you are much more likely to be governed
effectively


43

Governance Should Address a Range of Issues
•
•
•
•
•
•
•
•
•
•
•
•
•

Team roles and responsibilities
Individual roles and responsibilities
Decision rights and decision making process
Governing body
Exceptions and escalation processes
Knowledge sharing processes
Metrics strategy
Risk mitigation
Reward structure
Status reporting
Audit processes
Policies, standards, and guidelines
Artifacts and their lifecycles


44

Why is Governance Important?
•
•
•
•

Sustain and extend your IT strategies and objectives, which in turn should reflect
your corporate strategies and objectives
Determine how the company will execute its strategy by selecting and prioritizing
the most valuable initiatives to undertake
Empower teams to carry out their work
Help to ensure that delivery teams:
– Regularly and consistently create real business value
– Provide appropriate return on investment (ROI)
– Deliver consumable solutions in a timely and relevant manner
– Work effectively with their project stakeholders
– Work effectively with their IT colleagues
– Adopt processes and organizational structures that encourage successful IT
solution delivery
– Present accurate and timely information to project stakeholders
– Mitigate the risks associated with the project


45

Why Traditional Governance Strategies Won’t Work

Traditional assumptions that conflict with agile:
– You can judge team progress from generation of artifacts
– Delivery teams should work in a serial manner
– You want teams to follow a common, repeatable process
– Projects should be driven by senior IT management


46

Exercise: I Don’t Want to Be Governed
• This is a role playing exercise
• Pair up
• One person is an agile developer who doesn’t
believe that governance is necessary
• The other person is a senior manager who will
argue for the need for agile governance
• For five minutes, have a back and forth
discussion with your pair
• At the end, identify three solid points that favor
governing agile teams and three solid points
against doing so


47

Principles of Agile Governance

Collaboration over conformance
Enablement over inspection
Continuous monitoring over quality gates
Transparency over management reporting


48

DAD Milestones

Milestone

Fundamental Question Asked

Stakeholder vision

Do stakeholders agree with your strategy?

Proven architecture

Can you actually build this?

Project viability

Does the project still make sense?

Sufficient functionality

Does it make sense to release the current solution?

Production ready

Will the solution work in production?

Delighted stakeholders

Are stakeholders happy with the deployed solution?

49

DAD Practices that Support Governance
•

“Standard” agile practices:
– Coordination meeting
– Iteration demonstrations
– All-hands demonstrations
– Retrospective
– Information radiators/Visual management

•

Disciplined practices:
– Explicit light-weight milestones
– Follow enterprise development guidelines
– Work closely with enterprise professionals
– Development intelligence via automated
dashboards


50

Agile
People at
Scale


51

Secondary Roles on DAD Teams
•

“The secondary” DAD roles typically occur at scale

•

Specialist
– Someone in a specialist role, such as business analyst,
program manager, or enterprise architect

•

Domain Expert
– Someone with deep knowledge of the domain, such as a
legal expert or marketing expert who is brought in as
needed to share their expertise

•

Technical Expert
– Someone with deep technical knowledge, such as a
security engineer or user experience (UX) professional,
whose help is needed for a short period

•

Independent Tester
– A test/quality professional outside of the team who
validates their work.

•

Integrator
– Someone responsible for the operation of the overall
team build


52

Large Teams
Organizational options:
• Feature teams: A
subteam works on a
feature from end to
end.
• Component teams: A
subteam does all the
work for a specific
component.
• Internal open source: A
component is
developed via open
source techniques.


53

Leadership Teams

•

For large teams there are several coordination subteams:
– Architecture Owners – Responsible for technical coordination
– Product Owners – Responsible for requirements coordination
– Project Management – Responsible for team coordination and management

•

How it works:
– Early in the project the respective visions are agreed to by key members of each
coordination team (plus others)
– Throughout the project these teams coordinate their respective issues on a regular basis
with one another

54

Geographically Distributed/Dispersed Teams


55

Group Exercise: Enterprise Teams
• Get back together into your groups
• Take 5 minutes to discuss:
– How do your agile delivery teams interact with
enterprise teams that provide cross-team services?
– Consider enterprise teams such as:
• Enterprise Architecture
• Portfolio management
• Reuse/asset management
• Infrastructure/operations and support
• Data management


56

Pattern: Enterprise Team
•

Individuals are members of both a delivery team and
an enterprise team

•

Common examples include:
– Architecture Ownership Team (Enterprise
Architecture)
– Product Ownership Team (Product Management)
– Product Delivery Office (Portfolio Management)

•

The delivery teams determine who will be in the
enterprise role for them

•

Delivery
Team

Potential scheduling challenges for the people in the
enterprise roles due to multi-team commitments

•

Enterprise
Team

The leaders of each enterprise team may be a full time
position


57

Enterprise Team Example:
Enterprise Architecture
•

•

•

•

Responsible for developing
the architecture/technology
roadmap for your
organization
Delivery teams will
determine who the
architecture owner (AO) is,
and that person becomes
part of the AO team
The AO team meets regularly
to evolve the roadmap based
on the hands-on learnings
from the AOs
Often called the enterprise
architecture team


58

Pattern: Specialized Services Team
•

Specialized services teams fulfill requests from
delivery teams

•

Common examples of specialized services:
– Infrastructure/network
– Database administration
– Security
– Facilities

•

The specialized services team will often have a
service level agreement (SLA) that the work to

•

Specialized
Service
Team

Delivery
Team

Service

Potential for the services team to become a
bottleneck

•

Service Request

They may supply specialists on a short term basis to
some delivery teams


59

Services Team Example:
Database Administration (DBA) Team

•
•

Responsible for supporting database development and database operation in
production
The delivery team submits a request, the DBA Team prioritizes it and then fulfills it


60

Communities of Excellence (CoE)
•

A CoE focuses on sharing and enhancing skills within a group of like-minded
people organized on a volunteer basis

•

Individuals will choose to join zero or more CoEs

•

Potential CoEs:
– Agile
– Architecture
– Testing
– Leadership
– Security

•

CoEs may adopt common strategies include internal discussion forums, training
sessions, “brownbag lunches”, and even certification.


61

Release train

Multiple “backlogs”

IT intelligence

Development intelligence

Continuous documentation

Requirements envisioning

Consumable solutions

API first

Continuous architecture

“Scaling” Practices
Work item pools
Work item lists

Parallel independent testing
Test suite API
Architecture envisioning

Active stakeholder participation

Continuous deployment


62

“Common” Agile Practices that Support Scaling
•

•
•
•
•

Continuous Coordination
– Coordination meetings – e.g. “Daily stand ups”
– Development intelligence
– Demos
Short iterations/sprints
Regularly producing a potentially consumable solution – e.g. Potentially shippable
software in Scrum
Continuous integration
– Better yet continuous deployment
Agile planning
– Initial high-level release planning
– Just in time (JIT) detailed planning – e.g. Iteration/sprint planning
– Look-ahead planning


63

Agile Modeling’s Best Practices


64

API First/Test Suite API
•

When there are many people developing a shared set of components you should
invest time at the beginning of the project to identify the components and define
the interfaces to those components
– “Component” is used to indicate any shared technical resource such as a set of
web services, a shared data source, a programming library, a framework, and
so on
– Many teams will choose to write the interface stubs and tests at this time so
that they have something to integrate

•

Effectively a rigorous application of Agile Model’s Architecture Envisioning and Just
Barely Good Enough practices

•

API First is a practice of The Eclipse Way

•

Also known as Contract Model in Agile Modeling


65

Continuous Deployment (CD)


66

Parallel Independent Testing


67

Multiple Backlogs

• There are dependencies between work
items (including requirements)
• When large teams are separated into
subteams, and if each subteam has its own
work items, then these dependencies need
to be managed
• Product Owners are responsible for the
work items, therefore they need to
coordinate dependencies with one another


68

Enterprise Agile

69

IT is More than Solution Delivery

Solution Delivery

Operations and
Support

People
Management

Portfolio
Management

Programme
Management

IT Governance

Enterprise
Architecture

Asset
Management

Information
Management


70

Your Organization is More Than IT

Information
Technology
Department

Your Organization


71

Agile/Scrum is a Good Starting Point

•
•
•
•
•

Construction focus
Value driven lifecycle
Self-organizing teams
Prescriptive
Project team aware


72

DAD Solidifies the Foundation

•
•
•
•
•

Delivery focus
Risk-value driven lifecycle
Self-organization with appropriate governance
Goal driven
Enterprise aware


73

Agility at Scale
•
•
•
•
•
•

Large teams
Geographically distributed teams
Compliance
Domain or technical complexity
Cultural issues
Organizational distribution


74

Individuals Become Agile

Individuals to be able to become a
truly agile practitioner within the
evolving context of the situation
that they face
They will require training,
education and coaching


75

Teams Build Solutions

Teams will self organize their
work strategy, their structure,
and their collaboration paths to
reflect the context of the
situation that they find
themselves in
They will require guidance to do
so effectively


76

IT Departments Become Agile
IT departments are often sophisticated
entities with teams addressing a wide
range of situations and a wide range of
goals
Agile delivery teams are just part of the
overall mix, as are operations teams,
architecture teams, portfolio
management teams, and many more
IT organizations will need to adopt a
wide range of strategies that reflect the
challenges that they face


77

The Agile Enterprise
An agile enterprise has two key characteristics*:
• Response ability – The physical ability to act
is derived from two sources, an
organizational structure that enables change
and an organizational culture that facilitates
change
• Knowledge management – The intellectual
ability to find appropriate things to act on
and encompasses both top-down knowledge
portfolio management (KPM) and bottom-up
collaborative learning

* Response Ability by Rick Dove, 2001.

78


79


80

What Does it Mean to Be
Disciplined?
•

•

In general, it requires discipline to
follow many agile practices and
philosophies
But, it also requires discipline to:
– Reduce the feedback cycle
– Learn continuously
– Deliver solutions incrementally
– Be goal driven
– Streamline Inception and
Transition efforts
– Adopt agile governance strategies


81

Disciplined Agile Delivery:
The Foundation for Scaling Agile
Compliance

Domain Complexity

Technical
Complexity

Geographic
Distribution

Team Size

Organizational
Distribution

Outside In Dev.

SAFe
XP

Scrum

And more…
Agile Modeling

Kanban

Lean

DAD leverages proven strategies from several sources,
providing a decision framework to guide your adoption and
tailoring of them in a context-driven manner.

82

A Disciplined Ending….

Please…
– Take the opportunity to thank your teammates – we all learned together
– Fill out the workshop evaluation form(s)
– Turn in the evaluation(s) to the instructor


83

Got Discipline?
DisciplinedAgileConsortium.org
DisciplinedAgileDelivery.com
ScottAmbler.com


84

Thank You!
scott [at] scottambler.com
@scottwambler
AgileModeling.com
AgileData.org
Ambysoft.com
DisciplinedAgileConsortium.org
DisciplinedAgileDelivery.com
ScottAmbler.com

85

DAD Certification: DisciplinedAgileConsortium.org
Disciplined Agile Yellow Belt
– Indication that the person is new to disciplined agile but eager to
learn
– Validate basic knowledge via a test

Disciplined Agile Green Belt
– Indication that the person is striving to be a professional
– Potential to be a junior coach
– Difficult test and several years of proven experience

Disciplined Agile Black Belt
– Indication that the person is an expert
– Often a senior coach, instructor, or agile transformation lead
– Board-level certification


86

Recommended Resources


87

Backup Slides


88

Agile Experiences with Team Size
On your (un)successful agile projects, how many IT team members were there?

Source: 2012 Agile Scaling Survey
www.ambysoft.com/surveys/

89

Agile Experiences with Geographic Distribution
On your (un)successful agile projects, how distributed were team members?


90

Agile Experiences with Compliance
On your (un)successful agile projects, was compliance applicable?

Note: Self imposed = CMMI, ISO, …


91

Agile Experiences with Domain Complexity
Question: From the point of view of the problem/business domain, at what
level(s) of complexity has the organization (un)successfully applied agile
techniques? (Please check all that apply)
Pilot Projects
Straightforward
Medium complexity
Complex
High Risk
0%

10%

20%

30%

Had Successes

40%

50%

60%

70%

80%

Had Failures



92

Agile Experiences with Technical Complexity
Question: In which technical situations has the organization
(un)successfully applied agile approaches? (Please check all that apply)
Greenfield
Stand-alone
Package/COTS
System integration
Fix legacy systems
Access legacy data
Fix legacy data
Single platform
Multi-platform
0%

10%

20%

30%

Had Successes

40%

50%

60%

70%

80%

Had Failures


93

Agile Experiences with Organizational Distribution
Question: In which of the following situations has the organization
(un)successfully applied agile techniques? (Please check all that apply)
Same division
Several divisions
Several countries
Contractors/consultants
Partner organizations
Outsourcing
0%

10%

20%

Had Successes

30%

40%

50%

60%

70%

80%

Had Failures


94

Disciplined Agile Delivery: Extending Scrum to the Enterprise

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (13)

Andere mochten auch

Andere mochten auch (15)

Ähnlich wie Disciplined Agile Delivery: Extending Scrum to the Enterprise

Ähnlich wie Disciplined Agile Delivery: Extending Scrum to the Enterprise (20)

Mehr von TechWell

Mehr von TechWell (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Disciplined Agile Delivery: Extending Scrum to the Enterprise