Harrah's Entertainment, Inc. is the world's leading gaming entertainment company, currently poised for continued expansion and growth. Its Enterprise IT team is also poised for continued success by virtue of an aggressive foray into Agile software development methods. Harrah's IT desires to provide an Agile alternative to traditional waterfall projects where it makes sense based on predetermined criteria.
This article describes the challenges in managing Harrah's first Agile pilot project - code-named "Slot Marketing" for this article.
The team consists of ten people in Las Vegas and six in Memphis, of which four are external consultants. The Agile coach, located in Cambridge, provides remote support and periodically visits the development sites. The authors of this article (referred to as "we" throughout) are the project's development lead, the quality manager for Harrah's, and the Sapient agile coach. The project began in July 2006, and consists of 11 two-week iterations, grouped into four major releases planned for the second half of 2006. The team is using Sapient's distributed agile methodology known as Sapient|Approach.After some expected but unpleasant growing pains, the team successfully completed its first release the first week of October, rolling out new functionality to one-arm bandits in Las Vegas and other markets.Read on to see how we tackled (and are still tackling):
Shifting to true team-based development.
Instilling discipline and rigor needed for short iterations.
Handling "process overload" for team members completely new to Agile.
Challenge #1: Shifting to true team-based development
Slot Marketing project team members are experiencing a paradigm change in team dynamics and interactions. Agile development requires project
Advertisement
contributors to complete tasks and stories as a team, which is very different than the "group" work these people have done in past waterfall development at Harrah's. Doing team work well is not an instinctive skill. In a group, value and importance of the individual is emphasized. By contrast, teams are interdependent and complete tasks collaboratively. How can a development manager persuade groups of programmers, testers, and business analysts to work collaboratively on a common goal when shifting from a waterfall approach to agile?
Beware the mini-waterfall
For the first three iterations (six weeks) of the pilot, the teams worked in what is best described as a mini-waterfall approach to iterative development. Despite training to the contrary, team members instinctively formed groups with others who played similar roles on the project. The developers would divide and conquer the development tasks and the testers would wait until all development was complete before beginning testing. The team felt more comfortable operating in this fashion, but the approach introduced major risks to the project. Waiting until the end of all development to test functionality meant that there was too much work in progress, creating a high likelihood that issues would be uncovered, stories would not be completed, and velocity would suffer. Also, developers typically moved on to the next development story and multi-tasked between fixing defects and developing new code, causing lost effort in excessive context-switching. In one case, the code did not meet the business needs and the story did not pass the iteration checkpoint. The group became frustrated with the missed deadlines, lost synergy, and had to deal with the resulting low velocity.
The solution was right in front of them: emphasize customer collaboration. The fact that the rejected stories needed rework provided an ideal opportunity to contrast and compare the traditional waterfall approach with the "new" way. We arranged for the business analysts, programmer analysts, and quality analysts all to meet directly with the business owner, and empowered this team to gather requirements, create the design, and develop test cases during a one hour meeting.
The team created a new estimate of three days to complete the story, compared with the mini-waterfall estimate of seven days. The approach pulled the team together and team members successfully collaborated, gaining signoff on the functionality at the next iteration checkpoint.
The team reported the following lessons learned with its errant foray into mini-waterfall:
Teams must work collaboratively to complete a story.
No one contributor should outpace the team.
The team should reach the finish line of a story together.
Leveraging the synergies among different roles on the project will decrease estimate-to-complete (ETC) and increase the "correctness" of the functionality (in the eyes of the business sponsor).
They should communicate in real-time as much as possible sharing ideas, plans, and solutions.
Challenge #2: Instilling discipline and rigor needed for short iterations
The word around Harrah's was that Agile allowed for flexibility in execution, therefore there was less discipline required of the people on the project teams. Very quickly, we found the opposite to be true: more rigor and discipline is required of people executing in an Agile methodology than on a typical waterfall project. Because of the short cycles, there was little room for misunderstood tests, incomplete task lists, and inconsistent ETC reporting. Our challenge was how to very quickly instill this greater sense of discipline and rigor in team members who were not accustomed to it.
Sitting and waiting is not an option
Through the pilot project, we've had to teach team members how to explicitly communicate their needs to others and work with them, whether it be face-to-face or via phone, to get the information they need. Team members now understand that communicating what they need to others and waiting on a response, via email or regular project team meetings, is not acceptable. Sitting and waiting is no longer an option - any loss of time can mean the difference between making or missing an iteration.
"Done" in waterfall does not equal "done" in Agile
We have fostered the partnership between developers and testers, and emphasized that a story is never considered complete until both groups have completed their tasks. Team members have had to shift their understanding of what done means. In a waterfall environment, developers truly have a mindset that when a piece of functionality is coded and unit tested, it's complete. There may be defects that are discovered later, but from their perspective it's done. The Agile model of partnership is difficult to foster, but we've found that once team members understand this concept the speed and efficiency with which they deliver functionality is exceptional.
Life happens - manage distractions
We have encouraged team members to be more conscious of all the little things that happen outside of stories. For example, we now address defects discovered in production following a release by developing stories that are solely focused on closing those defects. Team members have also learned to balance their good instincts to pitch in and help out other team members with an understanding that every day counts and that they need to also stay focused on their story. One way we have helped manage this is by having team members work in team rooms. When people are working alone in a cube, there's more likelihood of others stopping by with random requests. A team room (or multiple ones at different locations) raises others' awareness of the team's focus and discourages interruptions. When a team member does receive an outside request, he or she has to be diligent about vocalizing that distraction to the team and explaining and mitigating any iteration impact associated.
Challenge #3: "Process overload" for team members completely new to Agile
Simple and beautiful as it may be, Agile will at first completely overwhelm a waterfall-trained person. In the first week of the Slot Marketing project, a majority of the team members not only had to learn the detailed business context, technology nuances, and team personalities, but also new concepts for decomposing work, writing code, and even communicating status. And for a handful of the team members, this had to be done over the phone. When something goes awry with the project - as it will and has - what gives out? Tracking our ETC? An orderly standup meeting? Code quality? Our challenge was to introduce a lot of new concepts and still deliver a demanding project, while learning what works well and what needs to change with Agile for Harrah's.
Define an approach
We thought we had the answer to this challenge. Before kicking off the pilot, we walked through a comprehensive list of the agile processes we wanted to adopt in the pilot. We modified versions of the Sapient|Approach processes to meet the Harrah's environment - for example, deciding to track story tests within the existing test management tool (Mercury Quality CenterTM ) and to maintain the master list of stories in Sapient ResultSpace®. This "Agile adoption plan" helped to steer the team through the variety of inter-dependent processes and approaches that the team would be using, and also set the stage for tracking.
From iteration to iteration, we assessed how well the project team was adopting the new Agile processes. A simple dashboard helped us to clearly identify and communicate the areas in need of improvement, but unfortunately there were simply too many (see Figure 1). We had expected a learning curve, but we felt unsure where to focus first.
Figure 1. Snippet of Adoption dashboard. Ratings are from scale of 0 (not practiced at all) to 4 (role model for projects). Red boxes indicate low ratings (0 or 1).
We simply had too much "red" to address, and so we revised our approach to be more methodical. We identified a subset of the agile processes as the areas most critical to examine in the pilot. By targeting this subset and focusing education and follow-up efforts explicitly in these areas (while not ignoring the others), we were able to help the team focus on the core areas that we felt we absolutely must address.
Summary
Despite challenges, our pilot is very successful thus far: an Agile plan is enabling us to release major functionality to the Las Vegas market three months earlier than originally planned (under waterfall), while remaining flexible to changes which will occur through the rest of this year. We are carrying all our lessons learned into a second pilot and in the spirit of continual improvement we expect to find more challenges but to collectively solve those too.
What can you do for your Agile pilot team?
Have collaborative teams work together with the business owner - not just the Analyst or Programmer.
Make sure individual contributors don't outpace others on the team.
Communicate immediately when possible and make real-time decisions.
Focus efforts on defining tests for stories to clarify what "done" means.
Don't leave a tasking meeting unless all stories have clearly defined tests.
Don't allow developers to finish coding and save testing until the end.
Empower teams to determine communication plans which work for them.
Minimize work not directly related to delivering customer stories.
Define what you're going to try to pilot.
Track what you've been able to pilot.
Identify process focus areas to rally the team around each iteration.
About the Author
Andy Takats is a Director at Sapient, a global services firm that helps clients innovate their businesses in the areas of marketing, business operations, and technology. After many years helping clients deliver leading-edge software systems (including work for the Philadelphia Stock Exchange, European Space Agency, and then for United Airlines, Williams Energy, Merrill Lynch, and others while at Sapient), Andy turned inward at Sapient to lead an overhaul of the company's delivery approach. Currently he is back in the fire coaching Sapient teams and helping Sapient clients adopt Agile methods.
Articles 
