DAH15 : Bray Goverance - Not Dirty Words

Discuss AgileHyderabad 2015

Rod BraySenior Consultant, Scott Ambler + Associates

Governance, Phases, and Milestones are notAgile Dirty Words!

@johnrodbray

© Scott Ambler + Associates 1

About Rod Bray


• Senior Consultant, Scott Ambler + Associates• 35+ years in IT• Certified Trainer• CDAI, CDAC, PMI-ACP, CSP, CSM,

ICP-ACC, ICP-ATF, AHF• [email protected]• @johnrodbray

• Helping to create Agile and Lean enterprisesaround the world

Many Organizations Are Serious About Governance

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

3

Moore’sAdoption Curve

© Scott Ambler + Associates

Disciplined Agile Delivery(DAD) is a process decisionframework

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

4© Scott Ambler + Associates

Scrum

ExtremeProgramming

LeanKanban

DAD is a Hybrid Framework

5

Unified Process Agile Modeling

Agile Data“Traditional”Outside In Dev.

DevOps …and more

DAD leverages proven strategies from many sources,providing a decision framework to guide your adoption and

tailoring of them in a context-driven manner.

SAFe


DAD is Goal-Driven, Not Prescriptive


DAD Initiatives have Milestones and may have Phases


Inception Construction TransitionInitiate the endeavor Development of a potentially consumable solution Deploy the solution

Stakeholder vision

Proven architecture

Sufficient functionalityProduction ready

Continued viability(several)

Delighted stakeholders

2014 © Disciplined Agile Consortium

Milestone Reviews should be lightweight!

Basic/Agile Lifecycle

8

A full Scrum-based agile delivery lifecycle.


Lean Lifecycle

9

A full lean delivery lifecycle


The Phases Disappear Over Time

10

First release: Inception Construction Transition

Second release: I Construction T

Third release: I Construction T

Nth+ releases: C CT C C TT T

.

.

.


Lean Continuous Delivery Lifecycle

11

Your evolutionaryend goal?


Exploratory “Lean Startup” Lifecycle

12

Sometimes it takes time to identify what yourstakeholders actually need



GoverningDisciplined

Agile Teams

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


Why is Governance Important?

• Sustain and extend your IT strategies and objectives, which in turn shouldreflect your corporate strategies and objectives

• Determine how the company will execute its strategy by selecting andprioritizing 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


Why Traditional Governance Strategies Won’t Work

16

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


Principles of Agile Governance

Collaboration over conformance

Enablement over inspection

Continuous monitoring over quality gates

Transparency over management reporting


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


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


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)


Inception Phase Milestone: Stakeholder Vision


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


Milestone: Bringing Stakeholders to Agreement aroundyour Vision

• Inception is complete and you can enter the Construction phasewhen:– Your stakeholders agree that it makes sense to proceed based upon the

achievable scope, schedule, budget, constraints, and other criteriarelated 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


Develop Common Vision Goal


25

Information Radiators

Light-weight

Detailed© Scott Ambler + Associates

An Example of a Lightweight Milestone Review…

26

Scenario:• End of 2 week Inception phase• Invitees to review meeting

• Sponsor• Product Owner• Delivery Team• Other stakeholders

• Architecture• Data• Governance• Support


Sample Inception Milestone Review Deck


An Example of a Construction Iteration Review…


Scenario:• End of 2 week Construction iteration• Invitees to review meeting

• Delivery Team• Product Owner• Other stakeholders

• Architecture• Data• Governance• Support

Sample Iteration Review Deck



GoverningIT


Governance cuts across all process blades


IT Governance Governance Views

Guidance Detail

SecurityDataDevelopmentOperationsArchitecturePortfolio

PrinciplesHigh-level rulesChecklistsDetailed definition

Develop GuidanceCollaborative (enterprise level)Collaborative (team level)Top-DownBottom-Up

Monitor

Direct interactionTeam dashboardPortfolio dashboardDirect observationStatus report

2014 © Disciplined Agile Consortium

Define Roles andResponsibilities

Share Knowledge

Measure Automated metricsManual metrics

Self-organizingCollaborativeDictatedTop-DownBottom-Up

Communities of practicePractitioner presentationDiscussion forumsExpert systemDevelop communication planKnowledgebaseNewsletterWord of mouth

Develop MetricsGoal-Question-Metric (GQM)Targeted metricsCommon core metrics“Standard” team metrics

Manage EnterpriseRisk

Aggregate organizational riskAggregate IT risk

There are many factors toconsider when adoptingAgile IT Governance

Let’s illustrate a few examples of where we needto consider governance across IT…


Governance –Guidance for PortfolioManagement


Governance – Guidancefor Enterprise Architecture


Governance – Guidancefor Reuse Engineering


Governance – Guidancefor Operations


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


Disciplined Agile provides aroadmap for pragmatic EnterpriseAgile

For More Information…

• Scott Ambler + Associates– www.scottambler.com– Rod.Bray[at] scottambler.com

@johnrodbray

• 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 is the thought leader behind the DisciplinedAgile Delivery (DAD) framework and its application. We are a boutiqueIT management consulting firm that advises organizations to be more

effective applying disciplined agile and lean processes within thecontext of your business.

Our website is ScottAmbler.comWe can help


PRINCE2 Processes/Stages & DAD Phases

PRINCE2® Process Model

DAD Basic/Agile Lifecycle

DAD’s phases map well toPRINCE2’s processes & stages

Stage 1Stage 1 Stage 2Stage 2 Stage 3Stage 3

Note: This should be a short-term mapping, not end state!© Scott Ambler + Associates 45

Recommendation: Apply Low formality In ProjectInitiation 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


DAH15 : Bray Goverance - Not Dirty Words

Engineering

Transcript of DAH15 : Bray Goverance - Not Dirty Words