Introduction to Agile Development

www.whizlabs.com | ©Copyright 2013 Page 1
Module 2:
Introduction to Agile Development

Table of Contents
Module 2: Introduction to Agile Development.............................................................................................3
Agile Movement........................................................................................................................................3
Agile variants.............................................................................................................................................4
Iterative and incremental .........................................................................................................................5
Agility ........................................................................................................................................................6
Agile Manifesto.........................................................................................................................................7
The Twelve Principles of Agile Manifesto.............................................................................................8
Declaration of Independence .............................................................................................................12
Agile project management vs. Tradition project management..............................................................13
Myths and concerns about Agile approaches.........................................................................................15
When to use and when not to use agile.................................................................................................16
Module Revision .....................................................................................................................................17
Case Study...........................................................................................................................................17

Module 2: Introduction to Agile Development
Agile Movement
Traditional software development methodologies believe in up front planning. In waterfall model, we
first gather all the requirements and then move to design and build phase. Some of the key assumptions
in traditional approaches are:
 Project management is a predictable & repeatable process.
 We can accurately estimate the efforts and resources requirement well in advance.
 We can actually create a plan up front that would almost remain intact in the course of project.
 Requirements can be completely specified in the beginning of project.
 Users can explain the requirements and know exactly what they need, without seeing a working
product
 Requirements will hardly change
This all worked well in simple projects wherein uncertainties were limited. However, these assumptions
were heavily challenged in complex and innovative projects. Over the years, in spite of heavy process
centric methodologies, large number of IT project failed.
In response to these challenges & failures, agile methods were developed, which were largely based on
empirical process control i.e. an adaptive rather than prescriptive development approach. Iterative
development and continuous delivery of working products or prototypes (incremental) was the key
change.

Agile variants
In 90’s number of agile methodologies became popular and successful. Some of the examples are:
 Extreme Programming (XP)
 SCRUM
 Lean Software development – Inspired from Lean manufacturing concepts.
 DSDM
 Feature Driven Development
 Crystal Methods
 Unified Process (UP)
XP, SCRUM and Lean are considered as lightweight agile approaches and that’s where ACP exam seem
to have most focus.
Some of the differences between these frameworks are quite minor. For e.g. SCRUM calls iteration as
sprint while others prefer to use word iteration itself. SCRUM typically recommends 30 days iteration
while XP prefer to 1-2 week long iterations.
In overall agile framework, these variants complement each other. While most of the basic principles
remain same, each framework offers some unique good practices for e.g. XP is quite famous for its
engineering practices such as pair programming, test driven development etc. Lean is quite famous for
managing wastes.
Towards the end (Module 13), we will discuss more about these various variants. More specifically, we
will cover XP, SCRUM and Lean as ACP exam seem to focus more on these three.

Iterative and incremental
Most of the agile methodologies such as scrum and XP are iterative and incremental. Let’s understand
what iterative and incremental mean as we will be using these terms very often.
Iterative process is all about successive refinements. For e.g. if we need to draw a painting, we will first
create a base, then will draw the picture, after that we will color the picture. In the end, we will make
minor tweaks (finishing touch) to make it look nice. This is a kind of iterative process as there are
successive refinements.
On the other hand, incremental process is about building and delivering in pieces. In above example, the
painting might be delivered in few parts. Each part will go through complete process i.e. base creation,
drawing, coloring, refinements. See below diagrams to understand more:

Agility
As defined by John Highsmith, one of the originator of Agile Methods.
"Agility is the ability to both create and respond to change in order to profit in a turbulent business
environment.”
“Agility is the ability to balance flexibility and stability."
While, responding to change guards against competitive thrusts, creating change require innovation:
Developing new products or enhance existing, creating new sales channels and improving product
development time.
However, when we are creating something innovative or complex, we can’t fully anticipate. That’s why
process centric metrologies often fail in such cases. Agility doesn’t mean lack of structure. It’s a just a
right balance between order and chaos; flexibility and stability.

Agile Manifesto
In 2001, representatives from various agile methodologies came together and formed Agile Alliance.
They authored Agile Manifesto and Agile Principles, keeping software development in mind.
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do
it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Top Tip – Remember all four values and understand meaning of these. It’s quite likely to have few
questions around these in ACP exam
A deep understanding of each and every word of Agile Manifesto is not only required for ACP exam but
also required for real life implementation of agile concepts.
A common misconception is that agile philosophy is against plan, processes and documentation.
However, if you read carefully, it only tells what should be focused more. Let’s have a close look at each
statement.
a) Individual and Interactions over processes and tools
 Processes are tools are certainly important but its individuals who choose, what would
be the appropriate processes & tools for given project.
 It’s the individuals who follow these processes and make right use of these tools. If
processes are too heavy to follow or individuals are not engaged enough to follow
these, processes would simply fail to work.
 Without much of processes and tools, there is a good possibility that a group of skilled
and motivated individuals will deliver the successful project. However, vice-versa is not
true. For e.g. we may have a robust review process but imagine what would happen to
the quality, if one novice is reviewing the work of other novice. Or, reviewer is not
motivated to do a critical review and doing it casually just for the sake of process
compliance.
b) Working software over comprehensive documentation
 Software without good documentation is problematic from maintenance & support
point of view. However, comprehensive documentation without software has no
business value. [Given a choice, would you pick a primitive video game or a detailed user
guide for an advance video game?]
 User would be in much better position to provide feedback on working software even
with less number of features, than with large document detailing all the features &
usage scenarios.
 Documentation is to help driving common understanding and assist in the process of
developing working software. However, primary goal is still to develop working
software.

c) Customer Collaboration over contract negotiation
 Our sole purpose of doing the project is so that customer can realize business value.
Only customer can tell what they want then isn’t it fair to listen to them and be flexible
about their needs [How would you feel if you have ordered furniture but then realized
that size isn’t good as per your room measurements and shop keeper doesn’t let you
modify the order].
 It’s difficult for customer to define an upfront and unchanging view of what should be
built. It’s likely that customer won’t get it right the first time. It’s likely that they would
change their mind.
 Successful developers work closely with their customers, they invest the effort to
discover what their customers need, and they educate their customers along the way.
d) Responding to change over following a plan
 Changes can come from various factors. Customer priorities may change or customer
may just get a better idea to improve ROI. Market/Business may change. Technology
can change. It could just be a result of improved understanding of problem domain.
 Rather than sticking to the original plan, we should respond to the inevitable changes.
Moreover, we should be flexible about changes, which help in reducing the risk and
maximizing ROI.
 This doesn’t mean we should not have a plan. Instead of suppressing changes and
sticking to a static plan, we need to acknowledge that things will change. We need to
accommodate the changes, which help in meeting key project & business objectives.
The Twelve Principles of Agile Manifesto
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable
software.
2. Welcome changing requirements, even late in development. Agile processes harness change for
the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need,
and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development
team is face‐to‐face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should
be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity—the art of maximizing the amount of work not done—is essential.
11. The best architectures, requirements, and designs emerge from self‐organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts
its behavior accordingly
Top Tip – Remember all twelve principles and more importantly the intent behind writing these as
explained below. It’s quite likely to have few questions around these in ACP exam

Let’s understand more about these 12 principles
a) Our highest priority is to satisfy the customer through early and continuous delivery of
valuable software.
 Many people within IT seem to do the project keeping the technology management
layer in mind rather than end customer. This principle reminds that most important
sign for a successful project is customer satisfaction.
 Valuable software here means working product or prototype - something that
customer can easily understand & appreciate. Deliverables such as design document
or software code have no meaning for customer. The focus is on the end goal, which
is working product.
 Early and continuous delivery of valuable software not only gives confidence to the
customer but also provides opportunity to receive customer feedback so that we
build what is right for the customer rather than what was specified initially.
b) Welcome changing requirements, even late in development. Agile processes harness change
for the customer's competitive advantage.
 Let’s take an example. We are building a product and then realize competitors have
launched a product with similar features. Unless we add some other exciting features in
the product, launching that product would be just waste of time and money.
 Traditional change management processes were designed to prevent/reduce scope
creep. But nowadays these processes are generally so rigid that these actually tend to
suppress changes.
 Agile processes acknowledge the fact that change will happen and provides an effective
way to deal with them by using a value driven iterative development approach.
c) Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter time scale.
 If you read carefully, it doesn’t prescribe any specific duration for iteration. It just
state the preference for more frequent delivery of working software so that there
are more opportunities for stakeholders to provide feedback, which reduces the risk
of going too far down the wrong track.
 More frequent delivery improves customer’s confidence. Often in a demo meeting,
team learns of new requirements or changes in business priorities, which are
important for improved ROI.
d) Business people and developers must work together daily throughout the project.
 When team works closing with business, team understands the business in a way that is
far beyond the typical requirement collection mechanisms. Scope creep due to missing
requirements and incorrect interpretation of requirement reduces drastically.
 Frequent demos to business people are another example of close working together.
 In some cases it’s not really feasible to have business people literally available daily. But
agile methods try to get as close collaboration as possible.
 Some teams use an experienced business domain expert as “proxy customer”. While
this can help development but this should not be a replacement of customer
interaction.

e) Build projects around motivated individuals. Give them the environment and support they
need, and trust them to get the job done.
 There are numerous industry examples wherein a team of skilled and motivated
individuals could achieve the goal while a much larger team failed to achieve similar
goal.
 Too many organizations just hire hordes of people and think that these would make
build successful software with help of heavy process framework. This doesn't seem to
work all that well in practice.
 While we don’t have the choice to choose our dream team and most skilled people. At
least we can do our bits to motivate them to get best out of them.
 A team of motivated individuals doesn’t require micro-management and project
manager can focus on removing impediments rather than doing day to day task
management.
 Agile teams, realize that you need to build teams from people who are willing to work
together collaboratively and learn from each other. In these kinds of teams, continuous
improvement never stops.
f) The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
 Exchange of information through e-mails or by sharing information is slow and effort
consuming mechanism. Still the interpretation may go wrong. A quick talk over the
phone can achieve results much faster and better.
 Face to face talk is even better as along with information, emotions, body language can
also be conveyed, which not only makes the information exchange even quicker &
better but also helps in reducing conflicts.
 In face to face conversation, you can quickly draw diagrams and have wide range of
techniques to express complex ideas.
g) Working software is the primary measure of progress.
Traditional approaches use documents or other forms of intermediate deliverables as
measure of progress. There are following issues with that:-
 Focus gets shifted from working software which is ultimate goal, to these intermediate
deliverables.
 We might show percentage completion or Earned value by measuring progress in terms
of intermediate deliverables but until we show the working software to business and
confirm that it meets the customer requirement, there are chances that we are just
going on wrong track.
 What if project has to be stopped in the middle, we might have a high earned value and
x% of work completion but without any working product, is there any value for
customer? In case of working software, customer may still make some use of features
delivered till then.

h) Agile processes promote sustainable development.
 Agile believes in a sustainable work pace rather working long hours just before key
milestones. XP recommends 40-hours work week.
 A sustainable work pace is better for team members for their work-life balance. It also
benefits the business because un-necessary stretch reduces the motivation levels and
increases the risk of people resigning. Hiring and training the people is a very costly
affair.
 8 hours work with full focus and attention is better than 12 hours of mediocre work.
There are chances of poor quality and rework later on, which will actually reduce the
overall output.
i) Continuous attention to technical excellence and good design enhances agility.
 It's much easier to understand, maintain, and evolve high-quality source code and a
good scalable design, than it is to work with rigid design & low-quality code.
 Agilists recommend a range of design & code development principles & practices for
technical excellence.
j) Simplicity – the art of maximizing the amount of work not done – is essential.
 Agile developers ask themselves “what is the simplest thing that could possibly work”.
 Rather than anticipating changes and adding numerous additional features or
extensibility hooks, agile developers create a simple and clean design. Un-intuitively,
this results in designs that are ready for any change, anticipated or not.
 Agile developers have strong focus on automation and reusability.
k) The best architectures, requirements, and designs emerge from self-organizing teams.
 Essentially it is saying getting the best from the people. A self organizing team is
naturally motivated to continuously find better solutions and improve ways of working.
 We may get number of ideas from experts outside the team but unless ideas are well
understood and well implemented by the team, purpose is defeated. Team is closed to
technical details and can choose which idea would actually work in project.
l) At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behavior accordingly.
 Gathering lesson learnt at the end of project might add to organization’s lesson learnt /
best practices repository but it’s too late for the project. In fact, these lessons learnt are
rarely being used much in practice – one because every project is different and second
because people tend to learn more from their own experiences than someone else’s
experiences.
 Agile projects often conducts sessions (called as retrospectives), typically after every
iteration to learn from past and adapt.
 The beauty of iterative development is there are ample opportunities to learn from
previous experiences and continuously improve. The key is to have that focus on
reflection and taking concrete actions from learning.
The Agile Manifesto provides a philosophical foundation for effective software development. This
doesn’t prescribe any particular methodology.

Declaration of Independence
In 2005, a group headed by Alistair Cockburn and Jim Highsmith wrote an addendum of project
management principles, the Declaration of Interdependence, to guide software project management
according to agile development methods. The principles of declaration of independence are:
 Increase return on investment by making continuous flow of value our focus.
 Deliver reliable results by engaging customers in frequent interactions and shared ownership.
 Expect uncertainty and manage for it through iterations, anticipation and adaptation.
 Unleash creativity and innovation by recognizing that individuals are the ultimate source of
value and creating an environment where they can make a difference.
 Boost performance through group accountability for results and shared responsibility for team
effectiveness.
 Improve effectiveness and reliability through situationally specific strategies, processes and
practices.
Key Points To Remember
- Agile manifesto was written keeping software developers in mind while declaration of
independence was written keeping project lead/managers in mind.
- Agile movement has greater influence on software as many of the agile methodologies were
invented by software professionals. However, most of the concepts are so generic that these
can be used across industries.
- While Agile manifesto is written keeping software developers in mind, this can very well be
used for other industries. To make it clearer, some people prefer to replace word ‘software’
with ‘product’.
- There are many generated accepted standard practices, which people see as part of integral
part of agile for e.g. user story. But the fact is as long as basic principles are being followed,
the methodology can still be called agile.

Agile project management vs. Tradition project management
Based on what we learnt as part of Agile Manifesto discussion, let’s summarize the key differences
between Agile and traditional project management
Traditional Project Management Agile Project Management
Focus is on plans and triple constraints Focus is on customer satisfaction and customer
value. See refined triple constraint diagram
mentioned below.
Breaking the work in activities and tasks and
managing activities/tasks.
Breaking the work based on features
Top down command and control Participative culture. Empowered, self organizing
team
Prescriptive heavy process framework Lean, light weight and adaptive processes
Measurement & reporting is largely based on non-
value items for e.g. % completion of activities or
deliverables
Value focused measurement for e.g. number of
completed features (Working s/w is primary
measure of progress)
Typically Scope based delivery Time boxed (fixed time duration) delivery. Scope
changes based on customer priorities
Up front planning and requirement gathering. In
other words Plan what you expect will happen
Progressive elaboration. Multiple levels of
planning. Plan what you expect to happen with
detail appropriate to the planning horizon
Enforce that what happens is the same as what
you planned
Inspection and adaptation (review and
retrospectives)
Discourage changes late in the lifecycle – heavy
change management processes
Flexible about changes. Use agile practices to
manage change
- continuous feedback loops between team
and customer
- Prioritized backlogs
Documentation as key medium to exchange
information
More focus on face to face conversation and close
collaboration
Please note that this table is slight exaggeration of traditional project management. In reality most of
the experienced project managers do practice some or other practices recommended in Agile Manifesto
as lot of it is pure common sense.

In agile, scope is fixed so traditional triangle of triple constraints is viewed as inverted.
A more advanced view of agile triage is:

Myths and concerns about Agile approaches
While we clarified most of the agile concept, let’s understand some of the common misconceptions
about Agile approach.
Myths Facts
Agile can be used only for small
projects and small teams
 There are various agile scaling models.
 There are examples wherein agile were successfully used for
more than hundred member’s team. Of course, there were sub
teams each having roughly 8-10 team members.
For Agile team must be
collocated
While there is strong preference about co-location, there have been
multiple models developed as guidance to use agile development
with distributed teams. Though it requires extra focus on
communication & collaboration.
Agile methods conflict with PMI
PMBOK
 PMBOK doesn’t recommend waterfall or any specific processes.
It says – for any given project, the project manager is responsible
for determining appropriate processes.
 PMBOK does focus on continuous planning and talk about
progressive elaboration.
 In summary, knowledge of PMBOK would actually help in better
management of any project be it agile or non-agile.
Agile practitioner does not plan Plan is nothing, planning is everything. In agile approach, rather than
initial up front planning, planning happens at multiple levels. Agile
practitioners conduct planning meeting at the beginning of each
iteration.
Agile practitioners just jump on
the code. Approach that would
fail for complex requirements or
complex systems.
Absence of heavy requirement or design document doesn’t mean
that agile practitioner do not do enough ground work. If systems are
complex, there could be an iteration zero to lay the basic foundation.
Other than what has been mentioned above, a typical question that people ask – if Agile methods are so
wonderful why do agile projects fail. Typically there are following reasons:
1) Agile methods are no silver bullet if there are fundamental issues such as problem with
knowledge and skills of the team. Agile would still help as it would fail fast. Issues which you
may typically realize many months down the line, you may realize after first iteration itself.
2) Lack of support from customer or management of performing organization.
3) People call the projects as agile but do not understand agile concepts. Many of them run mini-
waterfalls (phased approach) and think that they are using agile methods. Poor implementation
of any framework doesn’t prove that framework is faulty.
4) Agile gives flexibility of scope changes but if on the name of agile, most of the requirements
keep on changing all the time, team will just end up doing rework and even agile can’t help.

When to use and when not to use agile
Agile methods are useful when :-
a) Developing innovative products
b) Changing market/economic conditions
c) Complex product
d) Customer requirements are changing
In summary, if there are lot many uncertainties about scope, market conditions, and productivity
assumptions etc, agile through its adaptive style of working and continuous risk management would
work much better than a typical waterfall model.
It requires:
a) Skilled and motivated individuals.
b) Sufficient customer support and close customer collaboration.
c) Support from management of performing environment.
Usage of agile methods should be carefully considered when:
a) Simple & straightforward project. There is little unknown. Iterative development will be
costly as each of the iterations will have some overheads involved.
b) Organizations with rigid process framework and slow decision making.
c) Limited involvement form customer/users.
d) Heavy on back-end changes – if nature of project is such that user can’t easily see and
understand the changes.
e) Heavy legacy tightly coupled system and slow development. Typical issues could be
a. Development of any functionality that user can see & appreciate would take quite
long
b. It would be difficult to break the scope into features which can be independently
developed, tested and demonstrated to customer.
f) Team having all novice team members – Idea of self organization will be defeated.
g) High-regulatory compliance requirements or areas wherein there is no room for error. For
e.g. pharmaceuticals. If no room for errors then experimentation and adaptation process
may not work.

Module Revision
Case Study
ABC Ltd. was quite popular for its accounting product. To increase revenue with existing customer and
gain new customers, ABC was planning major enhancements in its accounting product. Company’s CEO
John was quite interested in this project. Neo was selected as project manager for this project.
Initiation
Neo was quite experienced. He quickly identified key stakeholders. Sales & marketing department was
the key stakeholder and there few senior marketing managers acting as customers. These business
stakeholders were conducting various focus groups, surveys etc to identify potential end customer
requirements.
With help of subject matter experts, within a week he got order of magnitude estimate and high level
plan. As per plan, this was 7-9 month long project, with roughly 1 month to gather detailed
requirements for all 10-15 proposed features.
Requirements
Neo started working with business stakeholders and scheduled multiple workshops to understand
detailed requirements & have functional specification ready. The key challenges were:
 For some of the proposed enhancements, when asked about detailed business rules, business
stakeholders were clueless.
 For some of enhancements, there was lack of consensus between various business stakeholders.
In spite of all effort put in by Neo and his domain/technical experts, it took almost 3 months to have
functional specification ready, which was more than 100 pages document. As this was two months late,
plan was broke in the beginning itself. CEO John wasn’t very happy but he provided his approval for
Neo’s revised plan.
Risks
Neo’s plan was having two key risks identified, one around changes in scope and other around testing
productivity assumptions.
Neo & team had assumed roughly 2000 scripts/cases in testing with roughly 50 scripts a day execution
rate. With few days slack, Neo had assumed 9 weeks testing duration. These assumptions were based
on available history data. However, few features needed integration with new technologies for which
there was no history data so Neo decided to raise a risk up front.
Design & Build
In spite of huge detailed functional specification, there were confusions. When clarifications were
sought with business, it resulted into rework. It took almost a month for team to produce a design
specs.
Team was now in build (coding and unit testing) phase and all the while Neo was closely tracking the
status and reporting to senior stakeholders using earned value management. He was using a robust
work authorization system to assign activities/tasks to the team. He somehow felt lack of task
ownership in team members. No activity ever finished before time. Due to this he ended up doing more
and more close status tracking. He was also trying hard to minimize the deviation from original cost
baseline and milestone agreed.

Change Request 1
One fine day, a change request was raised. After impact assessment it was clear that accepting this CR
(change request) is surely going to impact the timelines but management wasn’t happy with that. Neo
added extra resources. He applied schedule compression techniques such as crashing & fast tracking to
accommodate this extra scope. New resources had learning curve and in spite of all planning, team had
to work weekends.
Change Request 2
When build was about to finish, one of the customer raised another change request for an additional
feature. This change request was based on latest marketing research of competitor’s product and this
was really something high value for business. Neo had already used all possible slack and he had to
clearly state that adding this feature at this stage would mean delaying the entire project by a month.
After much deliberation, CEO John decided one month delay to the project and rework was substantial.
Testing
Finally, build got over and testing started. The risk which Neo identified earlier did occur and testing
team was hardly able to finish 30 scripts per day. Large numbers of defects were adding further to the
problem. Neo was under tremendous pressure. His half of the time was going in clearing up the testing
mess and other half in managing stakeholders who were demanding more & more regular progress
reports.
Even after taking risk based testing approach and deferring a good number of test scripts/cases, it took
almost 3 months to finish the testing.
UAT/Business Demo
Product was now ready and a demo was planned, calling all key stakeholders. Everyone was quite
excited about seeing the working new product first time.
Neo was expecting a good outcome. After all this was the outcome of year long hard work. However, he
was astonished to hear when sales & marketing manager said, I don’t think we can launch this in current
form. This requires number of changes. Neo wanted to say that we built based on requirements given by
your department only but preferred not to argue with senior managers.
This was really frustrating for Neo and soon he heard that he would be moved to a new assignment and
someone else will take over his current project.
In the evening deeply frustrated Neo was sitting in a pub, where he met his old friend Kane who was
working as agile coach. He told him the whole story and asked what he could have done better.
Kane: I will tell you my views but first tell me how do you define a successful Project?
Neo: Delivering the scope, on time and within budget.
Kane: That means if everything would have gone as per plan till your business demo, you would call that
as success. Even though your customer didn’t see value in the final product, can you really call the
project as really successful?
Neo: I never thought this way. Anyways, do you think I could have done anything differently? I did
identify the right risks and was constantly monitoring the risks.
Kane: Identifying risk & monitoring the risk is fine but doing something concrete about it early makes

the real difference.
Neo: I didn’t get you.
Kane: Let’s take help of our scientist friend who has developed a time machine to go back in past. We
can fix the things just like movie “19 Again” or “Action Replay”. When we go back in time, you just need
to do as I advise. Agreed?
Action Replay
With help of time machine Neo & Kane went back the time when Neo was just appointed as project
manager for Accounting product Enhancement project. Considering the amount of uncertainty involved,
Kane advised Neo to do development in small iteration of 4 weeks, while each of the iteration will
deliver some useful working functionality. Iteration duration will be timeboxed i.e. fixed duration though
scope delivered in iteration can vary.
Neo explained CEO John about iterative development approach. John said – “I don’t care what approach
you follow. As long as I get the project delivered in time and value from money, I don’t care. Tell me
what do you need from me?”
Neo requested CEO John to appoint someone in business community as single point of contact –
someone who has right amount of knowledge, authority and influence so that he can help in getting
support from all key business stakeholders. John appointed one of his senior managers, Peter as product
owner.
Feature Priority List
With help of Peter, Neo was quickly able to put the various proposed features in priority order. They
called this list as “product backlog”. Kane asked him to just pick top few for further detailing rather than
focusing on everything. Within a week Neo & team was able to break these top priority features into
smaller chunks so that each small feature was a fairly independent piece of functionality and was just
few days’ worth development effort.
Planning Meeting
A planning meeting was called out, in which Peter, Neo and rest of team, walked through the Product
Backlog i.e. list of features. Together they put the features into a prioritized list using three factors:
a. What generates most business value
b. What is the right logical sequence - Technical, functional interdependencies
c. What is the risk involved.
Kane’s logic was to pick High Value and High risk items first so that not only they could deliver business
value early but also reduce the risk early on.
Once they had the prioritized list of features, it was time for team to decide what they could deliver in
first iteration. Team committed to deliver 5 features. Rest of the time of the meeting, team spent in
coming up with initial list of tasks needed.
Iteration
Neo had an urge to put together a plan with key SDLC phases and deliverables defined. He also wanted
to use work authorization system for task assignment and status tracking. However, Kane said – “It’s
only 4 weeks long iteration so there is no point of creating a detailed plan for that. There is no need of
work authorization system as well. We can just have a simple task board / excel in which team members

can add tasks and sign-up for tasks. Your focus should be on ensuring collaboration and removing
blockers.”
Kane was also against the idea of heavy document deliverables. His focus was more on verbal
discussions with business and then documenting what was really necessary. He also suggested
colocation (if feasible) and daily morning 15 minutes huddle for better collaboration.
Problem
As it happened last time, testing turned out to be more complicated than team members thought. Team
realized that they wouldn’t be able to delivery everything in time. The options were:-
1) Postpone the iteration review i.e. demo meeting.
2) Deliver everything but few features would be untested.
3) Drop at least one of the features completely and deliver rest.
However, Kane was against the idea of even discussing first two options with product owner. He said,
we have to deliver on time and working software means thoroughly tested code. Understanding the
situation Product owner agreed to defer one of the features to next iteration.
Review/Demo Meeting
The room was full as everyone was quite excited to see working software so early in the project. Team
presented completed features (working software) to product owner and other business stakeholders. In
general, everyone liked the product. There were few suggestions. Neo duly noted all the suggestions
and demands for new features etc. All of these got added to the backlog (prioritized list of features).
Further Iterations
While working on first iteration, domain expert was spending some time in further detailing of other top
priority features in product backlog. There was a separate meeting held to reflect back at iteration
experiences and learnings.
Next iteration planning was easy as everyone had better idea about what they can commit. Also some of
the inefficiencies were addressed based on lesson learnt (retrospective) meeting after 1st
iteration. After
3rd
iteration, team was quite comfortable in predicting what they can deliver in each iteration, end date,
end budget etc.
Business was quite happy with the flexibility to make scope changes and had more confidence after
seeing working product. Early feedback and close customer collaboration helped in delivering faster and
better. After five iterations, customers got most of key features developed so it was decided to drop the
stop the project and launch the product in market. Overall, it all turned out to be major success.

Exercise 1: What were the key changes in approach which made the project successful second time
and how?
Answer:
1) Working software after each iteration - Helped in getting early feedback. After seeing
working software customer can better formulate requirement and might come up with
more ideas to maximize business value.
2) Flexibility for the customer to drive the sequence of delivery based on business value and
get high value changes delivered even late.
3) Better risk management – most of the uncertainties were known early and there was
opportunity to adapt.
4) Team empowerment and buy in from team – Realistic commitments, Empowered team is
more motivated & productive. Project manager can focus on removing blockers rather than
activity/task management.
5) Single point of contact from business helped in scope prioritization and decision making.
6) By delivering in the sequence of business value, business realized the optimum value much
ahead and ROI was improved.
7) Multiple levels of planning – Initial planning and then planning for each and every iteration.
Instead of plan, focus here is on planning.
8) Early start as there was no need to wait for complete requirements.
Exercise 2: Tick what all the Agile Menifesto values and principles were touched in this case study.
Answer:
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable
software. [Iterative development was chosen delivering working software in each iteration.]
2. Welcome changing requirements, even late in development. Agile processes harness change for
the customer's competitive advantage. [In review / Demo meeting changes in backlog were
welcome.]
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale. [Team worked in 4 weeks long iterations.]
4. Build projects around motivated individuals. Give them the environment and support they need,
and trust them to get the job done.[No work authorization system, concept of team signing up
for the work]
5. Working software is the primary measure of progress. [When there was a problem the option
chosen was to deliver less but deliver working software]
6. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts
its behavior accordingly. [There is mention of lesson learnt meeting after 1st
iteration.]

Introduction to Agile Development

Recommandé

Recommandé

Contenu connexe

Plus de Whizlabs

Plus de Whizlabs (15)

Dernier

Dernier (20)

Introduction to Agile Development