Scaling agile scrum practices 2.0

IBM Software Group | Rational software 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/ 2

IBM Software Group | Rational software Agenda Why Scaling Agile is difficult Agile Scaling Model What to Scale Case Studies Parting Thoughts 3

IBM Software Group | Rational software Traditional Traditional Agile Waterfall • The waterfall model is a sequential process in which progress is seen as flowing steadily downwards through the phases of Conception Construction Initiation Testing Analysis Production Design Maintenance 4

IBM Software Group | Rational software Agile, XP and Scrum Traditional Agile Agile Lean Practices Waterfall Extreme Scrum Programming (XP) • 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 5

IBM Software Group | Rational software Scrum Scrum works well for small, co-located teams and can be scaled for more complex situations 6

IBM Software Group | Rational software Challenges with using Scrum What about distributed teams But what about big projects Hard to conduct effective Teams too large (15 – 20) Standup meetings Overlapping work-streams Communication barriers Fractured teams 7

IBM Software Group | Rational software Challenges with using Scrum But what a hybrid projects where But what a hybrid projects where PM must track resources and Long-range planning is required budgets Multiple stakeholders (but no one Part-time resources Product Owner) 8

IBM Software Group | Rational software Examining Scrum Advantages But it’s missing… Focused on software construction Guidance on how to scaling and by delivering value in 2 or 4 week which factors to consider cycles How to coordinate large-scale Solid, proven kernel for effective project to deliver value each Sprint software development How to prepare large-scale Scrum #1 Agile software development Teams to work together framework used today How to work together as a global Simple framework into which good Scrum Team practices "plug in" How to deal with hybrid processes Defines key points where team (traditional projects still exist) engages stakeholders 9

IBM Software Group | Rational software 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 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 10 11/20/2012 10

IBM Software Group | Rational software Agenda Challenges Scaling Agile Agile Scaling Model What to Scale Case Studies Parting Thoughts 11

IBM Software Group | Rational software What is the IBM Agile Scaling Model (ASM) Agility at Scale Scales to address more scaling factors Technically complex development, hybrid projects Multiple teams from different organizations Disciplined Agile Delivery Core 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 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 12

IBM Software Group | Rational software What is the IBM Agile Scaling Model (ASM) Agility at Scale Disciplined Agile Delivery Scales to address Add practices for geo – Scales to include Extends Scrum to more scaling factors team, large projects “right amount“ of address full system straightforward solution governance lifecycle (project startup, Technically complex software deployment development, hybrid projects Multiple teams from different Core Agile Development organizations Focus is on software Small co-located team construction (Scrum, XP) developing software Value-driven lifecycle with regular Develop high-quality code in production of working software an self-organizing manner 13

IBM Software Group | Rational software 14

IBM Software Group | Rational software 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 2. Principles foundation which reflects organizations 3. Practices 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. 4. Process 5. Tools 5. The “glue” which pulls everything together. 15

IBM Software Group | Rational software Challenges to Scaling Agile (i.e., Agile Scaling Factors) Team size Compliance requirement Under 10 1000’s of Critical, developers developers Low risk audited Geographical distribution Domain Complexity Straight Intricate, Co-located Global -forward emerging Disciplined Enterprise discipline Agile Organization distribution Project Enterprise Delivery (outsourcing, partnerships) focus focus Collaborative Contractual Organizational complexity Technical complexity Flexible Rigid Heterogeneous, Homogenous legacy 16

IBM Software Group | Rational software 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 18

IBM Software Group | Rational software Scrum – Focuses on Construction Sprint 1 Sprint 2 Sprint 3 ….. Sprint X Sprint 0 is Production short handoffs are easy Scrum assumes Product Backlog has Scrum assumes Product Backlog has been groomed or can be easily defined been groomed or can be easily defined Assumes Project funding, high level Assumes Project funding, high level scope, team and infrastructure are in scope, team and infrastructure are in place place Management buys in to project goals Management buys in to project goals 19

IBM Software Group | Rational software Scale to support Entire life cycle Sprint 1 Sprint 2 Sprint 3 ….. Sprint X 20

IBM Software Group | Rational software 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. 21

IBM Software Group | Rational software Agile Practices – how do you ensure these are being executed repeatedly and consistently across many projects? User Story Driven Development Product Backlog Continuous Integration & Deployment Value Driven Lifecycle Iterative Development Self Organization Retrospectives Release Planning Test Driven Development Sprint Planning Daily Scrums Sprint Demo Pair Programming Architecture Envisioning Whole Team Architecture Spike Automated unit testing Shared Vision Sustainable Pace Refactoring Automated Metrics User Acceptance Testing Parallel Independent Testing Continuous Documentation 22

IBM Software Group | Rational software 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 23

IBM Software Group | Rational software 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 24

IBM Software Group | Rational software Scaling Product Owner Product owner is really a communication conduit between the team and 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 25

IBM Software Group | Rational software Add Additional Roles as Required Architecture 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 Note: Many of these additional roles may be needed on Sometimes component sub-teams require people focused on narrow specialties smaller teams too! E.g. Business analysts, security experts, database administrators, usability professionals 26

IBM Software Group | Rational software 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 27

IBM Software Group | Rational software 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 28

IBM Software Group | Rational software 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 29

IBM Software Group | Rational software 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 30

IBM Software Group | Rational software 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 31

IBM Software Group | Rational software 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 32

IBM Software Group | Rational software 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 33

IBM Software Group | Rational software 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 34

IBM Software Group | Rational software 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) 35

IBM Software Group | Rational software Jazz is an open platform with a shared set of services c Existing Rational New Rational/ Business Partner Offerings IBM Offerings Offerings Business Your Planning Existing & Alignment Capabilities Product Compliance Collaborative & Project & Lifecycle Design Future Management Security Management & 3rd-Party IBM Development Jazz Capabilities Capabilities Best Practice Processes Administration: Users, Collaboration projects, process Presentation: Storage Mashups Discovery Query 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 38

IBM Software Group | Rational software 39

IBM Software Group | Rational software Visit us at: @ Rational Brasil @ Rational Users Group @ IBM Rational Software @ IBM Brasil – Rational @ IBM Brasil – Plataforma Jazz @ O Mundo depende de Software 40

IBM Software Group | Rational software 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 41

IBM Software Group | Rational software www.ibm/software/rational © Copyright IBM Corporation 2010. All rights reserved. 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. 42

Scaling agile scrum practices 2.0

More Related Content

What's hot

Viewers also liked

Similar to Scaling agile scrum practices 2.0

More from Reedy Feggins Jr

Recently uploaded

Scaling agile scrum practices 2.0