Scaling scrum agile2010
0 likes278 views
The document discusses the experiences of two organizations in successfully scaling Scrum methodologies despite differing structures and challenges. Key strategies included fostering strong team collaboration, training internal coaches, managing dependencies effectively, and maintaining a clear project management structure while embracing agile principles. The insights emphasize the importance of selecting appropriate roles within teams and promoting adaptability among members to ensure successful large-scale implementation of Scrum.
Scaling scrum agile2010
- 1. 1
- 2. 2
- 3. 3
- 4. I assume everyone understands the basics of Scrum, and won’t be going through that. Examine two very different organizations who ultimately ended up using the same techniques to be successful in scaling Scrum. This presentation focuses on the techniques that they used, which may differ from those recommended in some of the more popular books on the subject of scaling. My hope is that you’ll be able to use at least one of these techniques to benefit scaling efforts in your own organizations. Questions throughout please. 4
- 5. I’m defining large as > 40 people (i.e. 4 or more Scrum teams). You want to scale when you are delivering a single product with a large team of people. You do not want to scale Scrum if you have a large team working on a diverse set of project (that’s a whole different issue). 5
- 6. 6
- 7. Each division is like its own smaller company Processes, tools, environment, all differ between divisions Customer base – large telco 7
- 8. 4 major sites, 3 continents, 4 time zones Organized around functions (architecture, software development, hardware development, test, project management) Sub-groups organized by product architecture (software/hardware components) 8
- 9. Releases: Typically large: >18 months duration, >100 developers, > 300K NCSL, 13 year old code base Life cycle: Big, up front requirements gathering/documentation Whole project scheduled early in the product life cycle Throw over the wall to test at the end Requirements churn Frequent Late (in the development life cycle) Missed schedules Late deliveries to test, certification, customers Denial of schedule slips – thought development wouldn’t work hard enough if they recognized the date needed to move Defects Backlog of thousands of bugs Morale “Sweat shop” mentality – working 24 x 7 (Anthony’s story) 9
- 10. Started with one pilot team – developers only Later added testers Slowly added additional teams Brought in people from other parts of the organization who had successfully scaled Scrum Note – this was a work in progress when I left – still expanding the organization. We’ll talk more about how far they got in the second half of the presentation. 10
- 11. 11
- 12. Customer base: consumer, enterprise, wireless carriers 12
- 13. 13
- 14. Releases: Typically small: < 6 months duration, < 30developers Life cycle: Big, up front requirements gathering/documentation Whole project scheduled early in the product life cycle Throw over the wall to test at the end Requirements churn Frequent Late (in the development life cycle) Changing priorities Uncertain schedules 14
- 15. Brought in internal Scrum coaches to transition to Scrum (boot camp) – trained 50 people and had them up running their sprints and Scrum of Scrums in one week. Was a good place for us to experiment with Scaling – open environment, cohesive team, co-located. 15
- 16. 16
- 17. Org Structure: •Functional/architecture based organization •Dealing with being part of the new organization •Difficult to deliver user visible features •Creating cross functional teams tended to be problematic – silos •How to ensure architecture didn’t deteriorate Beyond SW: •How to manage dependencies between Hardware and Software •Can hardware developers use Scrum? •Dealing with dependencies on corporate functions •Working with other teams who aren’t using Scrum Geography: •Obvious issues: •Communication difficulties •Some sites had no common working time •No sense of commitment or team due to having never met teammates in person •Not so obvious issues: •Cultural resistance to Scrum •European site was much more adverse to Scrum than North American or Asian sites Delivery Schedules: •Releases were defined based on content •But, schedule was king •And content kept changing Release Management •A traditional project management structure was in place, and it needed to be maintained •Senior management still needed some level of more traditional oversight •Releases were so big (from a content, personal and schedule perspective) that PMs could not effectively function as SMs, unless they were cloned 17
- 18. 18
- 19. I recently attended Alan Altas’s of Rally webinar titled Scaling Agile in 7 Smooth Steps, and one of the first pieces of advice he gave was to “ruthlessly apply agile principles”. It turns out that everything that you need to do for a single Scrum team becomes that much more important when you scale. Keep agile principles in mind whenever you are faced with a problem. These organizations were successful at scaling because they did this. Also, invest in training and coaching. If you have internal coaches, so much the better, as they will have extra credibility in your organization. 19
- 20. Share between teams, and share with others. These organizations shared a product backlog (perhaps with multiple views into it, as suggested by Mike Cohn), and they had demo days, where they shared their work with everyone. This is a good time to involve those you separated from previously – invite them to your planning sessions and demos. Established a shared, aligned sprint length, definition of done, coding standards, and other processes. In addition to individual Scrum team retrospectives, have a joint retrospective, or share the results of each team’s retrospective. You might also consider sharing team members, particularly where you can’t minimize cross team dependencies. Having the same person on both teams will help provide effective dependency management. 20
- 21. Choose your ScrumMasters and Product Owners wisely. Assuming your project manager will fill the ScrumMaster role is a mistake when you’re planning to scale (and maybe in general). A Product Manager is usually a good choice for a PO, skill set wise, but you have to make sure they’re going to be as available as the team needs them to be. Who did these organizations choose as ScrumMasters? • Software team leads/managers • Architects • Testers • Senior developers Just like in a one team environment, your ScrumMaster has to be an ambassador of Scrum to the team, but they also have to be able to resolve more complex dependencies than they otherwise would. Make sure they have the technical expertise to help. Avoid the ScrumMaster for hire syndrome. You need a good Product Owner. This is true of course for a single Scrum team, but hyper true for teams that are scaling. These organizations had an uber product owner who was responsible for the product backlog as a whole, and individual product owners who could make day-to-day decisions about their subject matter areas. If you don’t have this, you’ll be blocked often. Have times where all the POs get together to understand priorities and do team building. Choose POs who have the following characteristics: •Ability to deal with and involve multiple stakeholders •Good understanding of the market and the organization •Speak the same language as the other POs •Decisive – able to make good quick decisions •Consistent - i.e. not changing mind back and forth •Sophisticated communication and influencing skills •Can represent customers and users of the system/product •Has the respect of developers •http://www.offshoreagile.com/resources/articles/right_person_for_the_job/ 21
- 22. A release train based approach is one where the organization recognizes that they are schedule driven. In this model, the product release dates are fixed, and the content that is ready on the date is released. This requires a commitment from your product owner team to prioritize feature content and manage the product backlog very carefully. These organizations took a release train approach. This gives the teams focus in planning, estimating and prioritizing. I could do an entire talk on release trains – I plan to write a blog post on the subject so please visit my blog or see me after if you’re interested in more information on this 22
- 23. These organizations both reused existing processes and roles where they could. Of particular importance is the project management organization. Both of these orgs reused existing project management structures to fulfill the Scrum of Scrums need. In fact, organization 1 didn’t even use the concept of Scrum of Scrums, they simply re- structured their weekly project status meetings to fit the new model. Project Managers are already familiar with dealing with inter-team dependencies and they have the contacts to help resolve common Scrum team impediments and making sure corporate functions are lined up. They can also fairly easily reuse whatever senior management reporting structures they have in place with some pretty minor adjustments. Make use of what you already have – don’t try to re-invent the wheel. 23
- 24. Don’t try to include everybody. On small teams, or in small companies, it makes sense to include every possible person who will contribute to your project on your Scrum team. In large organizations, don’t even try. Technical writers, support specialists, certification engineers, etc. are usually part of a central service function in large organizations. Those people are working on multiple projects at once and having them be part of your team will usually make them frustrated because they’ll perceive there to be a great deal of overhead. Follow their processes for involving them and let your project management organization manage the dependencies. Separate geographically too. Once again, a practice that matters on single teams, but is intensified on scaled teams. Geographical distribution is bad for teams in general, which is why Scrum says co-located. But most large organizations are geographically dispersed. Does that mean that you have to fold up your Scrum tent and go home? No! Work with geography, not against it. I’m continually surprised by the number of teams that strive for geographical distribution – preferring to take the approach of taking a few team members from each location to create several geographically distributed teams. The only reason Organization #1 was successful was because they formed (cross functional) teams based on geographical lines. Let the project manager (or ScrumMasters) deal with the inter-team dependencies. Organization #2 had less geographical distribution, and certainly not enough to form teams on geographical boundaries. Their distributed team members agreed to work on the home team’s time zone. And separate the work. Plan the work between teams to minimize cross team dependencies as much as possible, and to plan the dependencies you want to have. Tips for choosing how to separate: - corporate organizations that work on many projects, part time people (less than 50% of their time on your project). Those teams should follow their own processes, whether agile or otherwise. Have people on your teams assigned to interface with those people. Include tasks in your sprints for dependency management. Let the PMs help you here too. 24
- 25. Your team needs to be like a Swiss Army Knife – the team, and the individuals need to be able to do many things. You might be able to get away with silos in smaller environments, but it won’t scale. People will necessarily have to re-think their roles sometimes, and break down the barriers between analysts, developers and testers. It also means that you have to let go of your area of expertise. But, you don’t want architecture to deteriorate either. Organization 1 addressed this by forming a hybrid between cross functional feature teams, with a few component based teams (as Mike Cohn suggests in Succeeding With Agile). 25
- 26. 26
- 27. This illustrates how organization 2 set up their team structure. Each team has assigned team members (and roles). The resources at the bottom of the board in the picture on the far left are shared between teams, or unassigned. 27
- 28. 28
- 29. 29
- 30. 30
- 31. 31
- 32. 32
- 33. 33