scaling agile scrum practices 2.0
TRANSCRIPT
®
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/
IBM Software Group | Rational software
3
Agenda
� Why Scaling Agile is difficult
� Agile Scaling Model
� What to Scale
� Case Studies
� Parting Thoughts
IBM Software Group | Rational software
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
IBM Software Group | Rational software
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
IBM Software Group | Rational software
6
Scrum
� Scrum works well for small, co-located teams and can be scaled for more complex situations
IBM Software Group | Rational software
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
IBM Software Group | Rational software
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
IBM Software Group | Rational software
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)
IBM Software Group | Rational software
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
IBM Software Group | Rational software
11
Agenda
� Challenges Scaling Agile
� Agile Scaling Model
� What to Scale
� Case Studies
� Parting Thoughts
IBM Software Group | Rational software
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
IBM Software Group | Rational software
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
IBM Software Group | Rational software
14
IBM Software Group | Rational software
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
IBM Software Group | Rational software
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
IBM Software Group | Rational software
17
Agenda
� Challenges Scaling Agile
� Agile Scaling Model
� What to Scale
� Case Studies
� Parting Thoughts
IBM Software Group | Rational software
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
IBM Software Group | Rational software
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
IBM Software Group | Rational software
20
Scale to support Entire life cycle
Sprint 1 Sprint 2 Sprint 3 ….. Sprint X
IBM Software Group | Rational software
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.
IBM Software Group | Rational software
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
IBM Software Group | Rational software
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
IBM Software Group | Rational software
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
IBM Software Group | Rational software
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
IBM Software Group | Rational software
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!
IBM Software Group | Rational software
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
IBM Software Group | Rational software
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
IBM Software Group | Rational software
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
IBM Software Group | Rational software
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
IBM Software Group | Rational software
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
IBM Software Group | Rational software
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
IBM Software Group | Rational software
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
IBM Software Group | Rational software
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
IBM Software Group | Rational software
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)
IBM Software Group | Rational software
36
Agenda
� Challenges Scaling Agile
� Agile Scaling Model
� What to Scale
� Case Studies
� Parting Thoughts
IBM Software Group | Rational software
37
Agenda
� Challenges Scaling Agile
� Agile Scaling Model
� What to Scale
� Case Studies
� Parting Thoughts
IBM Software Group | Rational software
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
IBM Software Group | Rational software
39
IBM Software Group | Rational software
40
Visit us at:
@ Rational Brasil
@ Rational Users Group@ IBM Rational Software
@ IBM Brasil – Rational@ IBM Brasil – Plataforma Jazz
@ O Mundo depende de Software
IBM Software Group | Rational 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
IBM Software Group | Rational software
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