agile governance for hybrid programs

Kevin Thompson, PhD, PMP, ACP, CSP, CSM

The leader in training and consulting for project management and agile development

Agile Governance for Hybrid Programs

RAGESM

Copyright 2013, cPrime Inc.

22

Who is cPrime?Who is cPrime?ENGAGED FOR YOUR SUCCESS


33

Who Are You?

1) Have you read the RAGESM paper, Recipes for Agile

Governance in the Enterprise: The Enterprise Web?

2) What fraction of your business initiatives involve hybrid

programs?

3) Which of these best characterizes the products you develop?

4) Are you a member of PMI or the Scrum Alliance?


44

Start Communicating!• View our previous RAGESM webinars:

• “Principles for Agile Governance in the Enterprise”• “Introduction to Agile Portfolio Governance”

• Download the white paper “Recipes for Agile Governance in the Enterprise (RAGE): The Enterprise Web.”

• Email: [email protected]

• Social media: #RAGEwebinar

mailto:[email protected]


55

After the webinar…

• We will send directions to collect the PDU you will earn from attending this webinar

• We will also send links to the recorded webinar and all RAGESM resources

• Please hold your questions until the end of the presentation


66

About Our Presenter

Kevin Thompson, Ph.D., has a doctorate in Physics from Princeton University, and extensive background in managing software development projects. He specializes in training individuals, teams, and organizations in agile development. Dr. Thompson helps companies make the challenging transition to agile development by working with development teams and business stakeholders to identify their needs, define the right process for the business, determine the steps needed to implement the process, and work through the steps successfully. Dr. Thompson has Project Management Professional (PMP), Agile Certified Practitioner (ACP), Scrum Master (CSM), and Scrum Practitioner (CSP) certifications.

Kevin Thompson


77

What will You Learn Today?

• Fundamentals of planning & executing hybrid programs• How to create a Release Plan• How to manage dependencies and changes• How to evaluate progress towards objectives

• This approach incorporates Principles of Agile Governance• Download “Recipes for Agile Governance: The Enterprise Web”

from www.cprime.com for much more detail

http://www.cprime.com/


88

Review: Agile GovernanceGovernance: The formalization and exercise of repeatable decision-making practices

• Governance = how to decide what to do• Agile Governance is an Agile style of governance

• Enables rapid decisions, based on lightweight artifacts developed with minimum effort

• Applicable to any process (Agile, Plan-Driven, Hybrid, etc.)

Governance Recipe: A mildly prescriptive and customizable technique for making a specific type of decision


99

Review: How the Principles Work Together

Recipes have Standard Elements, including Common Role Types and Categories of Governance Points. We organize deliverables at each level into a small number of coarse-Granularity items, which we rank by value, and for which our estimates for effort, value, etc. should be Good Enough for the current need, and no better. Work is always completed to a Definition of Done, and the Handoff from source to receiver is accomplished through sustained interaction over time.

Download Recipes for Agile Governance: The Enterprise Web from www.cprime.com for much more detail



1010

Review: Levels of Governance• Classic perspective

• Project: Temporary endeavor to deliver a fixed scope• Program: Collection of linked projects• Portfolio: Group of Programs/Projects to be managed together

• Classic definitions don’t map well to Agile world, but…• Hierarchical organization is still relevant.• Our levels for Agile Governance

• Project Level: Refers to work of a single Team, which is a persistent grouping of people

• Program Level: Refers to the collaboration between Teams• Portfolio Level: Refers to the development and management of

business Initiatives that lead to program- and project-level work


1111

Levels of Governance


1212

The Teams in the Program• Two Software Teams

• They write software, to be deployed in Production environment

• They mostly interact with each other• They depend on IT for key milestones in next Release

• IT Department• Manages procurement, configuration of hardware and

software products • Supplies hardware, software, services to software

development Teams• Builds, maintains, deploys applications to Production

environment


1313

The Processes• Software Teams follow Scrum process

• Work must be planned against a calendar• Work can be divided into short cycles• Teams can start and finish deliverables in each cycle

• IT follows a plan-driven process• Work must be planned against a calendar• Unique, one-off projects are common and have varying lengths• Work cannot be divided into short cycles in which deliverables

are started and finished


1414

The Objective• Deliver first release of Web application for an online-

dating service• First release has minimum-marketable feature set

• Time to market more important than feature richness


1515

Program Governance Summary• Requirements Development

• The Area Product Owner defines the Release goals. Team Product Owners and Team Members write Stories to define the specific deliverables, review them in Backlog Grooming meetings, and revise after. An IT Project Manager meets with the Teams over time to understand the deliverables IT needs to deliver for the Release.

• Release Planning• The Program Manager facilitates the Release Planning meeting for the Scrum Teams

and IT personnel, who develop an initial Release plan for the Stories and IT milestones.

• Execution during the Release Cycle• The Program Manager facilitates twice-weekly Scrum-of-Scrums meetings, where

ScrumMasters and the IT Project Manager identify and respond to cross-Team issues as they arise.

• Validation for Release to Production• The Area Product Owner facilitates the Release Review meeting at the end of the

Release cycle, to work with the Team Product Owners, Program Manager, and IT Project Manager to confirm that the Release candidate satisfies the Release Definition of Done.


1616

Backlog Grooming Meeting• Purpose: Ensure Product Backlog is ready for planning• Team Product Owner facilitates• When: 1—2 hours per week• Who: Team, Team Product Owner • Actions in meeting

• Provide feedback on clarity, quality, acceptance criteria, dependencies, ranking of Stories

• Identify “holes” (esp. technical) for which Stories must be written• Break Epics into Stories• Do long-term technical (architecture / infrastructure) planning

• Follow-up actions• Team, Product owner write or revise Stories, as needed


1717

Release Planning Meeting• Purpose: Develop Initial Release Plan• Program Manager facilitates• When: 1—4 weeks before start of Release cycle• Who: Program Manager, Area Product Owner, Team Product

Owners, ScrumMasters, Team Members, IT Project Manager,…

Agenda1. Teams lay out Stories, Epics (“Items”) in preferred sequence2. Teams quickly provide adequate estimates for Items not yet

estimated (e.g., Planning Poker, Affinity Estimation)3. Teams map Items to Sprints

– Stories do not cross Sprint boundaries, but Epics may4. Teams collaborate to identify, sequence dependencies5. Teams collaborate to identify missing Items, create, and

incorporate them into the plan6. IT Project Manager collaborates on timing of IT milestones7. All agree on “Definition of Done” (exit criteria) for Release


1818

Example: Release Definition of Done• No P0 or P1 defects• No more than 15 P2 defects• Value of Release candidate justifies a Production

deployment• Prerequisites for handoff to IT are confirmed by IT

and Engineering to have been satisfied


1919

Stories and MilestonesBlue Team Stories SizeUser Creates Account 5User Logs In 5CC Gateway 8User Gives CC Info 3CC Data Secure Storage

8

User Logs Out 3Total 32

Green Team Stories SizeUser Personal Info 5User Search Profiles 5User Message to Profile

8

User Reads Message 3User Replies to Message

8

User Emailed re: Msg 3Total 39Milestones for IT Department Day of

Release Cycle

Reconfigure Firewall to enable access to CC Gateway for development

0

Deliver DB Server 8Deliver Mail Server 12


2020

Initial Release Plan

User Create

s Accoun

t

User Logs

In

User Logs Out

User Gives

CC Info

CC Data Secure Storage

CC Gate-way

User Search Profile

s

User Messag

e to Profile

User Reads

Message

User Emailed re: Msg

User Replies

to Message

User Personal Info

Sprint 2Sprint 1 Sprint 3

DeliverMail Server

Recon-figureFirewall

Deliver DBServer

Blue Team: CC Gateway is new and high-risk, so put at front of Sprint 1 to allow time to deal with issues. Enable account creation and access next, to make work easier for Green Team.

Green Team: Ranking by workflow is natural, and gives IT time to deliver the Mail Server before it is needed. Will mock user-account objects at start.


2121

Scrum-of-Scrums Meeting• Purpose: Identify and address cross-Team issues• Program Manager facilitates• When: Twice weekly (more or less often, as needed)• Who: Program Manager, ScrumMasters, IT Project Manager

Agenda• Each person describes

What my Team is doing that may affect other Teams What issues my Team needs help to resolve

• Resolve issues in meeting, if possible• Identify follow-up actions and owners

• Follow-up actions• Resolve problems, revise schedule as needed


2222

Revision at Start of Sprint 1

Sprint 2Sprint 1 Sprint 3

DeliverMail Server


Deliver DBServer

User Create

s Accoun

t

User Logs

In

User Logs Out

User Gives

CC Info


CC Gate-way

User Search Profile

s

User Messag

e to Profile

User Reads

Message


User Replies

to Message

User Personal Info

Blue Team: IT can’t reconfigure corporate firewall to enable development access to credit-card gateway before Sprint 1. Defer ‘CC Gateway’ to Sprint 2.

Green Team: No change needed. Actually more convenient to have Login earlier than for original plan.


2323

Burn-Up Chart: End of Sprint 1

Sprint 1 Sprint 2 Sprint 3 No guarantee, but progress is consistent with completion of planned Release scope


2424

Revision at Start of Sprint 2

Sprint 2Sprint 1 Sprint 3User

Creates

Account

User Logs

In

User Logs Out

User Gives

CC Info


CC Gate-way

User Search Profile

s

User Messag

e to Profile

User Reads

Message


User Replies

to Message

User Personal Info

DeliverMail Server


Deliver DBServer

Blue Team: Firewall fixed, but IT will be late delivering DB server for CC data storage. Defer ‘CC Data Secure Storage’ to Sprint 3.

Green Team: IT delivery of email server will be late. Defer ‘User Emailed re: Msg’ to Sprint 3.


2525

Burn-Up Chart: End of Sprint 2

Sprint 1 Sprint 2 Sprint 3 The trend looks good. Completion of planned Release scope is likely.


2626

Final at Start of Sprint 3

Sprint 2Sprint 1 Sprint 3User

Creates

Account

User Logs

In

User Logs Out

User Gives

CC Info


CC Gate-way

User Search Profile

s

User Messag

e to Profile

User Reads

Message


User Replies

to Message

User Personal Info

DeliverMail Server


Deliver DBServer

Blue Team: No change needed.

Green Team: No change needed.


2727

Burn-Up Chart: End of Release Cycle

Sprint 1 Sprint 2 Sprint 3 The planned Release scope was completed


2828

Release Review Meeting• Purpose: Ensure product is ready for release to Production• Area Product Owner facilitates• When: End of Release cycle• Who: Area and Team Product Owners, Program Manager, IT

Project Manager• Actions in meeting

• Review Release Definition of Done to confirm release readiness Review business objectives to confirm value justifies release Quality is sufficient Technical pre-requisites for deployment have been satisfied

• Area Product Owner makes Go/No-go decision• Follow-up actions

• Program Manager communicates decision, initiates handoff, to IT department, as appropriate


2929

Summary of Cross-Team Roles

Project Manager (IT)• Brings Scrum Teams’ requirements to IT Department• Creates and updates IT work schedule

Area Product Owner• Defines Release Goals

• Minimum Feature Set• Works with Team Product Owners to

clarify requirements

Program Manager• Ensures cross-Team planning,

collaboration are done well• Runs Release Planning,

Scrum-of-Scrums meetings


3030

Summary of Scrum Team Roles

Team Product Owner• Is Team’s sole source of truth for requirements and priorities• Owns requirements (new features, bug fixes) and ranking• Works with Area Product Owner to define & rank user-facing features• Collaborates with Team to ensure proper implementation• Often a Product Manager, Business Analyst

ScrumMaster• Does whatever is needed to make

Team as productive as possible• Acts as Servant Leader• Owns process (enforces, tracks,

expedites problem resolution)• Runs Daily Scrum, Sprint Planning,

Retrospective Meetings• Often a Project Manager

Team• Self-organizes cross-

functional members to implement, test features

• Software & test engineers, database architects, UI developers, etc.

• Owns estimates, tasks, assignments


3131

Summary of RecipesRecipe Participants Decisions & ActionsBacklog Grooming Meeting

Team Product Owner, Team

Identify changes required for the Product Backlog (revise, add, delete Stories)

Release Planning Meeting

Area & Team Product Owners, Program Manager, IT Project Manager, ScrumMasters, Teams

Program Manager facilitates. Teams and IT Project Manager devise Release Plan that satisfies Release goals and dependencies.

Scrum-of-Scrums Meeting

Program Manager, ScrumMasters, IT Project Manager

Each describes possible impact of Team’s work, impacts discovered that require assistance. All identify how to address impacts.


3232

Summary of RecipesRecipe Participants Decisions & ActionsRelease Readiness Review Meeting

Area & Team Product owners, Program Manager, IT Project Manager

Area Product Owner facilitates review to confirm product satisfies Release Definition of Done, make Go/No-go decision for deployment.

Release Definition of Done

Area Product Owner, Program Manager, IT Project Manager

Defines requirements that must be satisfied before product can be released for production deployment. Guides development, and is used in Release Readiness Review meeting.


3333

Which Agile Governance Principles are Used?

Most of them!

1. Standardization of Recipe Elements2. Common Role Types3. Categories of Governance Points4. “Good Enough” is Good Enough5. Granularity6. Definition of Done7. Handoffs

Download “Recipes for Agile Governance: The Enterprise Web” from www.cprime.com for much more detail



3434

Conclusion• Program-level governance for hybrid processes means

• Developing, planning requirements across all Teams and processes• Adapting to issues that arise during development

• Our hybrid Program governance is conducted with• Roles: Area & Team Product Owners, Program Manager,

ScrumMasters, Teams, IT Project Manager• Ceremonies: Backlog Grooming, Release Planning, Scrum-of-

Scrums, Release Readiness Review Meetings• Artifacts: Stories, Release Definition of Done• Tracking and Metrics: Burn-Up Chart

• Key insights• Breaking scope into small deliverables (Stories) is key to our ability

to adapt to unexpected changes


3535

Question & Answer