Case Study 1: Agile in Practice – An Agile Success Story

timer Asked: Oct 19th, 2018
account_balance_wallet $20

Question Description

Write a four to five (4-5) page paper in which you:

  1. Determine the key reasons why Deloitte Consulting (DC) chose a modified SCRUM method instead of a traditional waterfall method.
  2. Explain how DC performed project planning and analyze its effectiveness for later execution and product release.
  3. Identify the challenges that DC encountered in each project phase and explain how they overcame those challenges. Give an opinion on whether the Agile concepts played an important role in this process.
  4. Determine the techniques that DC used to monitor the project progress and evaluate how it enabled the project success.
  5. Explain why DC did not use offshore resources and evaluate whether the Agile method will work in a project with diverse workforce geographically and culturally. .
  6. Speculate on the leadership roles needed if you were part of the DC team.
  7. Use at least three (3) quality resources in this assignment. Note: Wikipedia and similar Websites do not qualify as quality resources.

Your assignment must follow these formatting requirements:

  • Be typed, double spaced, using Times New Roman font (size 12), with one-inch margins on all sides; citations and references must follow APA or school-specific format. Check with your professor for any additional instructions.
  • Include a cover page containing the title of the assignment, the student’s name, the professor’s name, the course title, and the date. The cover page and the reference page are not included in the required assignment page length.

The specific course learning outcomes associated with this assignment are:

  • Compare and contrast Agile methods with traditional project management techniques.
  • Explain the challenges and opportunities of an Agile project leader.
  • Summarize the iterative qualities for Agile project success.
  • Describe Agile project management methods and phases.
  • Use technology and information resources to research issues in Agile project management.
  • Write clearly and concisely about Agile project management topics using proper writing mechanics and technical style conventions.

Unformatted Attachment Preview

Agile in Practice An Agile Success Story February 2012 Contents Overview   1   Why  Agile   2   How  We  Did  Agile   4   4   5   6   7   7   8   SCRUM-­‐derived  Model   Distributed  Teams   Planning   Execution   Documentation   Reporting   Lessons  Learned   What  Worked   What  We  Could  Have  Done  Better   Agile in Practice - An Agile Success Story 11   11   11   Overview Our client serves about 10,000 clients worldwide. Their aging platform was proving to be inefficient, difficult and expensive to adapt to the changing needs of their clients. In August 2010 our client asked Deloitte Consulting (DC) to help drive an effort to create a new global platform to offer portal, collaboration and document management capabilities. Many of the requirements for this new solution were above and beyond what the selected platform, Microsoft SharePoint 2010 (SP), had to offer. To make matters more complex, the expected number of combinations of clients, locations, application modules and individual functionalities quickly grew into the thousands. Moreover, our client had little experience embarking into an enterprise like this one. 16 months and 11 releases later our top-talented DC team completed a solution that exceeded our client's expectations. Each release delivered working software, showing the team's progress and giving our client the opportunity to adjust requirements and design as needed. Each release was delivered on time and under budget, every time! This document explains why we chose an agile life cycle model for this project, how we implemented it and what lessons we learned, so other DC teams can benefit from our experiences1. 1 For more information on Agile methodologies, please see the “Agile Development POV” available on KX 1 Agile in Practice - An Agile Success Story Why Agile Like many other large-scale projects, the first couple of months were mostly dedicated to establish the overall vision, business case and define high-level business requirements for the solution. We started off with a traditional waterfall Software Development Life Cycle (SDLC) approach; given the strong emphasis of our established methods (Playbook) and for the need for a tight control over scope and budget, it seemed an adequate decision at the time. The original concepts for the solution were vaguely defined so we needed a way to make them concrete through continuous refinement iterations with our client. By the end of January 2011, requirements and design work started to pile up and our initial attempts to prototype some of these concepts were not working well. The interactions between the client and DC teams took too long to get from concept to requirements to prototype and back again. It was clear we had to make important adjustments to our process to make this work. The transition to Agile was made possible in great part thanks to the deep involvement of the business side and their flexibility to adopt a new, more efficient lifecycle for this project The project was tightly constrained on resources, tools and budget; surprisingly timeline was not very solid. There was a vague expectation on when to deliver a first working release and since scope kept changing every month, it became more of a balancing act between the DC Project Management (PM) and the project owner from the client side to prioritize scope based on real business drivers. Interestingly, the project owner was very involved in every aspect and decision of the project. He was very receptive to new ideas on how to improve the process so teams could be more effective and efficient with the resources we had available. He also understood how to partition the scope and budget into multiple releases and negotiate that with the project steering committee. Figure 1 – Paradigm Shift Opposite approaches driven by different needs 2 These factors were key for the adoption of an agile SDLC. However, given project constraints, we had to do this in a very "creative" way, to minimize disruption and the learning curve required. At the time, nobody in our teams had been certified on any agile methodologies, only a few of us had some experience with them, and the supporting DC tools available for agile delivery were not very helpful either. The transition to agile didn't happen overnight. It took 3 months, from February to April, to evolve our processes to have repeatable release cycles. During this time our team was busy creating all the frameworks and tooling required to get us to a consistent release cycle. SP based solutions tend to be easy to "prototype on the go", but we had to actually build each iteration with our custom process rather than the standard SP tools, otherwise we'd face an unmanageable number of artifacts to redo later on, "pay me now or pay me later" sort of scenario. From May to December our team got into the rhythm of delivering working releases about every 4 weeks. Each release was fully working software with the features planned for that release. Our client was able to provide very specific feedback on what was built instead of looking at prototypes. It was clear our decision to move to an Agile SDLC had paid off. 3 Agile in Practice - An Agile Success Story We adopted agile incrementally to minimize project disruption, we evolve our process while keeping the project going How We Did Agile We implemented agile incrementally. Our toolbox and the experience of teams were limited; we could not afford a "big-bang" approach and we had to use what we had available and make it work. The first decision was selecting what agile method to use. We chose to use a modified version of SCRUM. We also had to deal with having team members geographically distributed. Then we had to define how to plan, execute and report each sprint. SCRUM-derived Model We used a derived version of SCRUM to fit our project needs and timeline. Terminology changed a bit but the concepts were very close. For instance, instead of Releases we used Versions and instead of Sprints we used Releases, terms our client was more comfortable with. Figure 2 – Standard SCRUM vs. Our Project Terminology Different names, same concepts There were other subtle differences throughout the SCRUM lifecycle. Instead of user stories we had a combination of UI wireframes and requirements and our Product Backlog was composed of features, not user stories. Figure 3 – SCRUM Lifecycle for the Project From requirements to working software in every release 4 Distributed Teams At the beginning of the project we tried to use offshore resources to keep costs down. However, given the highly iterative nature of the project and the everevolving requirements, it became very clear this model wouldn't work, so we switch to an onshore model. Back in February we needed to augment our functional team again, but we couldn't find any BTA-level resources available in the USA, so we had to explore other alternatives. After some searching we found 2 very talented resources in our Mexico City practice. Later we added 2 other great resources from our US Federal Consulting practice to our .Net development team. As the team grew it became very inefficient to co-locate every week. Travel became hectic as we were flying team members from all over the place to work with our client. Travel was impacting our productivity so we decided to start colocating less frequently. We saw how our productivity improved without impacting our client. This also boosted the morale of our team as we got great work-lifebalance. Co-locations became more an opportunity to interact with our client, demo each release and plan the next one. Sometimes we co-located just selected members of our team, to work on focused aspects of the solution. We were able to leverage the Internet to stay productive while keeping our project expenses very low. We used Communicator (now Lync) extensively to have our stand up calls, review design and code artifacts, debug code, discuss project issues and have our weekly status calls with the client. We used Virtual Machines (VM) provided by the client, one for each member of our team (plus additional ones for other staging environments). The main benefits of this approach were: • VM images were quickly created for us (usually less than 5’) • We were able to access these VMs from any point • The client provided us with excellent support to snapshot and backup any VM • VMs were easily disposable when no longer needed • We had individual VMs to support different server roles, such as source control (Team Foundation Server - TFS), PM team site, staging environments, etc. 5 Agile in Practice - An Agile Success Story The team was able to reduce travel without impacting visibility with the client, resulting in increased productivity and boosted team moral Planning We built our Release Roadmap incrementally, listing the features to be included in the current release and estimating the next features throughout subsequent releases. We adjusted this roadmap with every release. As the list of features stabilized it was easier to pin down production timeline. Figure 4 – Release Roadmap Major features outlined by release Our sprint planning selected features from our product backlog, starting with those with the highest priority, and split them into actual tasks Planning each release was done during the week we co-located. This way we had the entire team available to assess which features to do next, and to base line our current workload and project priorities. We used Excel to balance and prioritize remaining features in our product backlog. We validated the list of features to include in each release with our client before proceeding. Then we detailed each feature as work items in our SP team site so each member of our team had specifics tasks to work on for the release in turn. Features that could not be commited were returned back to the Product Backlog to be done in a later release. Figure 5 – Release (sprint) Planning Selecting features for a given Release (sprint) and breaking them into tasks 6 Execution Each release was about 4 weeks long in average. The first 3 weeks were dedicated to work on the features planned for that release. Development, testing and bug fixes were almost continuous (although we didn’t implement Continuous Integration). Once we stabilized the release, we proceeded to prepare for deployment. The final week was dedicated to present the release to our client, gather feedback, restrospect on what worked and what could be improved, and to plan the next release. Figure 6 – Executing a Release (sprint) Staggered phases within each release We co-located the team on the final week. We had every member of our team present the features they worked on for that release to our client. This way each member of our team got credit for their work, visibility and interaction with client top executives. Then we repeated the cycle all over again. Some features were too complex (or we had little idea of how to do them), so we broke them down into one or more Proof of Concepts (PoC) to have a chance to test different alternatives. Each PoC was limited to 2 weeks. We used a standard format to structure and present each PoC (problem statement, alternative solutions, recommendations) so everything got properly documented and our client had an opportunity to decide which option would fit the solution and timeline best. Once a recommendation was accepted, we committed it as a feature in the next release. Documentation All our projects commit to some level of documentation as part of our deliverables to the client. Keeping documentation up to date is typically a challenge. Our project was not an exception. Given the fast pace of each release and the constraints on our team, we had to make some documents smarter rather than static, especially design documents (functional and technical)2. 2 7 All infrastructure work and specifications were done by the client Agile in Practice - An Agile Success Story Smartdocs helped keeping our functional and technical specifications up-to-date while minimizing the need for rework We used the following practices to keep these documents as dynamic as possible and to reduce the level of maintenance on them as changes occured: • Some documents, such as SP list definitions, where both documents and tools, so we could generate XML content with them and document the actual list schema, using the same artifact • Functional specifications where very user-oriented and didn’t include any reference to requirements, rather features, which usually grouped more detailed requirements • Each technical specification was more a set of documents. We used smartdocs out of code (enforced by code authoring tools), class diagrams were reversed engineered from code and kept in Visual Studio (VS), data models were produced with and kept in VS, and the rest of the technical specification (less volatile content) was done in a Word document Reporting We combined the tools at our disposal (Excel, SP team site and TFS) to document all project artifacts and to generate our progress reports on demand. This was the first project where most of us didn't need to spend any cycles creating weekly status reports. All pertinent project information was available at all times. Our SP team site was our PM tool where we managed the following lists using Out of the Box (OOB) SP functionality (we kept our documents and solution artifacts in TFS): • Project issues • Risks • Key Decisions • Work items (tasks) • Change requests • Assumptions • Team calendar • Contacts list 8 Figure 7 – PM Dashboard Project information was readily available in our project SP team site We generated our progress reports using Excel Services based charts, so we could feed the charts with data from our different lists in the team site (issues, risks, work items, time and expenses budget/projections/actuals, etc.). We created SP pages to host these Excel charts to have an up-to-date project dashboard for the team or our client to access at any time. Figure 8 – Progress Chart Completed, In-Progress and Not-Started work items chart 9 Agile in Practice - An Agile Success Story Our team members updated the progress and status of the work items assigned to them every Thursday so on Fridays our PM team had to only refresh the Excel charts and prepare the agenda to discuss on the status calls with our client on Mondays. Our work items list became our project plan. Figure 9 – Work Items by Release Tracking our progress for each release We also prepared a "release deck" for the week when we presented to the client at the end of each release. This deck had detailed information of what was being delivered for that release, including: • Updated release roadmap • Progress charts (bugs and work items) • List of demos to be presented • Key areas of concern (for subsequent releases) 10 Lessons Learned In terms of adopting an agile SDLC, here’s what worked for us, and what we could have done better: What Worked Although we used a modified version of SCRUM, we found the end results highly contrasted those from other projects. In the end, we managed to deliver every release (or sprint) on time and under budget, exceeding our client’s expectations every time. Here are the key areas that worked for us: • Top talented, self-driven individuals: This was key to drive a program like this without any lag • Knowledgeable, practical client: The flexibility and experience of the project owner was key to the successful adoption of agile • Quality-driven team: Agile does promote quality through the embracing of change. Our team understood that and drove every effort through top quality standards • Combined remote/co-located schedule: This improved our productivity without affecting progress or visibility with our client, and made a big difference in terms of work-life-balance • Smartdocs for design specifications: This helped minimize rework while the solution evolved What We Could Have Done Better It’s hard to argue with results. However there were other areas we definitively recommend to plan better, including: • Allocate time to train your client: Agile is not for every project and it does require a level of adoption so your client understands what’s the required level of involvement, how the project should be structured and funded • Make pervasive use of automated Unit Testing (UT): This helps different tools to generate all kinds of quality metrics, and is key to support Continuous Integration (CI) • Implement an Application Lifecycle Management (ALM) solution: For projects based on the MS platform, leverage tools like TFS to enable requirements traceability, work item tracking, reporting, integrated test and build support. Multiple reports are readily available generated so project health is visible at all times (without teams needing to spend additional cycles to create them) as shown in the samples below: 11 Agile in Practice - An Agile Success Story An ALM solution centralizes all pertinent project information and facilitates tracking progress and overall project health on demand Figure 10 – Additional Reporting Benefits of an ALM solution Tracking team capacity Tracking team progress 12 Tracking additional project indicators (testing, builds, etc.) 13 Agile in Practice - An Agile Success Story About the Authors Javier Becerril ( Javier is a Specialist Leader in our Technology Systems Integration service line based out of our Costa Mesa office in California. He's a senior advisor to many of our clients, leading architecture work for .Net and SharePoint based solutions. He also leads the Microsoft and Agile Communities of Practice in the firm. During the engagement, Javier led the Deloitte Consulting team, including all aspects of the PMO, SDLC and architecture work. Angel Garcia ( Angel is a Manager in the Technology practice based in the Madrid office in Spain. During the engagement, Angel managed the Deloitte Consulting team and led the functional definition of the solution, including the development of our custom process to define SP artifacts. 14 This publication contains general information only and is based on the experiences and research of Deloitte practitioners. Deloitte is not, by means of this publication, rendering business, financial, investment, or other professional advice or services. This publication is not a substitute for such professional advice or services, nor should it be used as a basis for any decision or action that may affect your business. Before making any decision or taking any action that may affect your business, you should consult a qualified professional advisor. Deloitte, its affiliates, and related entities shall not be responsible for any loss sustained by any person who relies on this publication. As used in this document, “Deloitte” means Deloitte Consulting LLP, a subsidiary of Deloitte LLP. Please see for a detailed description of the legal structure of Deloitte LLP and its subsidiaries. Copyright © 2012 Deloitte Development LLC, All rights reserved. ...
Purchase answer to see full attachment

Tutor Answer

School: UC Berkeley


flag Report DMCA

Goes above and beyond expectations !

Similar Questions
Hot Questions
Related Tags
Study Guides

Brown University

1271 Tutors

California Institute of Technology

2131 Tutors

Carnegie Mellon University

982 Tutors

Columbia University

1256 Tutors

Dartmouth University

2113 Tutors

Emory University

2279 Tutors

Harvard University

599 Tutors

Massachusetts Institute of Technology

2319 Tutors

New York University

1645 Tutors

Notre Dam University

1911 Tutors

Oklahoma University

2122 Tutors

Pennsylvania State University

932 Tutors

Princeton University

1211 Tutors

Stanford University

983 Tutors

University of California

1282 Tutors

Oxford University

123 Tutors

Yale University

2325 Tutors