Disciplined Agile Delivery Enterprise Transformation Coach Helping to Create Agile and Lean Enterprises Around the World

Governance, Phases, and Milestones are not Agile Dirty Words!

Mark Lines, Scott Ambler + Associates Co-creator of Disciplined Agile Delivery Enterprise Transformation Coach Helping to create Agile and Lean enterprises around the world

@Mark_Lines

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

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.

Epic/User Story Domain/Conceptual Model Persona Logical Data Model (LDM) Usage Scenario UML Class Diagram Story Mapping UML Component Diagram UML Use Case Diagram

User Interface (UI) Process Value Stream Map UI Flow Diagram Business Process Model UI Prototype (Low Fidelity) Data Flow Diagram (DFD) UI Prototype (High Fidelity) Flow Chart UI Specification UML Activity Diagram UML State Chart

General Impact (Mind) Map Business Rule Context Diagram Feature/Shall Statements

Inception Construction Transition Initiate the endeavor Development of a potentially consumable solution Deploy the solution

Stakeholder vision Continued viability Sufficient functionality Production ready Proven architecture (several) Delighted stakeholders

2014 © Disciplined Agile Consortium

Milestone Reviews should be lightweight!

A full Scrum-based agile delivery lifecycle.

A full lean delivery lifecycle

First release: Inception Construction Transition

Second release: I Construction T

Third release: I Construction T . . . Nth+ releases: C T C T C T C T

Your evolutionary end goal?

Sometimes it takes time to identify what your stakeholders actually need

Current 10% 90%

2 years 20% 10% 5% 15% 50%

5 years 40% 10% 5% 30% 15%

Agile/Scrum Lean Exploratory/Lean Start-up Continuous Delivery Traditional Choice is good! © Scott Ambler + Associates 20 Governing Disciplined Agile Teams

Moore’s Adoption Curve

The farther to the right an organization, the greater the chance they’re focused on governance

• 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

• 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

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

Collaboration over conformance

Enablement over inspection

Continuous monitoring over quality gates

Transparency over management reporting

• “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

• 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

• Acceleration • Lead time • Activity time • Net present value (NPV) • Age of work items • Ranged release burndown/up • Blocking work items • Release burndown/up • Build health • Return on investment (ROI) • Business value delivered • Stakeholder satisfaction • Code quality • Net promoter score • Cumulative flow • Team morale • Cycle time • Test coverage • Defect density • Velocity • Defect trend • Work in process (WIP) • Iteration burndown

• 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

• 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

Light-weight

Detailed

Scenario: • End of 2 week Inception phase • Invitees to review meeting • Sponsor • Product Owner • Delivery Team • Other stakeholders • Architecture • Data • Governance • Support

Scenario: • End of 2 week Construction iteration • Invitees to review meeting • Delivery Team • Product Owner • Other stakeholders • Architecture • Data • Governance • Support

Goal-Question-Metric (GQM) Develop Metrics Targeted metrics Common core metrics “Standard” team metrics

Measure Automated metrics Manual metrics

Direct interaction Team dashboard Monitor Portfolio dashboard Direct observation Status report

Principles Guidance Detail High-level rules Checklists Detailed definition

Collaborative (enterprise level) Develop Guidance Collaborative (team level) Top-Down Bottom-Up

There are many factors to Self-organizing Define Roles and Collaborative Responsibilities Dictated consider when adopting Top-Down Bottom-Up Communities of practice Agile IT Governance Practitioner presentation Discussion forums Share Knowledge Expert system Develop communication plan Knowledgebase Newsletter Word of mouth

Manage Enterprise Aggregate organizational risk Risk Aggregate IT risk

• 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

Disciplined Agile provides a roadmap for pragmatic Enterprise Agile

• 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

PRINCE2® Process Model

DAD’s phases map well to PRINCE2’s processes & stages

Stage 1 Stage 2 Stage 3

DAD Basic/Agile Lifecycle

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 • PRINCE2’s PID – Team Makeup – Project Definition • Background – Initial Scope • Scope and Exclusions – Initial Technical Strategy • Constraints & Assumptions – Initial Release Plan • Users and other parties – Funding • Interfaces – Identified Risks – 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