CIS 443 Agile Project Management Case Study 1

This is a 4-5 pages assignment in Agile Project Management.  The suspense to complete the work is January 26, 2018 at 5 pm eastern time.  Attached is the assignment.

CIS443 Agile Project Management

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

Due Week 4 and worth 100 points

Read the article provided here titled “Agile in Practice – An Agile Success Story” and complete this case study assignment.

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..

Agile in Practice

An Agile Success
Story

February 201

2

2

Agile in Practice – An Agile Success Story

Contents

Overview
  1
 
Why
 Agile
  2
 

How
 We
 Did
 Agile
  4
 
SCRUM-­‐derived
 Model
  4
 
Distributed
 Teams
  5
 
Planning
  6
 
Execution
  7
 

Documentation
  7
 
Reporting
  8
 

Lessons
 Learned
  11
 
What
 Worked
  11
 
What
 We
 Could
 Have
 Done
 Better
  11
 

1 Agile in Practice – An Agile Success Story

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

2

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 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

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

3 Agile in Practice – An Agile Success Story

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.

We adopted agile incrementally
to minimize project disruption,
we evolve our process while
keeping the project going

4

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

5 Agile in Practice – An Agile Success Story

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 ever-
evolving 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 co-
locating 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-life-
balance. 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.

The team was able to reduce
travel without impacting
visibility with the client,
resulting in increased
productivity and boosted team
moral

6

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

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

Our sprint planning selected
features from our product
backlog, starting with those
with the highest priority, and
split them into actual tasks

7 Agile in Practice – An Agile Success Story

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 All infrastructure work and specifications were done by the client

Smartdocs helped keeping our
functional and technical
specifications up-to-date while
minimizing the need for rework

8

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 smart-
docs 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

9 Agile in Practice – An Agile Success Story

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

10

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)

11 Agile in Practice – An Agile Success Story

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:

An ALM solution centralizes
all pertinent project
information and facilitates
tracking progress and overall
project health on demand

12

Figure 10 – Additional Reporting Benefits of an ALM solution
Tracking team capacity

Tracking team progress

13 Agile in Practice – An Agile Success Story

Tracking additional project indicators (testing, builds, etc.)

14

About the Authors
Javier Becerril (jabecerril@deloitte.com)
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 (agarciapujalte@deloitte.es)
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.

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 www.deloitte.com/us/about for a detailed description of the legal structure of Deloitte LLP

and its subsidiaries.

Copyright © 2012 Deloitte Development LLC, All rights reserved.