Using RUP As A Scaling Framework For Scrum

Using the Unified Process as a Scaling Framework for Scrum

Where to go for the presentation

Mike’s blog: http://www.leadingagile.comBrian’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

Who is Brian Sondergaard?

• 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

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

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

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

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

…a little more story

• 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

Big company overhead

• Document based tollgates

• Corporate governance and decision making

• Traditional Project Management Offices

Agile offers only partial coverage

Mike Griffiths, Leading Answershttp://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.

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

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

Is this even agile?

• 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

Scrum-but introduces 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

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

Why bother talking about UP

• 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

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

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

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!

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

What agile should I keep?

• 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

What agile stuff might go away?

• 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

42

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

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

UP phases explained

ConstructionConstructionElaborationElaborationInceptionInception TransitionTransition

LifecycleObjectiveMilestone

LifecycleArchitectureMilestone

Initial OperationalCapabilityMilestone

ProductRelease

Milestone

Are the technical Are the technical risks mitigated?risks mitigated?

Are the Are the logistical risks logistical risks mitigated?mitigated?

Are the business Are the business risks mitigated?risks mitigated?

Are we really Are we really ready to ship a ready to ship a complete complete robust product robust product to market?to market?

Effort and duration by phase

Inception Elaboration Construction Transition

Effort 5% 20% 65% 10%

Schedule 10% 30% 50% 10%

Inception Elaboration Construction Transition

A more Agile representation?

Iteration Zero Iteration H

Iteration 1 Iteration 2 Iteration 3

Internal Release*

Phases are time boxes for dealing with risk

With phases as the key concept…

• 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

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

Collaborative Model

Project Manager

Inception Artifacts

• 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

Elaboration Activities

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

Scrum of Scrums

Epic/System Perspective

Feature/SubsystemPerspective

Story/Component/ DesignPerspective

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

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

Construction Outcomes

• 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

Construction Artifacts

• 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

Transition Activities

• Review• Documentation• Last minute bug

fixes• Last minute

backlog changes

Transition Artifacts

• Hand off docs• Final user

documentation• Packaging• Website• Marketing

Role of documentation

Managing Complexity

• 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

Valuable RUP concepts

• 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

Where to go for the presentation

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

Simplifying Software Delivery