Using the Unified Process as a Scaling Framework for Scrum

Where to go for the presentation Mike’s blog: http://www.leadingagile.com Brian’s blog: http://blog.softwarearchitecture.com

Mike’s blog: http://www.leadingagile.com

Brian’s blog: http://blog.softwarearchitecture.com

Who is Mike Cottmeyer? Have been on the VersionOne service team for about 8 months Prior to joining VersionOne I was a Senior Project Manager for CheckFree Corporation in Atlanta, GA Certified Scrum Master, PMP, DSDM Agile Project Leader

Have been on the VersionOne service team for about 8 months

Prior to joining VersionOne I was a Senior Project Manager for CheckFree Corporation in Atlanta, GA

Certified Scrum Master, PMP, DSDM Agile Project Leader

Who is Brian Sondergaard? Director of Architecture at CheckFree (now a part of Fiserv) Instrumental in bringing agile to Fiserv

Director of Architecture at CheckFree (now a part of Fiserv)

Instrumental in bringing agile to Fiserv

Overview of the next 90 minutes Not a questioning agile talk This is a scaling agile talk It is a talk about applying agile from “concept to cash” It is a talk about making agile work in real organizations Lot’s of stuff to cover Links to resources at the end

Not a questioning agile talk

This is a scaling agile talk

It is a talk about applying agile from “concept to cash”

It is a talk about making agile work in real organizations

Lot’s of stuff to cover

Links to resources at the end

Our Agenda 15 minutes setting up the problem 15 minutes talking about core UP and Agile principles 45 minutes explaining how it all works 15 minutes for questions

15 minutes setting up the problem

15 minutes talking about core UP and Agile principles

45 minutes explaining how it all works

15 minutes for questions

If you are part of a small team running agile on whiteboards…

Methodology pragmatist We are passionate about the values and principles of Agile We love stories about wholesale agile transformation But… we’re going to do what it takes to get the job done

We are passionate about the values and principles of Agile

We love stories about wholesale agile transformation

But… we’re going to do what it takes to get the job done

Most teams are not there… Many are doing agile under less than agile circumstances As an agile community we need to help people where they are … but get them where they need to be

Many are doing agile under less than agile circumstances

As an agile community we need to help people where they are

… but get them where they need to be

Most teams are looking for advice that resonates

Our story… Started with a small colocated team Product took off Team grew, 70 plus including offshore Our product was beginning to leveraged as a shared service across the organization

Started with a small colocated team

Product took off

Team grew, 70 plus including offshore

Our product was beginning to leveraged as a shared service across the organization

… a little more story We were beginning to depend on other enterprise services for our product Our product became a product of products

We were beginning to depend on other enterprise services for our product

Our product became a product of products

What is a product of products? Payments Services Risk Services Business Intelligence Corporate Financials Online Banking X X X X Phone Banking X X X Payment Processing X X Remittance Processing X X

Complex product architecture Partner Communication Payments Risk Bus Intel/ Reporting Business Intelligence Corporate Financials

Small team agile doesn’t resonate Shared code ownership Teams responsible for entire architecture Legacy systems with little automation Tightly coupled architectures

Shared code ownership

Teams responsible for entire architecture

Legacy systems with little automation

Tightly coupled architectures

Big company overhead Document based tollgates Corporate governance and decision making Traditional Project Management Offices

Document based tollgates

Corporate governance and decision making

Traditional Project Management Offices

Agile offers only partial coverage Mike Griffiths, Leading Answers http://www.leadinganswers.com

Teams are trying to find a way to get the value of agile …

… but don’t fit the agile profile

Scrum is really simple Scrum is a simple framework Deliver in short cycles, inspect outcomes, and adapt process or requirements Some role definition, daily stand up meetings, planning process, etc.

Scrum is a simple framework

Deliver in short cycles, inspect outcomes, and adapt process or requirements

Some role definition, daily stand up meetings, planning process, etc.

Devise and execute the best processes possible based on their skills, experience , and the situation in which they find themselves

Scrum is not enough Business case Vision Backlog (where does it come from?) Architecture Documentation Release plans and roadmaps

Business case

Vision

Backlog (where does it come from?)

Architecture

Documentation

Release plans and roadmaps

Other Challenges Interfaces with external organizations When there are lots of team members Geographically distributed Offshore team members Closed workspaces Large systems architectures External dependencies

Interfaces with external organizations

When there are lots of team members

Geographically distributed

Offshore team members

Closed workspaces

Large systems architectures

External dependencies

Is this even agile? Maybe not Lots of smells Agile thinking and agile practice can still be valuable

Maybe not

Lots of smells

Agile thinking and agile practice can still be valuable

What do we build around Iterative and incremental delivery of working software Short cycle planning with an integrated customer Small, independent stories Empowered teams Autonomy and self organization Ownership and Accountability

Iterative and incremental delivery of working software

Short cycle planning with an integrated customer

Small, independent stories

Empowered teams

Autonomy and self organization

Ownership and Accountability

Scrum-but introduces risk Deviating from agile practice introduces risk We need to be intentional about how we mitigate that risk

Deviating from agile practice introduces risk

We need to be intentional about how we mitigate that risk

Mitigating process Risk As we scale, we often need to have more things written down We need to be more intentional about architecture We need to be more intentional about requirements

As we scale, we often need to have more things written down

We need to be more intentional about architecture

We need to be more intentional about requirements

Why bother talking about UP Provides an iterative and incremental delivery structure Guidance for writing and breaking down requirements Patterns for dealing with software architecture

Provides an iterative and incremental delivery structure

Guidance for writing and breaking down requirements

Patterns for dealing with software architecture

Why bother talking about UP Structure for necessary documentation Provides process guidance for all aspects of the SDLC, not just development

Structure for necessary documentation

Provides process guidance for all aspects of the SDLC, not just development

Most teams are making tradeoffs, lets be intentional about managing those tradeoffs and understanding the risks

Common myths about UP Adopting UP means adopting Rational Tools UP is too big UP is too document focused UP is not configurable People in the agile community really HATE the Unified Process, especially the RUP

Adopting UP means adopting Rational Tools

UP is too big

UP is too document focused

UP is not configurable

Process gone bad UP is designed to be configurable In practice people do UP poorly UP with a waterfall, predictive focus Agile with an undisciplined ad-hoc focus

UP is designed to be configurable

In practice people do UP poorly

UP with a waterfall, predictive focus

Agile with an undisciplined ad-hoc focus

Bad process is bad process no matter what methodology you are using

How do we make all this work? Take what is good about agile, what scales, and leverage it Replace what doesn’t work with certain components of the UP Keep things as simple as possible

Take what is good about agile, what scales, and leverage it

Replace what doesn’t work with certain components of the UP

Keep things as simple as possible

How do we do this right? We want to be as agile as possible We want to implement as little structure as possible to scale Give people across all the teams a common language, minimal standardization, and some degree of coordination Stay risk focused !

We want to be as agile as possible

We want to implement as little structure as possible to scale

Give people across all the teams a common language, minimal standardization, and some degree of coordination

Stay risk focused !

Do the simplest thing that could possibly work

What agile should I keep? Small teams, teams of teams if necessary Short planning cycles Visibility, inspection, adaptation Retrospectives Integrated onsite customer

Small teams, teams of teams if necessary

Short planning cycles

Visibility, inspection, adaptation

Retrospectives

Integrated onsite customer

What agile should I keep? Progressive elaboration of plans Small independent stories Autonomy and self organization Ownership and accountability

Progressive elaboration of plans

Small independent stories

Autonomy and self organization

Ownership and accountability

What UP stuff should I keep? Sprit of RUP Phases Iterations Use Cases Deliberate Architecture Some artifacts

Sprit of RUP

Phases

Iterations

Use Cases

Deliberate Architecture

Some artifacts

What agile stuff might go away? No documentation No planning Emerging architecture Universal shared code ownership

No documentation

No planning

Emerging architecture

Universal shared code ownership

What UP stuff might go away? Role definitions Process guidance unless something has value in our context Most artifacts

Role definitions

Process guidance unless something has value in our context

Most artifacts

What UP stuff will definitely go away?

Introduce elements of UP that reduce risk

Spirit of UP Attack major risks early and continuously, or they will attack you Ensure that you deliver value to your customer Stay focused on executable software and the “product” Accommodate change early in the project

Attack major risks early and continuously, or they will attack you

Ensure that you deliver value to your customer

Stay focused on executable software and the “product”

Accommodate change early in the project

Spirit of UP Baseline an executable architecture early Build your system with components Work together as one team Make quality a way of life, not an afterthought

Baseline an executable architecture early

Build your system with components

Work together as one team

Make quality a way of life, not an afterthought

UP phases explained Construction Elaboration Inception Transition Lifecycle Objective Milestone Lifecycle Architecture Milestone Initial Operational Capability Milestone Product Release Milestone Are the technical risks mitigated? Are the logistical risks mitigated? Are the business risks mitigated? Are we really ready to ship a complete robust product to market?

Effort and duration by phase Inception Elaboration Construction Transition Inception Elaboration Construction Transition Effort 5% 20% 65% 10% Schedule 10% 30% 50% 10%

A more Agile representation? Internal Release* Iteration Zero Iteration H Iteration 1 Iteration 2 Iteration 3

Phases are time boxes for dealing with risk

With phases as the key concept… Outcomes Activities Artifacts

Outcomes

Activities

Artifacts

Inception Outcomes Clarify the Vision Initial Backlog Preliminary estimates One possible solution Validation of the business case Business risk mitigated Stakeholder agreement

Clarify the Vision

Initial Backlog

Preliminary estimates

One possible solution

Validation of the business case

Business risk mitigated

Stakeholder agreement

Inception Activities Meetings between product owner, architect, and analyst to evolve the product backlog and the candidate solution Balance the needs of the business with the capability of the team and feasibility of the solution Review the outcome with the business, manage expectations, go/no-go decision

Meetings between product owner, architect, and analyst to evolve the product backlog and the candidate solution

Balance the needs of the business with the capability of the team and feasibility of the solution

Review the outcome with the business, manage expectations, go/no-go decision

Collaborative Model Project Manager

Inception Artifacts Business case Vision Use Case Inventory Risk Assessment Candidate architecture

Business case

Vision

Use Case Inventory

Risk Assessment

Candidate architecture

Elaboration Outcomes Architectural spikes completed Architecturally significant backlog done Validated systems architecture Walking skeleton Product backlog “fully” defined Technical risk mitigated Backlog re-estimated Business decision to move forward

Architectural spikes completed

Architecturally significant backlog done

Validated systems architecture

Walking skeleton

Product backlog “fully” defined

Technical risk mitigated

Backlog re-estimated

Business decision to move forward

Elaboration Activities Validate systems architecture by building out backlog items that will “prove” the architecture Performance testing Security testing Backlog creation Arch/Tech Spikes

Validate systems architecture by building out backlog items that will “prove” the architecture

Performance testing

Security testing

Backlog creation

Arch/Tech Spikes

Consensus on major “forces” Clarity of boundaries Agreement on where we’re going “ Stay between the lines” Establish architecture “guardrails”

Consensus on major “forces”

Clarity of boundaries

Agreement on where we’re going

“ Stay between the lines”

Scrum of Scrums Epic/ System Perspective Feature/ Subsystem Perspective Story/ Component/ Design Perspective

Business Level Use Case

Solution Architecture

Primary and alternate flows

Interactions and contracts

Design level use case

Detailed interactions

Data

Scrum of Scrums Higher level scrums integrate the scenarios of the component teams Breakdown application and zip it back up Automation at each level of the breakdown/rollup

Higher level scrums integrate the scenarios of the component teams

Breakdown application and zip it back up

Automation at each level of the breakdown/rollup

Elaboration Artifacts Updated Product backlog Use case scenarios defined Go forward architectural representation Done backlog items Test plan/test results Fully integrated and working subset of the system

Updated Product backlog

Use case scenarios defined

Go forward architectural representation

Done backlog items

Test plan/test results

Fully integrated and working subset of the system

Construction Outcomes Product built Product fully tested Product documentation completed Logistical risks mitigated Business decision to release to market

Product built

Product fully tested

Product documentation completed

Logistical risks mitigated

Business decision to release to market

Construction Activities Most ‘agile’ of all phases Teams building features from the backlog Testing Documentation Measure velocity Project management

Most ‘agile’ of all phases

Teams building features from the backlog

Testing

Documentation

Measure velocity

Project management

Construction Artifacts Evolving backlog Design documentation Code User documentation Test results

Evolving backlog

Design documentation

Code

User documentation

Test results

Transition Outcomes Product finalized and ready to be released Any remaining issues resolved Preparation for handoff Transition to support or operations Production deployment

Product finalized and ready to be released

Any remaining issues resolved

Preparation for handoff

Transition to support or operations

Production deployment

Transition Activities Review Documentation Last minute bug fixes Last minute backlog changes

Review

Documentation

Last minute bug fixes

Last minute backlog changes

Transition Artifacts Hand off docs Final user documentation Packaging Website Marketing

Hand off docs

Final user documentation

Packaging

Website

Marketing

Role of documentation

Managing Complexity Product Project Management Team Architecture Pick two Align the rest

Product

Project

Management

Team

Architecture

Pick two

Align the rest

Complexity diagram

Keep it simple

Closing remarks Might not need to bother if you are a small collocated agile team Be pragmatic about process and adopt things that make sense for the size and complexity of your organization Be intentional about the tradeoffs you are making and mitigate process risks Done right, there are some concepts from RUP you can use to help mitigate these risks

Might not need to bother if you are a small collocated agile team

Be pragmatic about process and adopt things that make sense for the size and complexity of your organization

Be intentional about the tradeoffs you are making and mitigate process risks

Done right, there are some concepts from RUP you can use to help mitigate these risks

Valuable RUP concepts Sprit of RUP Phases Iterations Use Cases Deliberate Architecture Some artifacts

Sprit of RUP

Phases

Iterations

Use Cases

Deliberate Architecture

Some artifacts

Where to go for more info… Scaling Software Agility – Dean Leffingwall Agile Project Management With Scrum – Ken Schwaber Managing Iterative Software Development Projects – Kurt Bittner, Ian Spence Scott Ambler http://www.ambysoft.com/unifiedprocess/agileUP.html DSDM http://www.dsdm.org/products/atern.asp

Scaling Software Agility – Dean Leffingwall

Agile Project Management With Scrum – Ken Schwaber

Managing Iterative Software Development Projects – Kurt Bittner, Ian Spence

Scott Ambler http://www.ambysoft.com/unifiedprocess/agileUP.html

DSDM http://www.dsdm.org/products/atern.asp

Where to go for the presentation Mike’s blog: http://www.leadingagile.com Brian’s blog: http://blog.softwarearchitecture.com

Mike’s blog: http://www.leadingagile.com

Brian’s blog: http://blog.softwarearchitecture.com

Simplifying Software Delivery