© Scott Ambler + Associates 1
Governance, Phases, and Milestones are not
Agile Dirty Words!
Mark Lines, Scott Ambler + AssociatesCo-creator of Disciplined Agile Delivery
Enterprise Transformation Coach
Helping to create Agile and Lean enterprises around the world
@Mark_Lines
DAD Has Caught On! - Organizations using
Disciplined Agile Delivery (DAD)
© Scott Ambler + Associates 2
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
3© Scott Ambler + Associates
Scrum
Extreme
Programming
LeanKanban
DAD is a Hybrid Framework
4
Unified Process Agile Modeling
Agile Data“Traditional”Outside In Dev.
DevOps …and more
DAD leverages proven strategies from several sources,
providing a decision framework to guide your adoption and
tailoring of them in a context-driven manner.
SAFe
© Scott Ambler + Associates
Functional Requirements: Potential Model Types
7
Usage
Epic/User Story
Persona
Usage Scenario
Story Mapping
UML Use Case Diagram
Domain
Domain/Conceptual Model
Logical Data Model (LDM)
UML Class Diagram
UML Component Diagram
ProcessValue Stream Map
Business Process Model
Data Flow Diagram (DFD)
Flow Chart
UML Activity Diagram
UML State Chart
User Interface (UI)
UI Flow Diagram
UI Prototype (Low Fidelity)
UI Prototype (High Fidelity)
UI Specification
And many more…
General Impact (Mind) Map Business Rule
Context Diagram Feature/Shall Statements
© Scott Ambler + Associates
DAD Initiatives have Milestones and may have Phases
10© Scott Ambler + Associates
Inception Construction Transition
Initiate the endeavor Development of a potentially consumable solution Deploy the solution
Stakeholder vision
Proven architecture
Sufficient functionality
Production readyContinued viability
(several)
Delighted stakeholders
2014 © Disciplined Agile Consortium
Milestone Reviews should be lightweight!
The Phases Disappear Over Time
15
First release: Inception Construction Transition
Second release: I Construction T
Third release: I Construction T
Nth+ releases: C CT C C TT T
.
.
.
© Scott Ambler + Associates
Exploratory “Lean Startup” Lifecycle
19
Sometimes it takes time to identify what your
stakeholders actually need
© Scott Ambler + Associates
© Scott Ambler + Associates 20
Choice is good!
40%
20%
10%
10%
10%
5%
5%
30%
15%
15%
50%
90%
5years
2years
Current
TypicalEvolutionofLifecycleMix
Agile/Scrum Lean Exploratory/LeanStart-up ContinuousDelivery Traditional
Many Organizations Are Serious About Governance
The farther to the right an organization,
the greater the chance they’re focused on governance
22
Moore’s
Adoption Curve
© Scott Ambler + Associates
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
© Scott Ambler + Associates 23
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
24© Scott Ambler + Associates
Why Traditional Governance Strategies Won’t Work
25
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
© Scott Ambler + Associates
Principles of Agile Governance
Collaboration over conformance
Enablement over inspection
Continuous monitoring over quality gates
Transparency over management reporting
© Scott Ambler + Associates 26
DAD Practices that Support Governance
• “Standard” agile practices:
– Coordination meeting
– Iteration demonstrations
– All-hands demonstrations
– Retrospective
– Information radiators/Visual management
• Disciplined practices:
– Risk-value lifecycle
– Explicit light-weight milestones
– Follow enterprise development guidelines
– Work closely with enterprise professionals
– Development intelligence via automated
dashboards
27© Scott Ambler + Associates
Measuring Agile Teams
• Talk to people; don’t manage to the metrics
• Measure teams, not individuals
• Collect several metrics
• Trends are better than scalar values
• Empirical observation is important but limited
• Prefer automated metrics
• Some metrics must be gathered manually
• Prefer pull versus push reporting
• Beware scientific facades
• The value of many metrics diminishes over time
• If you collect no metrics at all you’re flying blind
• If you collect too many metrics you may be flying blinded
28© Scott Ambler + Associates
Potential Metrics
• Acceleration
• Activity time
• Age of work items
• Blocking work items
• Build health
• Business value delivered
• Code quality
• Cumulative flow
• Cycle time
• Defect density
• Defect trend
• Iteration burndown
• Lead time
• Net present value (NPV)
• Ranged release burndown/up
• Release burndown/up
• Return on investment (ROI)
• Stakeholder satisfaction
• Net promoter score
• Team morale
• Test coverage
• Velocity
• Work in process (WIP)
29© Scott Ambler + Associates
What’s in a Project Vision?• Could be thought of as an agile project charter
• Typically outlines:
– Goals of the project team and who is on it
– High-level scope of the current release
– Technical overview of the solution
– Outline of the plan to do the required work
– Could include feasibility information
• Could also describe:
– Business problem being addressed
– High-level schedule and estimates
– Key milestones
– Stakeholders
– Funding models
– Project risks and constraints
– Process/method used (e.g. DAD), governance strategy
– Key assumptions
31© Scott Ambler + Associates
Milestone: Bringing Stakeholders to Agreement around
your Vision
• Inception is complete and you can enter the Construction 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 identified and seem tolerable
– There is agreement on using a minimalist and agile process for building
the solution
– The team and environment have been set up that supports collaborative
teamwork, or are in the process of being so
– The process and governance strategies have been agreed to by both
your team and your stakeholders
32© Scott Ambler + Associates
An Example of a Lightweight Milestone Review…
35
Scenario:• End of 2 week Inception phase
• Invitees to review meeting
• Sponsor
• Product Owner
• Delivery Team
• Other stakeholders
• Architecture
• Data
• Governance
• Support
© Scott Ambler + Associates
An Example of a Construction Iteration Review…
© Scott Ambler + Associates 37
Scenario:• End of 2 week Construction iteration
• Invitees to review meeting
• Delivery Team
• Product Owner
• Other stakeholders
• Architecture
• Data
• Governance
• Support
© Scott Ambler + Associates 41
IT Governance Governance Views
Guidance Detail
SecurityDataDevelopmentOperationsArchitecturePortfolio
PrinciplesHigh-level rulesChecklistsDetailed definition
Develop Guidance
Collaborative (enterprise level)Collaborative (team level)Top-DownBottom-Up
Monitor
Direct interactionTeam dashboardPortfolio dashboardDirect observationStatus report
2014 © Disciplined Agile Consortium
Define Roles and Responsibilities
Share Knowledge
MeasureAutomated metricsManual metrics
Self-organizingCollaborativeDictatedTop-DownBottom-Up
Communities of practicePractitioner presentationDiscussion forumsExpert systemDevelop communication planKnowledgebaseNewsletterWord of mouth
Develop Metrics
Goal-Question-Metric (GQM)Targeted metricsCommon core metrics“Standard” team metrics
Manage Enterprise Risk
Aggregate organizational riskAggregate IT risk
There are many factors to
consider when adopting
Agile IT Governance
Let’s illustrate a few examples of where we need
to consider governance across IT…
© Scott Ambler + Associates 42
In Summary…
• DAD is “pragmatic agile”, not purist or prescriptive
• Flexibility of lifecycle approach with the consistency of a framework
• A collection of good ideas to help you to adjust your approach for
your context
• Not difficult to apply – if you are using Scrum/XP or Lean you are
using a subset of DAD already
• Agile Governance built-in
© Scott Ambler + Associates 51
Disciplined Agile provides a
roadmap for pragmatic Enterprise
Agile
For More Information…
• Scott Ambler + Associates
– www.scottambler.com
– Mark [at] scottambler.com
@mark_lines
• Disciplined Agile Delivery: A Practitioner’s Guide, by Scott Ambler &
Mark Lines
• DAD Blog: www.DisciplinedAgileDelivery.com
• DAD Certification: www.DisciplinedAgileConsortium.org
• DAD LinkedIn Discussion Group
– http://www.linkedin.com/groups/Disciplined-Agile-Delivery-4685263
• DAD YouTube Channel
– https://www.youtube.com/channel/UCcWJ20C86Mzxcsqb73AReHQ
© Scott Ambler + Associates 52
Scott Ambler + Associates is the thought leader behind the Disciplined
Agile Delivery (DAD) framework and its application. We are a boutique
IT management consulting firm that advises organizations to be more
effective applying disciplined agile and lean processes within the
context of your business.
Our website is ScottAmbler.com
We can help
© Scott Ambler + Associates 53
PRINCE2 Processes/Stages & DAD Phases
PRINCE2® Process Model
DAD Basic/Agile Lifecycle
DAD’s phases map well to
PRINCE2’s processes & stages
Stage 1 Stage 2 Stage 3
Note: This should be a short-term mapping, not end state!
© Scott Ambler + Associates 54
Recommendation: Apply Low formality In Project
Initiation Document (PID) Where Possible
• DAD’s Vision Statement
– Team Makeup
– Initial Scope
– Initial Technical Strategy
– Initial Release Plan
– Funding
– Identified Risks
• PRINCE2’s PID
– Project Definition
• Background
• Scope and Exclusions
• Constraints & Assumptions
• Users and other parties
• Interfaces
– Project Approach
• Business Case
• Team Structure
• Role Descriptions
• Quality Management Strategy
• Configuration Management Strategy
• Risk Management Strategy
• Communication Management Strategy
• Project Plan
• Project Controls
• Tailoring of PRINCE2
© Scott Ambler + Associates 55