Preview:
Citation preview
- 1. 2014 IBM Corporation Session 2333A Scaling Agile Planning to
Support Large Distributed Programs Reedy Feggins. Jr., SPC, CSM,
PMP rfeggins@us.ibm.com 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
- 35. 34 34 Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6
Sprint 7 Sprint 8 Sprint 9 Sprint 10 Sprint 11 Sprint 12 Sprint
Agile Release Production Release 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
- 40. 39 Scaling Agile Requires Scaling Requirements
- 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.