Rolling Out Agile In A Large Enterprise

3y ago
53 Views
2 Downloads
305.18 KB
10 Pages
Last View : Today
Last Download : 4m ago
Upload by : Luis Wallis
Transcription

Rolling out Agile in a Large EnterpriseGabrielle tYahoo! is a large enterprise with a 32 billion market capand has one of the largest Agile implementations in theworld. The adoption of Scrum and Agile practices hasbeen steadily growing over the past two years, and nowencompasses more than 150 Yahoo! teams in the UnitedStates, Europe, and Asia-Pacific. The projects range fromnew product development for properties such as Yahoo!Autos to heavy-duty infrastructure work on Yahoo! Mail,which serves 250 million users each month around theglobe.1. IntroductionIn the highly competitive Internet space, gettingproducts to market quickly while being both flexible andadaptive to change is critical. Yahoo! needed a softwaredevelopment process that could support an Internetstartup culture within the structure of a company thatprovides products and services to more than 500 millionusers worldwide. I joined Yahoo! in 2005 to help Yahoo!adopt and utilize the highly effective frameworks ofScrum and Agile throughout the organization. We startedwith Scrum, using its lightweight framework to createhighly collaborative self-organizing teams that couldeffectively deliver products to market. Next we started toadd in Agile engineering practices and Lean fundamentalsto deliver greater business value and reduceorganizational waste. In the two plus years since thiseffort began, there have been tremendous successes andvaluable lessons learned. This is a retrospective look atmy experiences in implementing Agile at a largecompany.2. BackgroundYahoo! went from being a small startup to a largeenterprise company quickly. As such, the culture atYahoo! is very much like a large startup. There is aconstant stream of innovative ideas and product launchesas the company strives to be the first to market with newservices, while continuing to meet the everyday needs ofits users. The company wanted to preserve the feeling ofbeing a startup, but also recognized the need to adoptstandard process and practices to help teams deliver betterproducts faster.Yahoo!’s first effort to meld its culture with amanaged software development process began in 2002with the release of a globally mandated waterfall processcalled the “Product Development Process” (PDP).Unfortunately, many teams simply ignored the process or,where they couldn’t ignore it, paid lip service and made itlook like they had adhered to the steps retroactively. Theteams that did follow the PDP found that it was heavy,slowed them down, and added little real value.Some grass-roots efforts to experiment with Agilepractices began to emerge within the company and inNovember of 2004, Tobias Mayer, an engineer on anAgile team invited Jeff Sutherland, one of the inventors ofScrum, to speak at Yahoo!. Pete Deemer, the VP ofProduct Development attended Jeff’s talk and was veryenthusiastic about what he heard. He asked Jeff to returnand speak to the senior executive team at an offsite. Thistalk was very well received, and sparked a lively internaldiscussion about how Yahoo! should embrace Agiledevelopment methods. The debate was whether to initiatea large-scale, top-down “forced adoption”, or to try tocultivate adoption from the ground-up in a grassrootsfashion. The decision was made to proceed with the latterapproach, and Pete Deemer was given a budget andmandate to lead this effort.3. KickoffAt the time, the most visible symptoms ofdysfunction in Yahoo! product development were at theproject and team layer (centered around issues ofplanning, project management, release management, andteam interactions), rather than at the technical practices ortools layer. As a result, Yahoo!’s initial focus was on theadoption of Scrum. There was active debate aboutwhether Agile engineering practices should also beadopting in parallel; in hindsight, it would have

accelerated the benefits had they been. But the constraintsof time and budget, as well as a nervousness about “tryingto make the elephant dance too fast, too soon” led to thepostponement of those efforts initially.Yahoo! launched its Scrum pilot program inFebruary, 2005. Four teams volunteered to try Scrum andshare their experiences with the rest of the company. Theteams covered a broad set of products and servicesincluding the Yahoo! Photos 3.0, a new backend forYahoo! Mail, internal tools for managing small businesssites, and a media site redesign.The initial commitment made by the teams was (i) tocomplete comprehensive Scrum training (which translatedinto Certified ScrumMaster training for most members ofthe team); (ii) to work with outside Scrum coaches duringthe first several Sprints; (iii) to use all the standard Scrumpractices described in Ken Schwaber’s “Agile ProjectManagement with Scrum”; and (iv) to complete at leastone Sprint (the term of art for a 30-day iteration inScrum). It was made clear to the teams that after the firstSprint they could at any time choose to abandon Scrum ifthey found it unsatisfactory.At the end of the two months, the feedback was forthe most part very positive; the teams liked the processand experience, and management saw positive results.What’s more, the positive word-of-mouth was spreadingwithin the company, and other teams were beginning toexpress interest.3.1. Roles and ResponsibilitiesThe pilot teams received some early coaching andtraining from leading Agile thinkers, Ken Schwaber, PaulHodgetts, Mike Cohn, and Esther Derby. I was initiallybrought in as a consultant as well. As the programexpanded, I accepted a permanent position to build aninternal coaching team, working with Pete Deemer toevangelize the benefits of Scrum throughout the company,and to train, coach and support the teams that wished touse it. With just two dedicated coaches in-house andburgeoning demand, we continued to work with externalconsultants to ensure that teams had as much support aspossible in the often difficult early stages of their use ofScrum.The coaching at this early stage consisted offacilitating key events in the Scrum methodology, such asiteration planning and retrospectives, attending dailystand-up meetings and working with key team members tohelp answer questions and provide guidance on anas-needed basis. Also, because the early Scrum teamsuncovered broader systemic impediments, we tried toknock them down as we went so that the issues we solvedfor one team would be solved for many. These solutionsincluded working with facilities to secure meeting roomsand take down cube walls, removing governance gateswhere processes were overly bureaucratic, and changingthe way we conducted resource planning and portfoliomanagement. We did not want individual Scrum teamsburdened with breaking down resistance from uppermanagement on extraneous issues and were keen toreduce the paperwork and process gates that these earlyteams would face.3.2. Tracking ProgressThroughout the transition, we were very active inreaching out across the organization to solicit feedback.We tried to be as honest and transparent as possible,capturing and presenting the challenges along withsuccesses.Many teams didn’t want to try something new unlessit was tested and proven a success with Yahoo! teamsalready. To help combat this problem, at the end of theirfirst month of using Scrum we had all team members andtheir managers participate in an online survey toanonymously provide their feedback. As an incentive, theresponders received a custom-printed Scrum t-shirt forparticipating.The overall response rate to the survey was 71percent (85 percent for Scrum pilot team members). Therespondents rated their experiences against the previousprocesses they had used. The data revealed importantinsight into both how Scrum had benefited the Yahoo!teams that had participated so far and also their greatestpain points. The survey demonstrated the power of Scrumand provided a strong incentive for other teams toovercome their doubts and get on board.Figure 1. 74 percent of respondents said Scrum improvedthirty-day productivity

Figure 2. 80 percent of respondents said Scrum helpedclarify team goals.Figure 5. 89 percent of respondents said Scrum helpedcollaboration and cooperation with the team.Figure 3. 64 percent of respondents felt Scrum improvedthe business value of their product at the thirty-day mark.Figure 6. 68 percent of those surveyed said Scrum helpedreduce the amount of time wasted.Figure 4. 54 percent of respondents said Scrum improvedoverall quality.Figure 7. 77 percent of those surveyed had positivefeelings concerning Scrum.

we found that the worst time to be trying to explain Scrumto a senior manager was in the midst of a difficultsituation where Scrum was the apparent source of theproblem; since Scrum tends to make all dysfunctionvisible, it is often unfairly blamed for the bad news itbrings up. Similarly, we tried hard not to “oversell”Scrum to management, because we were concerned thatScrum might be misinterpreted as a silver bullet. Wewanted to ensure that people understood the hard workrequired by such a major change.3.4. Coaching ModelFigure 8. 81 percent of respondents wanted to continueusing Scrum.We continued to track the overall happiness of teamswho were using Scrum as a baseline metric to show howwe were trending as we scaled. The number has remainedfairly consistent over the last few years.Figure 9. Over the past three years, the number ofrespondents who want to continue using Scrum hasremained consistent.3.3. Management SupportWe noticed across the board that management felt morecomfortable with our progress when they heard realfeedback from their peers. We tended to focus on thebenefits rather than on the mechanics of Scrum, as generalmanagers are typically not interested in the specifics ofthe process as long as it generates positive results. This inhindsight may have led to some problems; those seniormanagers that had a clear understanding of the principlesand practices of Scrum tended to be much better atsupporting their teams use of Scrum, not surprisingly; andOnce we laid the groundwork for the pilot program,we experimented with an engagement model that allowedus to coach multiple teams effectively. We wanted towork closely with teams until kickoff and then slowlywean them off our services.While designing the model we tried to be sensitive tothe fact that no two teams would face the same challengesin implementing Scrum, nor would they have the samesolutions. Some teams might need revolution and rapidchange to get rid of major dysfunction, while other teamsmight need gentle persuasion and understanding. Weneeded to allow time for coaches to learn the individualneeds of a team and be able to help them tailor the Scrumframework specifically for them. We also made theconscious decision not to try to prescribe Scrumthroughout the organization all at once, or to allow teamsto be forced into Scrum by others; the only teams thatwould use Scrum were the teams that wished to useScrum.Our initial rollout strategy consisted of the followingengagement model:Initial discussion Meet with people interested in Scrum anddiscuss their context and challenges. Schedule an overview for key members of theteam. Organize training and coaching, includingScrum Master training and team training.Preparation Work with the Product Owner to prepare theProduct Backlog (Scrum’s prioritization of workitems).Training Conduct two-day Scrum training for the wholeteam.CoachingFor the first sprint, the Agile coach would facilitate thefollowing events: First sprint planning meeting First sprint review (including setup)

First sprint retrospectiveDuring the second sprint, the Agile coach wouldmentor the ScrumMaster as he or she facilitated themeetings. The coach would be available to observe, givefeedback, and answer questions. Where possible, thecoach would encourage ScrumMasters on different teamsto facilitate the retrospective for each other. This wouldallow them to observe other teams and share knowledge.We found that teams forgot things over extendedperiods of time so we stayed in contact and continually reengaged to lead some master retrospectives and give theteams objective advice and coaching. Teams need topursue improvement relentlessly.Teams seemed to follow a standard adoption curvepattern. The first three months were turbulent andchallenging. Scrum seemed to work well as a way to getthe team self-organizing. During the second three months,many teams were ready for more advanced information. Ifyou have the resources, this is a great time to focus ontechnical practices and advanced product planning.4. Scaling Beyond Our MeansBy the end of 2005 we had twenty-five teams usingScrum and ongoing feedback checks showing that aconsistent 84 percent of team members supported the newScrum framework as compared to what their teams hadbeen using previously. We had high hopes of increasingthe coaching team size by the end of the year so we couldcontinue the momentum. Unfortunately, changes in thebudgetary cycles delayed hiring by a few months. Theentire organization was affected by the cycle change. Thedevelopment team was now on the line for meeting theirplanned roadmaps with reduced resources. The obvioussolution (to them at least) was to use the magic bullet ofScrum to make everything go faster. Most people didn’treally know what Scrum was, but they heard it was good.They were scaling up before we were ready to scale withthem. In the first week of January 2006 our pipelineincreased dramatically (figure 10). They all wantedtraining and coaching. The coaching team now consistedof only two people, Senior Agile Coach JF Unson and me.Our executive champion, Pete Deemer, had left for Indiato be the Chief Product Officer of our Bangalore office.and tried Scrum anyway, getting their help from attendinga training class or reading a book. This had long termnegative implications that we are still grappling with.Figure 10. In one year, the number of Scrum teams rosefrom four to forty.We were spread so thin that we lost track of the teamtrainings in progress and were unable to keep up withdemand. The whole program was in danger of imploding.We said “no” to teams who were requesting help thinkingthat might stem the tide. Many of those teams went aheadWe frequently ran into one reason that many Scrumimplementations fail; Scrum looks simple but it causeschange, and change is hard. Scrum works by makingdysfunction visible, so that the team can take steps toimprove; and this improvement often involvesfundamental change by individuals, teams, and the entireorganization. Unfortunately, both of these take a toll ofthe people involved, with extra work, conflict, fear, stress,pain, risk of failure, and other things that peopleordinarily try at all costs to avoid. Teams withoutadequate training and coaching will fail to see the“difficulty” they experience as what it usually is -- Scrumchallenging them to improve and they either abandon thepractices that challenge them most, or fall back intofamiliar habits when times get tough. We have discoveredteams who believe they are Agile, yet are really doingmini-waterfalls. We have heard managers using Scrumterminology while they are assigning tasks and signingteams up to unreasonable demands (such as makingpeople work nights and weekends).While these teams are exceptions, they are contrary toAgile values, and they give the practices a bad name. It isgenerally more work to correct these misguidedimplementations of pseudo-Scrum than it is to do it rightfrom the beginning.5. Scaling the BudgetAs the organization’s embrace of Scrum progressed,we saw again and again how training could make the

difference between success and failure for a team.Unfortunately, our funding and headcount just weren’tsufficient to support the accelerating adoption. We hadfunding from various parts of the organization, includingthe internal professional development organization, butthe demand for training and coaching was simplyoutstripping supply. We needed to show that wellcoached Scrum teams were worth the cost of coaching.For that, we would need metrics.We began by completing internal case studies andsurveys to show the difference between teams that werecoached versus teams that were not. We found differencesin performance and satisfaction between the two groups.The teams with solid foundational training and coachingthrived, while teams with little or no coaching still hadmany challenges to overcome. We saw the differences inproductivity gains, in survey comments, and in individualteam’s management satisfaction levels.The executive team was interested in these results,but needed more concrete data regarding how Agilewould affect the bottom line in order to justify funding.Based on this management requirement, the coachingteam spent a lot of time debating ways to measure successand productivity. We had no established baseline anddidn’t want the metrics to be used to skew behavior in away that could potentially be dangerous. For example, ifwe measured features built as a success metric, we mightencourage people to deliver more features, rather than lessof the right features. This would increase complexity andthe possibility of more defects and ongoing maintenancecosts.“On-time and on-budget” measures might also bemeaningless. How useful was it to ship on time and onbudget if we built the wrong thing and released it at thewrong time? If we rushed to hit a promised date we wouldlikely miss key opportunities to learn and take advantageof changing market conditions.The more we debated, the more complicated thesolutions became. We weren’t getting anywhere. To moveforward, I simply went and asked all the Product Ownerson Agile teams to estimate their teams’ productivity usingScrum as compared to their previous process. I surveyedthirty-three Product Owners, defining productivity as“how much work the team completed per unit of effortexpended.” The degree of improvement ranged from0-200 percent. I captured their comments along with thenumbers so we could learn what affected their responses.I was very upfront about the fact that this data wasvery subjective. I told the management team that if theyhad a better suggestion we would be happy to try it. Thegood news for the program was that the two teams whofelt there was no improvement with Scrum felt that theircontinued lack of productivity was related to eventsoutside of their control, not the process itself. On the otherhand, the teams with high productivity increases directlycited Scrum as the reason for their improvement. Forexample, the Yahoo! mail team uncovered majorarchitectural issues early enough for the team to fix thembefore launch and were able to quickly respond to acompetitive threat during development. They released amajor storage improvement ahead of schedule, saving thecompany millions of dollars.Overall, the average productivity increase was a 34percent improvement. An experienced Agile coach mightlook at this number as see massive opportunity foradditional improvement; however, for a management teamthat was coping with budgetary belt-tightening, animprovement of a one third was dramatic; “Wow ” oneexecutive said, “Imagine if we could increase theproductivity of the entire company by 30 percent!” Smallimprovements can make a big impact when done at such alarge scale. We now build the productivity question intothe online survey and run it with all team members andtheir managers. The number has tracked fairlyconsistently over time. Our most recent survey in July2007 showed a 39 percent improvement.The productivity number helped make a case formore coaching resources. I’ve always been disinterestedin numbers until they are related to buying power, then Iam very interested in them. Here’s what we found: One Agile coach can coach about ten teams peryear.Each team averages ten people, a ratio ofapproximately 1:100.Based on our survey, productivity should increaseby an average of 30

Rolling out Agile in a Large Enterprise Gabrielle Benefield Yahoo! gabriellebenefield@yahoo.com Abstract Yahoo! is a large enterprise with a 32 billion market cap and has one of the largest Agile implementations in the world. The adoption of Scrum and Agile practices h

Related Documents:

1. The need for an agile way of working 6 2. The need for an agile way of working 9 3. Agile Core Values - Agile Project Management Vs. 10 Agile Event Management 4. Agile principles 12 _Agile Principles of Agile Project Management 13 _Agile Principles of VOK DAMS Agile Event Management 14 5. Agile Methods 16 _Scrum in Short 16 _Kanban in Short 18

1.1 Purpose of the Agile Extension to the BABOK Guide1 1.2 What is Agile Business Analysis?2 1.3 Structure6 Chapter 2:The Agile Mindset 2.1 What is an Agile Mindset?7 2.2 The Agile Mindset, Methodologies, and Frameworks8 2.3 Applying the Agile Mindset9 2.4 Agile Extension and the Agile Ma

Agile Estimating and Planning by Mike Cohn Agile Game Development with Scrum by Clinton Keith Agile Product Ownership by Roman Pichler Agile Project Management with Scrum by Ken Schwaber Agile Retrospectives by Esther Derby and Diana Larsen Agile Testing: A Practical Guide for Testers and Agile Teams by Lisa Crispin and .

Agile World View "Agility" has manydimensions other than IT It ranges from leadership to technological agility Today's focus is on organizational & enterprise agility Agile Leaders Agile Organization Change Agile Acquisition & Contracting Agile Strategic Planning Agile Capability Analysis Agile Program Management Agile Tech.

The most popular agile methodologies include: extreme programming (XP), Scrum, Crystal, Dynamic Sys-tems Development (DSDM), Lean Development, and Feature Driven Development (FDD). All Agile methods share a common vision and core values of the Agile Manifesto. Agile Methods: Some well-known agile software development methods include: Agile .

1. Agile methods are undisciplined and not measurable. 2. Agile methods have no project management. 3. Agile methods apply only to software development. 4. Agile methods have no documentation. 5. Agile methods have no requirements. 6. Agile methods only work with small colocated teams.-7. Agile methods do not include planning. 8.

The Agile Customer . 9/6/2012 6 Agile Development Team Agile Analyst . 9/6/2012 7 Agile Programmer Agile Tester . 9/6/2012 8 Agile Manager Agile Usability Designer . 9/6/2012 9 Kicking off a project The Inception Deck –Ten questions you’d be crazy not to ask before starting any

The Agile Customer. 9/4/2013 6 Agile Development Team Agile Analyst. 9/4/2013 7 Agile Programmer Agile Tester. 9/4/2013 8 Agile Manager Agile Usability Designer. 9/4/2013 9 Kicking off a project The Inception Deck –Ten questions you’d be crazy not to ask before starting any software