1. 2014 IBM Corporation Session 2333A Scaling Agile Planning to
Support Large Distributed Programs Reedy Feggins. Jr., SPC, CSM,
PMP [email protected] Software Delivery Leader / Agile Coach
2. 1 Please note IBMs statements regarding its plans,
directions, and intent are subject to change or withdrawal without
notice at IBMs sole discretion. Information regarding potential
future products is intended to outline our general product
direction and it should not be relied on in making a purchasing
decision. The information mentioned regarding potential future
products is not a commitment, promise, or legal obligation to
deliver any material, code or functionality. Information about
potential future products may not be incorporated into any
contract. The development, release, and timing of any future
features or functionality described for our products remains at our
sole discretion. Performance is based on measurements and
projections using standard IBM benchmarks in a controlled
environment. The actual throughput or performance that any user
will experience will vary depending upon many factors, including
considerations such as the amount of multiprogramming in the users
job stream, the I/O configuration, the storage configuration, and
the workload processed. Therefore, no assurance can be given that
an individual user will achieve results similar to those stated
here.
3. 2 Agenda Scrum basics Challenge scaling core agile Scaling
Factors - identifying what needs scaling Solution Overview Mapping
out the Journey Summary
4. 3 How Agile Teams Work
5. 4 Sprint User Story User Story User Story Epic Epic User
Story SprintPlanning Design Test Integrate Deploy Refine Story
Develop Demo/Retrospective DatabaseDatabase ReportsReports UI
Screen UI Screen Application Process Financial Application X
Identify Develop and Test Demo Deliver Business Objectives Measured
Progress Scrum
6. 5 Agenda Scrum basics Challenge scaling core agile Scaling
Factors - identifying what needs scaling Solution Overview Mapping
out the Journey Summary
7. 6 The New Normal Deliver code faster, cheaper and better
6
8. 7 Adopting an agile approach is a great start Agile succeeds
three times more often than non-agile projects The Chaos Manifesto,
Standish Group 2012 Agile succeeds three times more often than
non-agile projects The Chaos Manifesto, Standish Group 2012
9. 8 Organizations have had success with agile... yet few have
been able to realize the full potential 8 65% of organizations
consider [complex] tool integrations a key inhibitor to success 42%
of agile projects are considered successful 26% of organizations
use agile ONLY in development Sources: Sources: NIST, Planning
Report 02-3. The Economic Impacts of Inadequate Infrastructure for
Software Testing, May 2002; aThe Times of India, IT sector to get
12% average salary hike in 2011, TOI Tech & Agencies, Mar 8,
2011, Forrester Research, 2012
10. 99 Giving managers Visibility while allowing developers to
Focus Growing beyond a small adoption
11. 10 Impediments agile developers face that ultimately slow
team velocity 1. Lost time due to task switching between tools or
duplication of work 2. Difficulty in coordinating different agile
teams with conflicting priorities 3. Inconsistent continuous
integration and deployment practices 4. Being disconnected from
customers and stakeholders Instant Messages Spreadsheets Tools
12. 11 Management challenges in growing an agile practice 11
Participation by operations and stakeholders are key to continuous
delivery Participation by operations and stakeholders are key to
continuous delivery Lack of a roadmap, milestones and measurements
cause inefficient and inconsistent execution Lack of a roadmap,
milestones and measurements cause inefficient and inconsistent
execution Practices that dont address distributed team members set
the organization up for failure Practices that dont address
distributed team members set the organization up for failure Siloes
of loosely integrated tools impairs project visibility and
unpredictable results Siloes of loosely integrated tools impairs
project visibility and unpredictable results Team members not
equipped with the right training, tooling and access to practices
Team members not equipped with the right training, tooling and
access to practices StrategyStrategy CultureCulture TeamsTeams
ToolingTooling PeoplePeople
13. 12 Agenda Scrum basics Challenge scaling core agile What
must be scaled Solution Overview Mapping out the Journey
Summary
14. 13 Scaling beyond Scrum Transforming your organization
requires the right framework and tooling 13
15. 14 Scale agile capabilities to adapt to a customers needs I
need to collaborate with my operations team and help them deploy
software more frequently I need to assure testing can keep up with
our agile development. We are planning to deliver mobile apps to
our customers that extend our enterprise solutions I need to
connect and prioritize projects with stakeholders
16. 1515 Domain Complexity Straight -forward Intricate,
emerging Compliance requirement Low risk Critical, audited Team
size Under 10 developers 1000s of developers Co-located
Geographical distribution Global Enterprise discipline Project
focus Enterprise focus Technical complexity Homogenous
Heterogeneous, legacy Organization distribution (outsourcing,
partnerships) Collaborative Contractual IBM Agility@Scale: A
process framework to extend your agile practice Flexible Rigid
Organizational complexity
17. 16 Agenda Scrum basics Challenge scaling core agile Scaling
Factors - identifying what needs scaling Solution Overview Mapping
out the Journey Summary
18. 17 Scaling Agile Requires a Framework
19. 18 Disciplined Agile The Disciplined Agile Delivery process
decision framework is a people-first, learning-oriented hybrid
agile approach to IT solution delivery. It has a risk-value
delivery lifecycle, is goal- driven, is enterprise aware, and is
scalable.
20. 19 Team Services Teams These teams support common services
across product lines. These teams support the needs of the product
teams.
21. 20 Scaling Agile Requires Teams / Project Structure
22. 21 Scrum Team Scrum Delivery TeamsScrum Team Scrum Team
Scrum Team Scrum Team Scrum Team Scrum Team Scrum Team Project and
Team Structure Product & Services Teams
23. 22 Scrum Delivery Teams Project and Team Structure Scrum
Team Scrum Team Scrum Team Scrum Team Scrum Team Scrum Team Scrum
Team Scrum Team Release Management Team System Team Product
Management Team Program Program Teams
24. 23 Release Management Team Program and Portfolio Management
Team System Team Scrum Team Product Management Team Team Program
Portfolio Scrum Team Scrum Team Scrum Team Scrum Team Scrum Team
Scrum Team Scrum Team Project and Team Structure Product &
Services Teams Program Teams Portfolio Teams
25. 24 Scaling Agile Requires New Roles For the Teams
26. 25 Scaling the Architect Role Source: Agile Portfolio and
Program Management in the Scaled Agile Framework, Dean Leffingwell,
Agile Melbourne Meetup, 15/02/12 Program Mgmt Product Manager
Product Owner
27. 26 Scaling the ScrumMaster Role Source: Agile Portfolio and
Program Management in the Scaled Agile Framework, Dean Leffingwell,
Agile Melbourne Meetup, 15/02/12 Release Train Engineers Scrum
Masters Business Owner
28. 27 Scaling the Architect Role Source: Agile Portfolio and
Program Management in the Scaled Agile Framework, Dean Leffingwell,
Agile Melbourne Meetup, 15/02/12 Enterprise Architect System
Architects Lead Developers
29. 28 Scaling Agile Requires Scaling Planning
30. 29 Portfolio Teams Kanban Planning
31. 30 Kanban creates a Pull System that is limited by your
Actual Capacity
32. 31 31 Epics span release Investment Themes are approved (1
or more ARTs may to be needed executedIdeas Kanban WIP limits
Ideas
33. 32 Program Teams Portfolio Teams Kanban Kanban
Planning
34. (*) Mike Cohn, Agile Estimating and Planning
StrategyStrategy PortfolioPortfolio ProductProduct ReleaseRelease
IterationIteration DailyDaily Agile team must plan at the multiple
levels Product Release Sprint (or Iteration) Daily Scaling
Plans
36. 35 Product & Services Teams Program Teams Portfolio
Teams Scrum Kanban Kanban Planning
37. 36 User Story User Story User Story Epic Epic User Story
Product Backlog Managing the product backlog between product owner
and scrum team A Scrum product backlog contains descriptions of the
functionality desired in an end product. Epic User Story User Story
Epic
38. 37 Sprint User Story User Story User Story Epic Epic User
Story SprintPlanning Design Test Integrate Deploy Refine Story
Develop Demo/RetrospectiveIdentify Develop and Test Business
Objectives Sprint Planning Epic Epic User Story
39. 38 Sprint User Story User Story User Story Epic Epic User
Story SprintPlanning Design Test Integrate Deploy Refine Story
Develop Demo/Retrospective DatabaseDatabase ReportsReports UI
Screen UI Screen Application Process Financial Application X
Identify Develop and Test Demo Deliver Business Objectives Measured
Progress Sprint Delivery
41. 40 Scaling Agile Requirements Investment Themes Feature
Story Story Story Feature Story Story Story Feature Story Story
Story Business and Architectural Epics Epics Feature 40 Approved
Projects Pre-Project Team IdeasIdeasIdeasIdeasIdeas
IdeasIdeasIdeasIdeasIdeas IdeasIdeasIdeasIdeasIdeas
IdeasIdeasIdeasIdeasIdeas Ideas
42. 41 Scaling Agile Requirements Investment Themes Feature
Story Story Story Feature Story Story Story Feature Story Story
Story Business and Architectural Epics Epics Feature 41 Epics span
release Themes may need one or more programs to be executed Stories
fit into Sprints IdeasIdeasIdeasIdeasIdeas
IdeasIdeasIdeasIdeasIdeas IdeasIdeasIdeasIdeasIdeas
IdeasIdeasIdeasIdeasIdeas Ideas Features span sprint sut fit into
release
43. 42 EPICS
44. 43 FEATURES
45. 44 STORIES
46. 45 Mapping out the Journey
47. 46 Defining the Roadmap Assessment Targeted Coaching
Measure Improvement Identify Business Drivers Identify Gaps in
Current Delivery Processes Identify Pilot Structure
48. 47 Define the Operational Framework Assessment Targeted
Coaching Measure Improvement Form Teams Teach Practices Guide
Culture Built around teams Product focused Service oriented Form
Teams Teach Practices Form Teams Teach Practices Teach Practices
Teach Practices
49. 48 Define the Operational Framework Structure
GovernanceMetrics Assessment Targeted Coaching Measure Improvement
Form Teams Teach Practices Guide Culture Portfolio Program
Project
50. 49 Define the Operational Framework Change Management &
Communication Structure GovernanceMetrics Assessment Targeted
Coaching Measure Improvement Form Teams Teach Practices Guide
Culture Return on Investment Throughput Capitalization
51. 50 Acknowledgements and Disclaimers Copyright IBM
Corporation 2012. All rights reserved. U.S. Government Users
Restricted Rights - Use, duplication or disclosure restricted by
GSA ADP Schedule Contract with IBM Corp. Please update paragraph
below for the particular product or family brand trademarks you
mention such as WebSphere, DB2, Maximo, Clearcase, Lotus, etc IBM,
the IBM logo, ibm.com, [IBM Brand, if trademarked], and [IBM
Product, if trademarked] are trademarks or registered trademarks of
International Business Machines Corporation in the United States,
other countries, or both. If these and other IBM trademarked terms
are marked on their first occurrence in this information with a
trademark symbol ( or ), these symbols indicate U.S. registered or
common law trademarks owned by IBM at the time this information was
published. Such trademarks may also be registered or common law
trademarks in other countries. A current list of IBM trademarks is
available on the Web at Copyright and trademark information at
www.ibm.com/legal/copytrade.shtml f you have mentioned trademarks
that are not from IBM, please update and add the following lines:
[Insert any special 3rd party trademark names/attributions here]
Other company, product, or service names may be trademarks or
service marks of others. Availability. References in this
presentation to IBM products, programs, or services do not imply
that they will be available in all countries in which IBM operates.
The workshops, sessions and materials have been prepared by IBM or
the session speakers and reflect their own views. They are provided
for informational purposes only, and are neither intended to, nor
shall have the effect of being, legal or other guidance or advice
to any participant. While efforts were made to verify the
completeness and accuracy of the information contained in this
presentation, it 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, this
presentation or any other materials. Nothing contained in this
presentation 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. All customer
examples described are presented as illustrations of how those
customers have used IBM products and the results they may have
achieved. Actual environmental costs and performance
characteristics may vary by customer. Nothing contained in these
materials is intended to, nor shall have the effect of, stating or
implying that any activities undertaken by you will result in any
specific sales, revenue growth or other results.
52. 51 Thank You! Your Feedback is Important! Access the
Innovate agenda tool to complete your session surveys from your
smartphone, laptop or conference kiosk.