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.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

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 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.

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

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

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/ 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

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.com
Brian’s blog: http://blog.softwarearchitecture.com

Simplifying Software Delivery

http://www.leadingagile.com	389
http://paper.li	24
http://www.slideshare.net	17
http://digitaltube.blogspot.com	5
http://a0.twimg.com	2
url_unknown	1
http://trunkly.com	1
http://leadingagile.blogspot.in	1
http://webcache.googleusercontent.com	1
http://translate.googleusercontent.com	1

Using RUP As A Scaling Framework For Scrum

by Mike Cottmeyer

Accessibility

Categories

Upload Details

Usage Rights

10 Embeds 442

Statistics

Using RUP As A Scaling Framework For Scrum Presentation Transcript