14. 2010 100+ agile teams R&D, IT, & Technical Operations
15. What is ADM? ADM (Adaptive Delivery Methodology) Salesforce.com flavor of agile Scrum project management framework XP practices Based on Lean principles
32. ADM Release Cycle Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Coordinate release planning with generic framework Planning cycle for next release Planning cycle for next release Planning cycle for next release Release Release Release Release
50. 26 to 33 to 27 Teams Team 13 Team 11 Team 9 Team 10 Team 14 Team 8 Team 7 Team 12 Team 19 Team 18 Team 16 Team 15 Team 17 Team 25 Team 21 Team 20 Team 27 Team 22 Team 23 Team 24 Team 26 Team 2 Team 3 Team 4 Team 5 Team 1 Team 6
52. Align to Workgroups Team 13 Team 11 Team 9 Team 10 Team 14 Team 8 Team 7 Team 12 Team 19 Team 18 Team 16 Team 15 Team 17 Workgroup 4 Workgroup 2 Team 25 Team 21 Team 20 Team 27 Team 22 Team 23 Team 24 Team 26 Team 2 Team 3 Team 4 Team 5 Team 1 Team 6 Workgroup 1 Workgroup 3
58. Program Dependencies Delivering Team & Feature Consuming Team & Feature May June July Team 8 Team 7 Team 22 High Med Low Risk Done – Delivered Low – On track Medium – Possible concerns/may miss deadline High – Not scheduled, cannot deliver, or deadline missed Team 12 Team 18 Team 10 Team 11 Monitor complexity & maintain visibility Something more Something I want Done Feature at risk Feature Something I need Cool Feature Something else I need Another Cool Feature
How we’ve applied agile organizationally at scale Challenges of scale Agile can be done at scale
At salesforce we have scaled both deep and wide. When we refer to deep, we mean that we have embedded agility very deep into the enterprise and have tackled and continue to face some of the more difficult enterprise scaling issues. Most of out talk today will be focused on specific areas where we go deep. However, before we get to that, we wanted to touch on organizational breadth of our agility. At salesforce our Technology and Products organization is 100%. That means that over 1000 people and more than 100 teams actively use ADM. There is no other methodology in use to deliver work. In fact, ADM has gained such a strong reputation inside salesforce that we are now starting to see other parts of the organization apply ADM—with Marketing being the most recent case.
Steve just walked you through our transformation in R&D to ADM and I’ll talk you through our Internal IT story. After two years of successful use of ADM in R&D, our leadership started to ask why we were not using it in IT. The fact is, IT pre-ADM suffered from many of the same issues that ADM had specifically addressed for us in ADM --too much work, too many priorities --Lack of visibility on progress --Difficulty resourcing projects and skill set gaps --Lack delivery predictability --Late feedback from internal customers I use this image because for many business customers, IT is a bit of a black hole. Requests come in and after some period of time, work comes out the other end (often after many months where the progress can only be seen through status reports).
So, we rolled it out to IT—an org of over 125 people who do three main type of work: application development (like R&D), vendor integrations using third party software and infrastructure projects like office build outs. We modeled the rollout on R&D and here are the basic steps: --firstly, gain executive buy-in and support. This might take a long time and requires work but is critically important. --step two: figure out your teams. When you are going from waterfall to agile, it’s common to find that your organization isn’t staffed correctly. For example, in IT we had lots of project managers but not enough delivery folks (developers, QA). 3 months Determine teams Get executive buy-in Train, train, train Launch teams Coach, adapt, correct Let go
Teams did not work well together: Break down silos Use same language ADM Everywhere Too many priorities Lack of bottom up feedback and visibility
Working with TechOps has caused us to stretch our understanding and application of ADM. TechOps is infrastructure and operations (software and infrastructure) Not only is the work in TechOps different than other parts of the org but also the culture is different.
Scaling across the org was hard and it is a constant work in progress. --each org has different needs, approaches and variations which require support But even within these challenges, going deep is harder than wide. We strive to stay lightweight, respect the autonomy and authority of teams, while increasing collaboration and
People
People
At salesforce Trust is our number one value. We only have a single version of our service and we cannot risk our customers’ success with low quality software. We have ensure that debt – both is quantity of bugs and test failures as well as quality and maintainability of our codebase – is avoided at all costs, by an ever increasing number of teams
Tools: GUS built internal tools for automation and scrum with robust reporting. These reports are reviewed daily—by all teams. -our standard is 99% plus and it graduates throughout And its crucial to our success. Potentially releaseable, continuously releaseable
People: maintain the autonomy and integrity of the team. We resist resourcing changes to stabilize and ultimately optimize teams. Make it easy to understand priorities globally and build relationships with dependent teams.
Raw talent is not enough. Hiring process has a heavy focus on cultural alignment. This is only successful if everyone – executives, managers and team members have the same value system. We look for people who are learners, empirical, how do they adjust to change Don’t want debt