scaling agile scrum practices 2.0

®

IBM Software Group

© 2012 IBM Corporation

Scaling Agile 2.0Scaling Scrum to Disciplined Agile Delivery

Reedy FegginsCSM, PMP, WW Solution Architect

IBM Software Group | Rational software

2

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/


3

Agenda

� Why Scaling Agile is difficult

� Agile Scaling Model

� What to Scale

� Case Studies

� Parting Thoughts


4

Traditional

• The waterfall model is a sequential process in which progress is seen as flowing steadily downwards through the phases of

Conception Construction Initiation TestingAnalysis ProductionDesign Maintenance

Traditional Agile

Waterfall


5

Agile Practices

Agile, XP and Scrum

Scrum

• 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

Extreme Programming (XP)

Traditional Agile

Lean

Waterfall


6

Scrum

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


7

Challenges with using ScrumWhat about distributed teams

� Hard to conduct effective Standup meetings

� Communication barriers

� Fractured teams

But what about big projects

� Teams too large (15 – 20)

� Overlapping work-streams


8

Challenges with using Scrum

But what a hybrid projects where � Long-range planning is required� Multiple stakeholders (but no one

Product Owner)

But what a hybrid projects where � PM must track resources and

budgets� Part-time resources


9

Examining Scrum

Advantages� Focused on software construction

by delivering value in 2 or 4 week cycles

� Solid, proven kernel for effective software development

� #1 Agile software development framework used today

� Simple framework into which good practices "plug in"

� Defines key points where team engages stakeholders

But it’s missing…� Guidance on how to scaling and

which factors to consider

� How to coordinate large-scale project to deliver value each Sprint

� How to prepare large-scale Scrum Teams to work together

� How to work together as a global Scrum Team

� How to deal with hybrid processes (traditional projects still exist)


10

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

11/20/2012

10

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


11

Agenda

� Challenges Scaling Agile


� What to Scale

� Case Studies



12

What is the IBM Agile Scaling Model (ASM)

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

Disciplined Agile Delivery� 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

Agility at Scale

� Scales to address more scaling factors� Technically complex development, hybrid projects� Multiple teams from different organizations

Core


13

What is the IBM Agile Scaling Model (ASM)

� Scales to address more scaling factors

� Technically complex development, hybrid projects

� Multiple teams from different organizations

Agility at Scale Disciplined Agile Delivery

Core Agile Development

Focus is on software construction (Scrum, XP)

Develop high-quality code in an self-organizing manner

Value-driven lifecycle with regular production of working software

Small co-located team developing software

Add practices for geo –team, large projects straightforward solution

Scales to include “right amount“ of governance

Extends Scrum to address full system lifecycle (project startup, software deployment


14


15

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 foundation which reflects organizations 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.

5. The “glue” which pulls everything together.

2. Principles3. Practices

4. Process5. Tools


16

Domain Complexity

Straight-forward

Intricate,emerging

Compliance requirement

Low risk Critical,audited

Team size

Under 10developers

1000’s ofdevelopers

Co-located

Geographical distribution

Global

Enterprise discipline

Projectfocus

Enterprisefocus

Technical complexity

HomogenousHeterogeneous,

legacy

Organization distribution(outsourcing, partnerships)

Collaborative Contractual

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

Disciplined Agile

Delivery

Flexible Rigid

Organizational complexity


17

Agenda



� What to Scale

� Case Studies



18

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


19

Scrum – Focuses on Construction

� Scrum assumes Product Backlog has been groomed or can be easily defined

� Assumes Project funding, high level scope, team and infrastructure are in place

� Management buys in to project goals

� Scrum assumes Product Backlog has been groomed or can be easily defined

� Assumes Project funding, high level scope, team and infrastructure are in place

� Management buys in to project goals

Sprint 0 is short Production

handoffs are easy

Sprint 1 Sprint 2 Sprint 3 ….. Sprint X


20

Scale to support Entire life cycle

Sprint 1 Sprint 2 Sprint 3 ….. Sprint X


21

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.


22

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

� User Story Driven Development

� Continuous Integration & Deployment

� Iterative Development

� Retrospectives

� Test Driven Development

� Daily Scrums

� Pair Programming

� Whole Team

� Automated unit testing

� Sustainable Pace

� Automated Metrics

� Parallel Independent Testing

� Product Backlog

� Value Driven Lifecycle

� Self Organization

� Release Planning

� Sprint Planning

� Sprint Demo

� Architecture Envisioning

� Architecture Spike

� Shared Vision

� Refactoring

� User Acceptance Testing

� Continuous Documentation

22


23

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


24

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


25

Scaling Product Owner

Product owner is really a communication conduit bet ween the teamand 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


26

Add Additional Roles as RequiredArchitecture 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� Sometimes component sub-teams require people focused

on narrow specialties� E.g. Business analysts, security experts, database

administrators, usability professionals

Note: Many of these additional roles may be needed on

smaller teams too!


27

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


28

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


29

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


30

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


31

Scaling Daily Stand Up Meetings

Geographic distribution�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

Organizational distribution�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


32

Scaling Sprint Demos

� Geographic distribution� 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

� Regulatory compliance

� Take meeting attendance and record action items (if any)

� Domain complexity� Invite a wider range of stakeholders required, not just insiders

� Organizational distribution� 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


33

Scaling reflections/retrospectives� Disciplined agile delivery� Track your progress with IBM Rational SelfCheck

� Geographic distribution� Hold retrospectives electronically to include everyone

� Team size� Subteams should hold their own retrospectives

� Subteams should share ideas with each other

� Regulatory compliance� May need to record any changes to your process

� Organizational distribution� May not be allowed to share improvements between organizations

� Organizational complexity� 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

� Enterprise discipline� Consider an agile center of competency (CoC) to share ideas


34

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


35

Scaling self organization� Disciplined agile delivery�Disciplined agile developers are self organizing within an appropriate governance

framework

� Regulatory compliance�Plans, estimates, and so on may need to be recorded

� Organizational complexity�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

� Enterprise discipline�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)


36

Agenda



� What to Scale

� Case Studies



37

Agenda



� What to Scale

� Case Studies



38

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

Jazz is an open platform with a shared set of services

c

Existing Rational Offerings

New Rational/ IBM Offerings

Business PartnerOfferings

Product & Project

Management

Compliance&

Security

Collaborative Lifecycle

Management 3rd-PartyJazz

Capabilities

FutureIBM

Capabilities

StorageCollaboration

QueryDiscovery

Administration: Users, projects, process

Best Practice Processes

Presentation:Mashups

Design&

Development

Business Planning

& Alignment

YourExisting

Capabilities


39


40

Visit us at:

@ Rational Brasil

@ Rational Users Group@ IBM Rational Software

@ IBM Brasil – Rational@ IBM Brasil – Plataforma Jazz

@ O Mundo depende de Software


41

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


42

© Copyright IBM Corporation 2010. All rights reserv ed. 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.

www.ibm/software/rational

scaling agile scrum practices 2.0

Technology

agile agile scaling

agile projects

software groupscaling

scaling scrum

agile coach

differentcore agile

agile methodswhat

agile journey