white paper

Bringing Products to Market Faster and With Better Quality

How Saba Is Leveraging Agile Development Methodology

Salil Prasad
Before we look at how Saba is leveraging agile development
methodology, let’s first look at what is driving the change.
Why the change: Until last year, Saba had been following
traditional waterfall methodology for software development.
This was a big mismatch between Saba’s business
environment and the development methodology it was
following. Traditional waterfall methodology is suitable
for projects that are similar to the ones executed before
or whose end state and the means to get there are very
well known. Most of the software projects do not fall in
that category anymore. Today’s business climate is very
different. Requirements change very fast, and complexities
are increasing with time as well. Even if the end state may
be known, means to get there may not be well known.
In certain situations, even the end state may not be very
clear. Forcing us to clearly define all the requirements
upfront in such a case is a risky proposition. It blurs the
distinction between wants and needs. Customers often end
up completing the requirements ambiguously under time
pressure. The end result may very well be a product that the
customer does not need. Applying the traditional waterfall
approach in such situations is clearly a setup for failure.
Saba’s environment is no different in this case. The HCM
market is new and rapidly evolving. Business rules are
complex and customers have varying needs. Due to
the complexity of the requirements, estimation is also a
challenge. As we know, the traditional/waterfall approach is
change intolerant. As a result, it made it even more difficult
to react to changes in requirements in the middle of releases
and it took us longer to put the products into the hands of
our customers.
Selection of the Scrum approach: Clearly more agility
was needed to be able to adjust to changing business
needs and ship products faster and of higher quality.
However, it is a massive change, and any change has
risk associated with it. It is necessary to proceed with a
mitigation plan when talking about such a large change.
Several agile methodologies were looked at, and the Scrum
approach stood out as the best suited to the company’s
business needs. This approach offers a lot of flexibility
in implementation and easily provides a middle ground
between traditional and extreme project management. This
helps soothe management’s fears about big changes in
development practice.
What is Scrum? Scrum is a much more people-focused
process than other development methods like waterfall,
which are typically process-focused.
By definition it is an iterative, incremental process for
developing any product or managing any work. It produces
a potentially shippable set of functionality at the end of
each iteration. Some of the noteworthy attributes are the
following (as adapted from www.controlchaos.com):
• A wrapper for existing engineering practices
• A team-based approach to iteratively, incrementally
develop systems and products when requirements are
rapidly changing
• A process that controls the chaos of conflicting interests
and needs
• A way to improve communications and maximize
cooperation
• A way to detect and cause the removal of anything that
gets in the way of developing and delivering products
• A way to maximize productivity
Scrum overview: In this approach, the entire project is
broken into multiple cycles of four to six weeks each, called
sprints. Each sprint has a predefined goal.
The product or systems requirements are tracked through
product backlog, release backlog, and sprint backlog.
A product backlog is developed by the business owner and
is a list of capabilities and user stories with their identified
use cases. It contains all outstanding requests and user
stories prioritized as high, medium, or low.
Similar to the product backlog, the release backlog is a
stacked ranked list of user stories for a single release with
the use cases identified for each user story.
3
white paper | Bringing Products to Market Faster and With Better Quality
How Saba Is Leveraging Agile Development Methodology
Sprint backlog is a breakdown of use cases, or set of
use cases to the task level addressing a user story that is
planned to be addressed in the sprint. At any given point,
the team is working on the highest-priority items.
Throughout the sprints, a daily 15-minute Scrum meeting
is held. The meeting focuses on three topics only: what
you did, what you are going to do next, and any issues or
roadblocks. The Scrum master is responsible for removing
any roadblocks.
At the end of each sprint, the Scrum team conducts a demo
of the work done. This provides an opportunity to collect
early feedback from users and make any adjustments if
necessary. It also gives a sense of accomplishment to
Scrum team members.
The best part of the Scrum approach, and perhaps the
most challenging at the same time, is that Scrum is not a
methodology that tells what to do; rather, it is a framework
that gives a lot of flexibility for teams to customize and
adapt according to their environment.
Last but not least, successful implementation of Scrum
methodology requires good change control. There should not
be any scope creep during a sprint. If requirements change,
it is best to reevaluate the priorities at the beginning of the
sprint and address them based on the revised priority. This
creates a win–win situation for the Scrum team as well as the
business owner. Changed or new requirements could still be
accommodated in the same release after proper evaluation
and impact analysis on other aspects of the release.
How Saba is leveraging the Scrum approach:
Initial rollout: We are humans and resistant to change.
Making a direct transition from the age-old waterfall style
is not an easy transition, especially when we are expected
to proceed when all the requirements are flushed out.
We feel uncertain and nervous about things that have not
been tried before and hesitant to try new things. In order
for any change to be effective, it has to be accepted by all
the people who are going to be impacted directly (project
teams) or indirectly (executives). Therefore, the size of the
4
population to influence was huge, and it was a challenge to
make an impact. Moreover, if people do not see the benefit
soon, there is a tendency to start losing momentum. Thus
the approach taken for our company was to mix agile and
traditional methods to mitigate the risk of adopting a brand-
new approach and let people gel into this new approach.
Several of the engineering practices were not touched
initially. After every sprint, we made a decision to come back
and do a mini post-mortem to see what is working, what is
not, where we need to improve, where we did better than
before, and so on. This approach took away a lot of initial
fear and also helped mitigate the risk.
Requirements analysis phase: In a traditional waterfall
model, one has to spend a considerable amount of time in
understanding and refining the requirements until they are
rock solid and frozen. This was a challenge for Saba, as
well. However, in the Scrum approach one does not have
to be bogged down with clarifying all the requirements. We
start with the chunk that is clear or almost clear, build it, and
refine it as we move along. For most of us this is a shocking
statement because we have grown so used to the traditional
waterfall approach.
Scrum meetings and monitoring progress: Saba’s
development staff is in U.S. as well as offshore, and this
allows the company to take advantage of greater scalability
and “round-the-clock” development cycles. Due to the
multishore development environment, it becomes more
compelling to adapt agile methodology as it creates a
framework for greater visibility into the team’s progress. The
challenge was getting daily Scrum meetings rolling.
While multishore development is advantageous for achieving
scalability, it also necessitates frequent cross-geo meetings.
Asking for additional and daily Scrum meetings that are
at times inconvenient for one or more parts of the world is
not going to fly well. Though a slightly different approach
is needed, every change has to be carefully evaluated
before implementing it. Restructuring the team to align
with the Scrum model at the early stage is clearly not the
right approach. Existing team dynamics, knowledge base,
interests, and goals have to be taken into perspective. Hence,
a balanced approach is taken for setting up the frequency
and timing of these Scrum meetings. Also, even though
Product Management plays a “chicken” role (not allowed to
speak during Scrum meeting), it is mandatory that they attend
these Scrum meetings so that they appreciate the workload
and can take prompt action when needed.
Each team is thus allowed to have Scrum meetings three
times a week at times convenient for the local teams. If a
product team spans multiple geos, use cases are split up
so that development can be done independently in sub
teams. However, each of these sub teams needs to be in
sync with each other. To facilitate that, we hold a “Scrum of
Scrum” meeting once a week in which Scrum masters from
each of the sub teams participate and report on progress
and issues. This ensures we do not overlook any integration
issues and have overall visibility into the team’s progress.
Scrum masters also have to report back on the status of
issues in the Scrum meetings, and this helped remove
issues and obstacles sooner. Issues get resolved much
faster, and eventually, the team is able to knock the features
and functionalities down faster. This eventually helps with
improved quality and time-to-market.
Distant collaboration: Prompt issue resolution is crucial to
the success of the Scrum model. The model requires more
than just facilitating Scrum meetings, especially where large
and multishore development teams exist. The team has
to be very creative in how its members communicate with
each other cross-country. There are cultural issues involved
when dealing with message interpretation. For example, a
team from one side of the world passes information to the
other side of the world, asking for prompt action, hoping
that by next day they will have a resolution. But in reality,
they may have left out some crucial information or provided
information that is too vague. They come back to the office
hoping that the issue is taken care of, but instead, they find
a request for additional clarifications, thus wasting another
day. This could be disastrous in critical stages.
Communication challenges do not end here. In today’s
era, e-mails are the most commonly used mechanism
for information sharing. More often than not, e-mails do
nothing more than create noise for most people on the
recipient list. To ensure more agility, a good communication
model is essential, and even more so with global teams.
To address this challenge a number of guidelines are being
set. A variety of techniques from instant messaging, regular
conference calls, personal wikis, and other collaborative
tools work very well and are necessary to close the distance
between teams that are not co-located. Instant messages
are best for quick questions that do not require more
than two to three exchanges of messages for one topic.
If the exchange of messages goes beyond this limit, team
members should pick up the phone and talk. At the same
time, trying to clarify complex problems over the phone or
IM is not a good idea. Team members should create a brief
write-up and send it for advance reading and then follow up
with phone call (if not co-located) for such issues.
Use of collaborative tools is the key, especially where teams
are in different time zones. Rather than relying on e-mails to
pass on key information to team members, it is necessary
to use some kind of dashboard that will force the requestor
to phrase what exactly is needed, who is the request being
made to, what is the expected time of completion, and who
are merely on a cc list. E-mail cannot enforce these rules.
Several collaboration activities are now managed by a single
online tool called TeamTrack, deployed at Saba, and it is
continuously being expanded to include more collaboration
capabilities. This tool is being used to manage integrated
change-control process, risk and issue management,
code completion checklists, backlog management, cross-
team dependencies, code review results, and so on. Since
attributes are predefined and several of these are set as
mandatory fields, it ensures the right information is captured
during the submission process.
Addressing estimation challenges: One of the biggest
challenges a team faces is with regard to estimation. The
requirements are complex and most of the time we are
5
white paper | Bringing Products to Market Faster and With Better Quality
How Saba Is Leveraging Agile Development Methodology
busy exploring newer technologies to give a richer feature
set and more value to our customers. Due to these issues,
estimations are often not accurate. In order to catch up with
lost time, the development team often takes steps that are
not productive.
In contrast, the Scrum approach forces teams to set 30-day
targets. The focus is shorter, and features are broken into
smaller sets of use cases and tasks, which become easier
to estimate and manage. If there are complexities involved
due to newer technologies, issues are known immediately
rather than late in the cycle, as in waterfall. Management
and the team can then take corrective action once issues
are escalated, which could be either to augment the staff,
hire external resources, or adjust the scope. Because goals
are short, and because teams are able to reach goals on
time, over the duration of a project teams start gaining
confidence in their estimations as well.
Parallel development, testing, and user documentation:
In the Scrum approach, development and testing run in
parallel. Development tasks are split up according to the
24–80 hour rule. This allows better insight into the progress
and control of tasks without having to micro-manage the
tasks. As deliverables are checked in, they are picked up for
testing immediately. When critical issues are detected, they
are addressed immediately.
Toward the end of each sprint, one week of stabilization is
allocated. The primary focus of this week is to stabilize the
sprint deliverables while testing is catching up on the last
set of deliverables. This allows entire sprint deliverables to
be in a pretty stable state.
To maintain this agility, management commitment is
required so that resources are not pulled during a sprint
execution. Also, there is more emphasis on development
and testing than maintaining monolithic documents.
However, while the documentation is streamlined, need for
keeping it up to date is even more critical. As a result, if
there are any changes in functional requirements, the team
immediately logs the changes and notifies stakeholders so
that they are always looking at the most current version.
6
Apart from this, user-facing documents also run in parallel
with feature development. The documentation team
participates in Scrum meetings and is current with day-
to-day issues. The parallel documentation and ability to
stay current with the issues help the documentation team
release customer-facing documents on time and updated
with known issues.
Change control: Because of so much agility and being
open to changing requirements, it becomes easy at times
to be carried away with changing requirements. Hence
it is essential to have a robust but lightweight change-
control system in place. An online tool is implemented that
shares the same database as product backlog to submit
and manage change requests. The chosen mandatory and
optional attributes that help capture necessary changes
upfront without having to go back and forth when analyzing
change requests. Once a change request is submitted, all
stakeholders are involved in analysis and decision-making.
If approved, the request moves to release backlog, and the
plan is updated. This helps ensure proper risk consideration
is made and scope changes are carefully managed.
Sprint demos for early feedback and reinforcement:
Sprint demos are conducted at the end of every sprint.
This is an open invitation to field personnel who are
actively engaged with customer issues. They get a
firsthand chance to look at what is being developed or
what has been developed so far. This serves several
advantages. Support and Consulting groups get to see
the product actually functioning before formal knowledge
transfer and training. Presales and Marketing groups get
the opportunity to provide real-time feedback from what
they hear from our customers. And also, in some cases, it
allows the team to do an advance demo for customers to
get early feedback.
After the sprint demo, a user acceptance test is conducted
against the functionally complete features. Feedback items
are prioritized and an action plan is developed to address
them in next sprint or next release as the case may be. If
items stand to be of higher priority than the other items
scoped for the subsequent sprint, the team works on those
first, and lower-priority items get deferred out as applicable.
Post-mortems as a way to continuously improve: At
the end of every sprint, we conduct a post-mortem to
look at what went well and where we can continue to
make improvements. The meeting is kept very informal to
encourage active participation. An action plan is developed
to apply those learnings to the subsequent sprint. This helps
us keep refining our development and testing practices on a
continuous basis.
Stabilization sprints to make the quality better: After all
the development sprints are over, we enter into stabilization
sprints. No new feature development is done in this phase. All
critical and important bugs are addressed to ensure the end-
user experience is as smooth as possible. Thorough reliability,
scalability, and availability tests are done and performance
issues are fixed as and when they are found. Locales are also
back after translations in this phase and linguistic reviews
are conducted and feedback items addressed as well. These
sprints are of shorter duration, and each has its own set of
goals to help achieve measured progress.
Closing: Thus, we have seen how we are getting the
most out of our distributed workforce as well as an agile
approach. Inherently they are not compatible with each
other but if managed carefully, we can reap the benefits of
both. There are organizational and cultural challenges. For
example, the waterfall method is fine where team structure
is more of a managerial hierarchy, but an agile methodology
is insistent upon open and flat structure. Moreover, in
Eastern cultures the management culture is more autocratic
and value is often measured by the number of people one
manages. But Scrum requires a smaller and manageable
team. Thus a delicate balance has to be carefully achieved
for Scrum to be successful. As an example, if a team is
used to getting detailed requirements upfront, and then
suddenly gets immersed in an agile environment where
requirements are not detailed, this impacts relevancy,
productivity, and quality of deliverables. Obviously there
are several challenges in reaping the most out of the Scrum
model in a distributed workforce, but once achieved, results
are phenomenal. As Ken Schwaber, co-creator of Scrum
and author of Agile Project Management with Scrum, says
in one of his articles, “Scrum is not for those who seek easy
answers and simple solutions to complex problems; it is for
those who understand that complex problems can only be
met head on with determination and wit.”
7
© 2007 Saba. All rights reserved. Saba, the Saba logo, Centra, and the marks relating to Saba products and services referenced herein are either trademarks or registered
trademarks of Saba or its affiliates. All other trademarks are the property of their respective owners.

Saba 2400 Bridge Parkway Redwood Shores CA 94065-1166 USA (+1) 877.SABA.101 or (+1) 650.779.2791 www.saba.com Rev. 10/07