Scaling agile scrum practices 2.0

®

IBM Software Group

Scaling Agile 2.0
Scaling Scrum to Disciplined Agile Delivery
Reedy Feggins
CSM, PMP, WW Solution Architect

© 2012 IBM Corporation

IBM Software Group | Rational software

About the author

Reedy Feggins World-Wide Solution Architect, Agile Coach and Certified
ScrumMaster (CSM) at IBM Rational Software focused on
Increasing client competitiveness through adoption of agile practices, business
process optimization and Collaborative Lifecycle Management (CLM) tools
Holds certifications both as Scrum Master and Project Management Professional
(PMP), having spent the past five years in Agile projects in large organizations.
His agile journey began in 1997 with a small business within the AT&T, called
AT&T PersonalLink, and since then never stopped; has coached teams in agile
methods, including RAD, XP, Scrum, and RUP Lean / Kanban.

Reedy is has successfully deployed CLM at several Fortune 500
organizations and is a strong contributor within the Agile community
Personal Blogs: http://smoovejazz.wordpress.com/

2


Agenda

Why Scaling Agile is difficult
Agile Scaling Model
What to Scale
Case Studies
Parting Thoughts

3


Traditional

Traditional Agile

Waterfall

• The waterfall model is a sequential process in which progress is seen as
flowing steadily downwards through the phases of
Conception Construction
Initiation Testing
Analysis Production
Design Maintenance

4


Agile, XP and Scrum

Traditional Agile
Agile
Lean
Practices
Waterfall
Extreme
Scrum Programming (XP)

• Scrum is the most common agile software development method for
managing software projects and product or application development.

• Sprints last between one week and one month,5 and are a "timeboxed"
(i.e. restricted to a specific duration) effort of a constant length.7

5


Scrum

Scrum works well for small, co-located teams and can be scaled for
more complex situations

6


Challenges with using Scrum
What about distributed teams
But what about big projects
Hard to conduct effective
Teams too large (15 – 20) Standup meetings

Overlapping work-streams Communication barriers
Fractured teams

7


Challenges with using Scrum
But what a hybrid projects where
But what a hybrid projects where PM must track resources and
Long-range planning is required budgets
Multiple stakeholders (but no one Part-time resources
Product Owner)

8


Examining Scrum

Advantages But it’s missing…
Focused on software construction Guidance on how to scaling and
by delivering value in 2 or 4 week which factors to consider
cycles
How to coordinate large-scale
Solid, proven kernel for effective project to deliver value each Sprint
software development
How to prepare large-scale Scrum
#1 Agile software development Teams to work together
framework used today
How to work together as a global
Simple framework into which good Scrum Team
practices "plug in"
How to deal with hybrid processes
Defines key points where team (traditional projects still exist)
engages stakeholders

9


Scaling Agile is Difficult

One of the major areas organizations are struggling with
today is how to scale Agile methods
What works on small, co-located teams may be tough to duplicate on
more “real life” projects

Many times individual teams customize Scrum so practices vary from
one project to another, or another, or another…

Most Agile vendors have presentations and white papers on scaling but
often fail to provide details on which practices and why

IBM addressed scaling agile head-on with Disciplined Agile Delivery (DAD) and
Agility@Scale which are designed to reduce risk and drive better results faster

10
11/20/2012
10


Agenda

Challenges Scaling Agile
Agile Scaling Model
What to Scale
Case Studies
Parting Thoughts

11


What is the IBM Agile Scaling Model (ASM)
Agility at Scale
Scales to address more scaling factors
Technically complex development, hybrid projects
Multiple teams from different organizations

Disciplined Agile Delivery
Core Extends Scrum to address full system lifecycle (project startup,
software deployment)
Scales self organization to include appropriate governance
Adds practices to support distributed team delivering a
straightforward solution

Core Agile Development
Focus is on construction (Scrum, XP)
Goal is to develop a high-quality system in an evolutionary, collaborative, and
self-organizing manner
Value-driven lifecycle with regular production of working software
Small, co-located team developing straightforward software
12


What is the IBM Agile Scaling Model (ASM)

Agility at
Scale Disciplined Agile Delivery
Scales to address Add practices for geo – Scales to include Extends Scrum to
more scaling factors team, large projects “right amount“ of address full system
straightforward solution governance lifecycle (project startup,
Technically complex software deployment
development, hybrid
projects
Multiple teams from
different
Core Agile Development
organizations
Focus is on software Small co-located team
construction (Scrum, XP) developing software

Value-driven lifecycle with regular Develop high-quality code in
production of working software an self-organizing manner

13


14


The “5Ps” of IT: Look at the Big Picture

To achieve systemic improvement within an IT organization,
you need to address five primary issues:

1. People 1. Solution delivery is a “team sport”,
individuals and how they work together are
the primary determinants of success on most
projects.
2. Teams must have a coherent philosophical
2. Principles foundation which reflects organizations
3. Practices values to help guide decisions.
3. Effective practices or procedures describing
how people work together to achieve a goal.
4. The tools and technologies which people use
to perform their work.
4. Process
5. Tools
5. The “glue” which pulls everything together.

15


Challenges to Scaling Agile (i.e., Agile Scaling Factors)

Team size Compliance requirement
Under 10 1000’s of Critical,
developers developers Low risk
audited

Geographical distribution Domain Complexity
Straight Intricate,
Co-located Global -forward emerging

Disciplined
Enterprise discipline Agile Organization distribution
Project Enterprise
Delivery (outsourcing, partnerships)
focus focus Collaborative Contractual

Organizational complexity Technical complexity
Flexible Rigid Heterogeneous,
Homogenous legacy

16


Agenda

Agile Scaling Model
What to Scale
Case Studies
Parting Thoughts

17


Scrum Practices
Single Product Backlog
Rank-prioritized list of requirements (usually Epics and User stories)
Value-Driven Lifecycle
Deliver potentially shippable software each sprint

Planning at Multiple Levels
Release Planning – Continuously develop and maintain a high-level project plan
Sprint Planning – Each Sprint, the team plans what and how they will deliver
Daily Scrum Meeting – Each day hold a 15 minute coordination meeting

Self Organizing Teams
Sustainable Pace - At start of each Sprint team estimates work based on priorities set
by Product Owner and commits to work they can complete
Sprint Demo – At the end of the sprint demo what you’ve built to key stakeholders
Reflections – At the end of the sprint the team identifies potential improvements to the
way that they work
18


Scrum – Focuses on Construction

Sprint 1 Sprint 2 Sprint 3 ….. Sprint X

Sprint 0 is
Production
short
handoffs are
easy

Scrum assumes Product Backlog has Scrum assumes Product Backlog has
been groomed or can be easily defined been groomed or can be easily defined
Assumes Project funding, high level Assumes Project funding, high level
scope, team and infrastructure are in scope, team and infrastructure are in
place place
Management buys in to project goals Management buys in to project goals

19


Scale to support Entire life cycle

Sprint 1 Sprint 2 Sprint 3 ….. Sprint X

20


Scaling Value Lifecycle to Risk-Value Lifecycle
Provides the extended team with explicit milestones centered on balancing risk
mitigation and value creation
Observations:
Key stakeholders frequently do not have time to carefully review and discuss the results of
every iteration.
Iteration demos are still a good idea for getting feedback.
Fewer key milestones where go/no-go decisions are made are actually needed.

21


Agile Practices – how do you ensure these are being
executed repeatedly and consistently across many
projects?

User Story Driven Development Product Backlog
Continuous Integration & Deployment Value Driven Lifecycle
Iterative Development Self Organization
Retrospectives Release Planning
Test Driven Development Sprint Planning
Daily Scrums Sprint Demo
Pair Programming Architecture Envisioning
Whole Team Architecture Spike
Automated unit testing Shared Vision
Sustainable Pace Refactoring
Automated Metrics User Acceptance Testing
Parallel Independent Testing Continuous Documentation

22


Which Practices to scale

Most Core Scrum practices can / should be scaled as needed
Scrum roles
Release Planning
Sprint Planning
Sprint Demos / Retrospectives
Some practices are more challenging to scale then others to be effective
Self-organizing teams
Daily Meetings
Product Backlog
Scaling some practices require tool support
Continuous Integration
Portfolio Planning
Sometimes additional practices must be added
Independent Testers
Architecture Envisioning

23


Scale Scrum roles to be more realistic

Scrum Master
Leader/coach
Facilitates scrum meetings such
as sprint planning, sprint demo,
and daily Scrum meetings
Product Owner
Represents the stakeholders
Owns the product backlog,
including the requirements
Provides information and makes
decisions in a timely manner
“The one neck to wring”
Team Member
Anyone else on the team
Developers, Testers, Business
Analysts
24


Scaling Product Owner

Product owner is really a communication conduit between the team
and stakeholders
Owns the work item list, including the requirements
Must have agile business analysis skills
Will often work with business analysts who elicit requirements from others
PO gets the team access to the relevant stakeholders just in time
Needs to negotiate, negotiate, negotiate

25


Add Additional Roles as Required
Architecture Owner
Facilitates technical decisions
Coordinates technical discussions between teams

Domain Expert
Has detailed knowledge about one or more aspects of the
problem domain

Technical Expert
Has detailed technical knowledge needed for short period

Independent Tester
Focuses on complex testing efforts, working parallel but
independent of the team

Integrator
Responsible for building the entire system from its various
subsystems

Specialist
Note: Many of these additional
roles may be needed on
Sometimes component sub-teams require people focused
on narrow specialties
smaller teams too!
E.g. Business analysts, security experts, database
administrators, usability professionals
26


Scaling Product Backlogs: Work Item Lists

Development teams do
more than just implement
requirements, they also fix
defects, go on training,
review the work of other
teams, and so on. All of this
work needs to be taken into
account when planning.
Smart teams look a few
iterations down the stack for
complex work items and
then mitigate the risk by
modeling a bit ahead.
www.jazz.net

27


Scaling product backlogs
Disciplined agile delivery
Defects treated like requirements and managed on backlog
Non-functionality work items, such as training, reviews, can be managed on backlog
Geographic distribution
Manage the backlog electronically
Team size
Subteams may have their own backlogs, but that makes rollups harder
Burndowns of subteams need to be rolled up into overall team burndown
Regulatory compliance
May need to manage backlog electronically
Domain complexity
Business analysts look ahead on the product backlog to explore upcoming complexities
Organizational distribution
A given organizational unit may only be allowed to see portions of the backlog
Technical complexity
Team members look a bit ahead on stack to consider upcoming complexities
Organizational complexity
Your team may need to conform to existing change management processes
Enterprise discipline
Electronic backlog management enables automation of burndown charts and other metrics via project
dashboard (e.g. in Rational Team Concert), supporting improved governance
28


Scaling release planning
Geographic distribution, Large team size
Plan needs to be captured electronically so that everyone has access
Sprint lengths/rhythms of the sub-teams should be a divisor of the larger team
Sub-teams may need their own release plans
Overall plan must reflect the plans of the sub-teams

Technical complexity, Organizational complexity
Dependencies on other teams are critical and need to be reflected in release plan,
particularly non-agile teams which have lower chances of on-time delivery
Dependencies on non-agile teams may require changes in the strategies of all
teams involved

Organizational distribution, Regulatory compliance, Enterprise
discipline
Release plan must reflect portfolio-level and product-level plans
Plan, and updates to it, may need to be documented
Planning across multiple organizations will potentially take longer and require
greater detail

29


Scaling sprint planning
Geographic distribution, Regulatory compliance
Capture plans electronically
Sprint plans may need to be documented

Team size
Scrum Masters must coordinate with each other on major dependencies
spanning sub-teams
Each sub-team is responsible for its own iteration planning and need to
Teams needs to be aware of dependencies particularly when sub-teams
have different iteration lengths/schedules
More upfront Sprint grooming required to review user stories, estimate,
discuss dependencies, reduce duplications across stories,…

Domain complexity, Technical complexity
Teams need to engage in look-ahead planning, not just plan for upcoming
sprint
Teams need to be aware of technical dependencies between subsystems
30


Scaling Daily Stand Up Meetings

Meeting occurs over phone, video, electronically…
Rational Team Concert (RTC) to share information
Change meeting times to reflect team distribution – spread the pain

Team size
Kanban strategy is to ask 1 question: What new issues do you foresee?
“scrum of scrums” to coordinate subteams

Add more coordination between organizations
Adopt Project dashboards to share with external organizations
Add more formal decisions/action and document items pertaining to external
organizations

31


Scaling Sprint Demos
Demos occurs physically where possible, but transmitted electronically
Change demo times to reflect team distribution – spread the pain
Greater need to schedule the demos ahead of time
Team size
Prioritize which subteam(s) should demo to the entire team
Individual subteams should do their own demos to their smaller community
Take meeting attendance and record action items (if any)
Domain complexity
Invite a wider range of stakeholders required, not just insiders
Invite stakeholders from each organization unit
Separate demos may be required by some organization units specific to them
Technical complexity
Some of the work may not be visible through user interface, so may need to do a
technical walkthrough instead

32


Scaling reflections/retrospectives
Track your progress with IBM Rational SelfCheck
Hold retrospectives electronically to include everyone
Team size
Subteams should hold their own retrospectives
Subteams should share ideas with each other
May need to record any changes to your process
May not be allowed to share improvements between organizations
Existing process improvement strategies may focus on reviews (post mortems) at the end of
the project
Process improvement may be “owned” by a specific process group
Consider an agile center of competency (CoC) to share ideas

33


Scaling Self-Organization
Lean development governance
Teams don’t work in a vacuum
Self-governance must be constrained by enterprise goals and
environment
Lean Development Governance paper by Ambler and Kroll, 2008
Automated measurements and project dashboards
It is possible to streamline much of the Scrum bureaucracy
through automation
This is true empiricism, not just marketing rhetoric
Rational Team Concert (RTC) for project dashboard
Rational Insight for portfolio-level dashboard
Adopt corporate development conventions
“Enforce” and monitor via static analysis tools

34


Scaling self organization
Disciplined agile developers are self organizing within an appropriate governance
framework
Plans, estimates, and so on may need to be recorded
May need to educate management team on collaborative leadership and facilitation
May need to provide education to help others shift from command-control to self-
organizing
Application architecture decisions are constrained by enterprise infrastructure and
futures directions
Application architecture enhanced by leveraging existing infrastructure and
reusable assets
Release plan must reflect portfolio and project plans
Agile teams should follow enterprise-level guidelines (e.g. coding standards, data
standards, UI standards, …)
Adopt a Lean Development Governance strategy (see paper by Ambler and Kroll)
35


Agenda

Agile Scaling Model
What to Scale
Case Studies
Parting Thoughts

36


Agenda

Agile Scaling Model
What to Scale
Case Studies
Parting Thoughts

37


Jazz is an open platform with a shared set of services

c
Existing Rational New Rational/ Business Partner
Offerings IBM Offerings Offerings

Business
Your Planning
Existing & Alignment
Capabilities Product Compliance Collaborative
& Project & Lifecycle Design
Future Management Security Management & 3rd-Party
IBM Development Jazz
Capabilities Capabilities
Best Practice Processes

Administration: Users,
Collaboration projects, process
Presentation: Storage
Mashups Discovery Query

Jazz is…
A scalable, extensible team collaboration platform which supports Scrum development
A community at Jazz.net, where you can see Jazz-based products being built
An integration architecture, enabling mashups and non-Jazz based products to participate

38


39


Visit us at:
@ Rational Brasil

@ Rational Users Group
@ IBM Rational Software

@ IBM Brasil – Rational
@ IBM Brasil – Plataforma Jazz

@ O Mundo depende de Software

40


References
Scott Ambler. The Agile Scaling Model (ASM),
ftp://ftp.software.ibm.com/common/ssi/sa/wh/n/raw14204usen/RAW14204USEN.PDF

Scott Ambler. Scaling Agile: An Executive Guide,
ftp://public.dhe.ibm.com/common/ssi/sa/wh/n/raw14211usen/RAW14211USEN.PDF

Scott Ambler. Improving Software Economics: Top 10 Principles of Achieving
Agility@Scale,
ftp://public.dhe.ibm.com/common/ssi/ecm/en/raw14148usen/RAW14148USEN.PDF

Enable the Agile Enterprise Through Incremental Adoption of Practices,
http://public.dhe.ibm.com/common/ssi/ecm/en/raw14077usen/RAW14077USEN.PDF

Disciplined Agile Delivery: An Introduction,
http://public.dhe.ibm.com/common/ssi/ecm/en/raw14261usen/RAW14261USEN.PDF

Per Kroll. “Measuring the Results of Your Agile Adoption - Using the Measured Capability
Improvement Framework”

Ted Rivera, Ed Richard. Core Iteration Metrics. “Agile and Lean Metrics: Quantifying
Agile Adoption and Business Contribution across the Entire Value Stream”

ScrumSenses, “Agile Metrics”. http://ww.scrumsense.com/coaching/metrics

41


www.ibm/software/rational

© Copyright IBM Corporation 2010. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind,
express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have
the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM
software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities
referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future
product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, Telelogic, the Telelogic logo, and other IBM products and services
are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product,
or service names may be trademarks or service marks of others.

42

Scaling agile scrum practices 2.0

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Scaling agile scrum practices 2.0

Similar to Scaling agile scrum practices 2.0 (20)

More from Reedy Feggins Jr

More from Reedy Feggins Jr (9)

Recently uploaded

Recently uploaded (20)

Scaling agile scrum practices 2.0