Two Agile development case studies illustrate the key roles in the Scrum method of the outer three layers of the Agile "planning onion": strategy, portfolio and product. Coordinating the roles of multiple teams and projects involved the creation of a solid front-door process including backlog, vision, estimates, quotes, inception and transition.
The Work Ahead in Healthcare: Digital Delivers at the Frontlines of Care
Agile Planning in a Multi-project, Multi-team Environment
1. • Cognizant 20-20 Insights
Agile Planning in a Multi-project,
Multi-team Environment
How organizations evolve to cope with the challenge of scaling Agile
planning and improving its reliability.
Executive Summary the number of people involved and the frequency
can increase as you peel down through the onion.
As Agile methods continue to gain popularity
Therefore, it is vital to get the first three layers
across the software development community, the
right and to mitigate the risk of spending money
Scrum method is on the verge of becoming a de
on features that may not be built or may be built
facto industry standard. Though there are success
differently.
stories and recommendations, additional under-
standing of the challenges in the adoption of This white paper, with its focus on two illustrative
Agile methods in general, and Scrum in particular, cases, throws light on industry best practices in
is needed. Agile planning in a multiple-project, multi-team
environment by detailing the first three layers
The adoption of the Scrum process in a multi-team
of the planning onion — strategy, portfolio and
context — with groups working simultaneously on
product.
several projects — is one area that is in severe
need of attention.
Case One: Online Platform in the
Planning Onion Telecommunications Industry
Mike Cohn, the cofounder of Scrum Alliance, has Operating in the European region, a leading tele-
described the planning continuum using an onion communications company undertook the con-
analogy. With this image, strategy is the outermost struction of an online platform. The program
layer followed successively by layers for portfolio, consisted of 20-plus subprojects spanning
product, release, iteration and daily segments as diverse areas, from online shopping to customer
you approach the onion core (see Figure 1). There care. The platform was developed and maintained
is no one tool or technique perfectly suited for by a mixture of in-house development teams and
each level in the onion. third-party vendors operating in both Agile and
Waterfall methods. However, the delivery team
The certainty of undertaking activities addressed and product management team were strongly
in each of these levels increases as you peel the committed to the Agile methodology.
onion. As a result, the amount of detail addressed,
cognizant 20-20 insights | november 2012
2. Peeling the Agile Onion backlog and from there it should be picked up
by one of the front-door team members.
• Vision: This is where the front-door member
works out the high-level requirements by estab-
lishing the goal, the benefits and the customer
experience. This team member will work out
Strategy the best way to deliver the work with the funds
Portfolio available, and set the initial expectations on
Product the size of the challenge. Particular emphasis
Release is given to how the solution fits with the overall
Iteration strategy and within the current portfolio.
Daily • Initial estimate: Once the scope of the require-
ment is understood, the front-door member
works with the online delivery team and third
parties if needed. The front-door member
Source: Mountain Goat Software.
estimates the high-level cost to complete the
Figure 1
request. The front-door member then goes
The teams received more than 1,000 requests through the estimate with the product owner.
to add, enhance or modify functionality of the • Inception: Sometimes it just isn’t possible to
platform in the last year alone from different nail down the requirements. In such cases, the
areas of the business. So, the challenge was to front-door member brings the project team
ensure that the delivery team — consisting of together with representatives of the online
multiple Scrum teams and vendors — adhere to delivery team, who’ll help shape the require-
the strategy set out by the product management ments and devise a more detailed estimate.
team. Given that only one of every two requests
gets financial approval, this mammoth task had to • Detailed quote: After the inception, a detailed
quote with an indicative cost to complete the
be executed with minimal waste of effort. It also
piece of work is given. Note that the quote
required an evolving design and architecture to
is given in monetary terms based on T-shirt
comply with the Agile principles of development.
estimation. Naturally, the variance and risk
This was achieved by setting up a dedicated front- involved in the estimates is made clear to the
door team that sits within the delivery team to product owner.
act as a primary point of contact for each product • Transition to delivery: Once the product owner
owner. Every request from any product owner had approves the estimate, the request is transi-
to go through the process diagrammed in Figure tioned for delivery. The product management
2, which enabled the delivery team to adhere to team then prioritizes the requests by liaising
the first three layers of the planning onion. with the product owners. In the Scrum of
Scrums meeting, one Scrum team picks up
The front-door process includes the following:
the request based on available resources and
skill sets. Note that from this point on, we are
• Backlog: This is where the business and
dealing with the bottom three layers of the
product owners engage with the front-door
team about any piece of work, whether it’s by planning onion. The Scrum team then liaises
phone, e-mail or face to face. It’s added into the with the product owner to deliver the request
per the business requirements.
Front-Door Process
Initial Detailed Transition to
Backlog Vision Inception
Estimate Quote Delivery
Figure 2
cognizant 20-20 insights 2
3. Case Two: E-commerce Platform in the prototypes and demos are used to minimize the
Airline Industry use of documents. Once the client (product owner)
is happy, he agrees on the delivery method and
Our second case in point involves an e-commerce
date with the project management office. If the
platform (or product) developed, customized and
request is approved, the feature request returns
hosted by a global software provider to the airline
as a Story to the backlog item with well-defined
industry. This solution is used by more than 20
acceptance criteria for development.
airlines operating in different geographies. The
diverse nature of the legislation and regulatory Results
compliance needed, coupled with varying require-
For both the cases, the observed results of the
ments for both budget and conventional airlines,
planning approach are as follows:
make it a complex systems development activity.
At any point in time, more than 100 requests from
various clients using different versions of the
• Case One: The front-door team received 1,012
requests over the first year. All of them were
customized solution have to be addressed by the initially cost-estimated. Figure 4 shows the
product management team. items estimated by the front-door team, bro-
ken down by calendar month and project area.
Similar to the first case, only one in every two
Note that only 46.2% of the requests (i.e.,
requests will be approved by the client based on
465 requests) were approved for delivery and
the estimates provided.
eventually transitioned to delivery. Many of
Figure 3 depicts how these requests were planned the items transitioned have either been deliv-
and estimated, before going back to the customer ered or are currently being developed. Given
for approval. that the front-door process was put in place
just over a year ago, the feedback received
The requests originate with the customer-fac- thus far from the business and Scrum teams
ing project managers who hand them off to has been positive. There is an overwhelming
the product management team. The product feeling within the business that this planning
management team prioritizes the requests by process is more transparent, relatively accu-
liaising with the project managers. These requests rate and reliable than the planning process
are fed into the Scrum of Scrums as research previously in place.
spikes for estimation. They are then picked up
by Scrum teams at least two Sprints (over two • Case Two: Before this planning process was
introduced, several customers were unhappy
weekly Sprints) in advance.
with the turnaround time of their requests.
Once the research spike is played in a Sprint, the One key customer was in a state of high
team proposes a high-level solution and relative escalation. After nine months of following this
estimate that is passed back to customers through planning process, along with other Agile meth-
the project management team. Where necessary, odology compliance improvements, many of
these customers have openly stated that their
Scrum of Scrum Process
Customer 1
Customer 2 Scrum teams estimate the
Scrum of requests as research
spikes and provide relative
Scrums estimates.
Customer 3
Figure 3
cognizant 20-20 insights 3
4. Front-Door Request Estimates
30
25
Number of Projects
20
15
10
5
May 2012
0 April 2012
March 2012
February 2012
January 2012
Project Areas
Figure 4
response times for estimation have improved same time. If not handled effectively, this multi-
significantly. As a testimony to the success tasking set of activities puts pressure on the team
of this Agile planning and distracts them from delivering their Sprint
Organizations must process, the key customer commitments.
evolve to adjust who was in a state of high Because of this problem, this is an area where
alert has now left red-alert
planning techniques status. a wide range of hybridization has occurred.
to fit their governance However, as demonstrated in this white paper,
Gaining Agile Momentum organizations must evolve to adjust planning
structures, culture techniques to fit their governance structures,
Planning and estimation
and risk profiles in a have often been contro- culture and risk profiles in a manner that
manner that increases versial areas for organi- increases standardization without ignoring the
principles of the Agile Manifesto. There is no one-
standardization without zations following Agile,
size-fits-all solution and therefore organizations
Waterfall or iterative
ignoring the principles methods. In particular, the can’t take the cookie-cutter approach to address
of the Agile Manifesto. key issues of predictabil- this challenge.
ity and standardization
It is clear that an organization has to inspect and
come up time and again. This gets exacerbated
adapt to fine-tune the planning process, before
in a multi-project, multi-team environment where
getting it right. This can be achieved only through
teams are expected not only to work on multiple
able leadership and support from an Agile coach
projects simultaneously, but to estimate the
with experience in Agile transformation projects.
requests and revert to the product owners at the
About the Author
Premkumar Lakshminarayanan is a Scrum Master in Cognizant’s Agile Center
of Excellence within its Advanced Solutions Practice. He can be reached at
Premkumar.Lakshminarayanan@cognizant.com | LinkedIn: http://uk.linkedin.com/
in/premkumarl | Twitter: https://twitter.com/PremkumarL.
cognizant 20-20 insights 4