Innovate session-2333

Innovate session-2333
© 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
1 Please note IBM’s statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM’s 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 user’s 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.
2 Agenda • Scrum basics • Challenge scaling core agile • Scaling Factors - identifying what needs scaling • Solution Overview • Mapping out the Journey • Summary
3 How Agile Teams Work
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 The New Normal Deliver code faster, cheaper and better 6
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
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
99 Giving managers Visibility… …while allowing developers to Focus Growing beyond a small adoption
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
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 don’t address distributed team members set the organization up for failure Practices that don’t 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
12 Agenda • Scrum basics • Challenge scaling core agile • What must be scaled • Solution Overview • Mapping out the Journey • Summary
13 Scaling beyond Scrum Transforming your organization requires the right framework and tooling 13
14 Scale agile capabilities to adapt to a customer’s 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”
1515 Domain Complexity Straight -forward Intricate, emerging Compliance requirement Low risk Critical, audited Team size Under 10 developers 1000’s 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 Scaling Agile Requires a Framework
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.”
19 Team Services Teams – These teams support common services across product lines. These teams support the needs of the product teams.
20 Scaling Agile Requires Teams / Project Structure
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
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
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
24 Scaling Agile Requires New Roles For the Teams
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
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
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
28 Scaling Agile Requires Scaling Planning
29 Portfolio Teams Kanban Planning
30 Kanban creates a Pull System that is limited by your Actual Capacity
31 31 Epics span release Investment Themes are approved (1 or more ARTs may to be needed executedIdeas Kanban WIP limits Ideas
32 Program Teams Portfolio Teams Kanban Kanban Planning
(*) 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
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
35 Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Planning
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
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
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
39 Scaling Agile Requires Scaling Requirements
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
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
42 EPICS
43 FEATURES
44 STORIES
45 Mapping out the Journey
46 Defining the Roadmap Assessment Targeted Coaching Measure Improvement • Identify Business Drivers • Identify Gaps in Current Delivery Processes • Identify Pilot Structure
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
48 Define the Operational Framework Structure GovernanceMetrics Assessment Targeted Coaching Measure Improvement Form Teams Teach Practices Guide Culture • Portfolio • Program • Project
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
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.
51 Thank You! Your Feedback is Important! Access the Innovate agenda tool to complete your session surveys from your smartphone, laptop or conference kiosk.

Check these out next

Innovate session-2333

Recomendados

Más contenido relacionado

Presentaciones para ti(20)

Destacado(20)

Similar a Innovate session-2333(20)

Más de Reedy Feggins Jr(7)

Último(20)

Innovate session-2333