PMI Agile Community of Practice

Equipping PMI Members with Agile Skills and Knowledge
Experience Report : Agile Software Development Case Study

Dave Rose 2012 All rights reserved
PMI Agile Community of Practice
The Agile Community of Practice focuses on delivering knowledge and providing a virtual networking forum for agile
practitioners. This includes anyone interested in, working in, or impacted by developments in the collection of good
practices, principles and techniques in agile project management.
The Community
Enables agile practitioners to contribute and share their knowledge with the global PMI community.
Explores the relationship between agile principles and practices.
Communicates how agile may differ from, or complement the teachings within, PMI's A Guide to the Project
Management Body of Knowledge (PMBOK Guide).
Experience Report Abstract
This Experience Report provides detail of the authors experiences when hired by an eProcurement company to
manage the complete replacement of their Software as a Service (SaaS) document exchange system. The system is
the core platform for the companys entire suite of services provided to their customers.
The existing system had outgrown its original design and the business stakeholders needed it to be replaced to meet
the expectations of their rapidly growing service portfolio. A decision was taken to manage the project using pure
Agile methodology. The author, like many PM's, had dabbled in Agile but had never embraced the full philosophy.
In this report the author describes those tenets where he was a bit skeptical, details from his experiences of seeing
how a pure Agile project could be evolved and delivered. This report follows the progress from start-up through the
first major release and illustrates where the team struggled and had successes. It outlines what worked and where
we there were challenges and what the author learnt from this journey.

Please do visit the PMI Agile Community of Practice site http://agile.vc.pmi.org to raise questions and discuss this
report.

The Starting Point
The Project
The customers current system had reached its end of life and needed replacing from the ground up. This system
was the company's lifeblood; all of its services were delivered from it. The project was high profile and
considered critical to supporting the company's future. Not only was it a software development project but we
also had to plan the transition of 6,000 customers to the new system.
My Agile Background
When I accepted the project management role, I, like many PMs had dabbled in Agile, embracing this concept or
that one; basically cherry picking what I thought would work best for any particular project. For this white paper I
wanted to start by creating a baseline of my knowledge and Agile perceptions, then compare this at the end of
the project to what worked, what didnt, and what I learned. For the baseline, I used the Agile manifesto and
rated myself. The tilde indicates partial usage, the X meant I avoided it, and the check mark, I already embraced
it.
Principles My
Experience
Welcome changing requirements, even late in development. Agile processes harness
change for the customer's competitive advantage.
X
Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.
~
Business people and developers must work together daily throughout the project.
~
Build projects around motivated individuals.
~
Give them the environment and support they need, and trust them to get the job done.
~
Working software is the primary measure of progress.
~
Agile processes promote sustainable development. The sponsors, developers, and users
should be able to maintain a constant pace indefinitely.
~
Continuous attention to technical excellence and good design enhances agility.
~
Simplicity--the art of maximizing the amount of work not done--is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.
X
At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behaviour accordingly.
~
The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
~

Three things of note from this table:
a) I, like many PMs, wanted to control scope change keep a firm hand on it so it doesnt interfere with
delivery.
b) I preferred consulting with senior team members and assigning tasks jointly; self-directed task selection
worried me.
c) On the other hand I did believe in simplicity; the KISS principle kept many a project on track.

The Environment
Agile was new to the company. This project and the Agile methodology was being inserted into an existing
system of processes and behaviours that often acted in conflict with our project:
Product managers did not want to compete to have their initiatives developed. They all had their own
development teams to carry out their wishes. The big challenge here was that all of these products were
delivered from one system; one shared software base. This led to:
o Major code merge challenges at deployment time
o Rework due to poor communication between teams
o Inconsistent development standards
Their project management methodology was mostly Waterfall with a smattering of Agile. This meant:
o Business Analysts gather requirements and document them as stories
o Developers create functionality based on the requirements
o Testing was performed by a QA group that was independent of the development team. They had
to be scheduled to test, and often werent available until sometimes, weeks later. This lead to
many issues as the developers had moved onto other projects while waiting; code management,
having to refresh their memory on what had been developed, etc.

Project Initiation
As mentioned in the abstract, the project did not start in an Agile manner. Before any development took place, the
executive wanted to know the scope, budget and timelines. The company could not use much of its existing
resources so new resources would need to be brought in. For this phase, 2 BAs and 2 project managers were hired.
They:
Met with the business units and created requirements for the new system
Estimated resources and budget to deliver
Created charters, budgets, schedules
Did a formal presentation to steering committee & executive for approval
This phase lasted 2.5 months and generated copious volumes of documentation.

Research & Proof of Concept Phase
Once the project was approved, we went into a 5 month research and PoC phase. This was necessary due to a lot of
new technology being employed, where we had little or no experience. While we believed all of these new
technologies would work together as expected, we needed to be sure. To that extent we:
Did a small Proof of Concept project using the new GUI tools
Did a vertical spike of all the technologies to prove them out

As the PoC was progressing satisfactorily, we began the planning for the first development phase. This is where
wed go Agile in a serious way. As a team, we created high-level functional stories, adding estimate points to them,
and then meet with the executive to determine business priorities and what could be expected when. We had a rift in
initial expectations on when the first phase could be completed. The development team felt that based on their
estimates, the delivery dates wanted by the executive could not be achieved. Since all we had were gross estimates
at that time, it was agreed that wed do 3 iterations and then determine our actual velocity. Based on this we would
set our milestone dates using more empirical data.

Stories were organized and prioritized into iterations to take us to the first major milestone, a production release that
would allow us to prove out the back-end with a pilot customer.

We recruited a top-notch team, co-locating them in one large space. This includes BAs, Developers, QA and the
PM. Key business stakeholders and infrastructure were close at hand.

Many of us had limited Agile experience. Jonathan Rasmusson, a local Agile guru, was available and looking to get
back into development. He agreed to join our team as technical and Agile practice lead. He took us through his Agile
boot camp and we incorporated our learnings into our project.

One of these learnings was the Inception Deck. My take on the Inception Deck is its a user friendly charter. It has
much the same content as a charter but it is more versatile on communicating expectations both upward and
downward. It really helps the team understand the big picture of why you are doing the project; what benefit it has to
the business; as well as things that directly impact them; how the team will work together, schedule, etc. You can
even select slides based on the audience.

Release Planning
Releases were based on specific functionality that would enable either new customer onboarding or existing
customer transitioning.

Our Release Planning involved:

Breaking the major milestones into releases
Determining iterations for the release
Selecting relevant stories
Prioritizing stories for the first iteration

We went with 2-week iterations. This was sufficiently long enough to get useful functionality developed, but short
enough to stay highly focused.

Development Iterations
Two avenues of work go on during an iteration:
We start with the Preparation Iteration. BAs and senior developers flesh out the selected stories add
requirements, mock-ups, test scenarios, etc.
Once the stories are ready for development, they move into a Development Iteration. This iteration includes
development & functional testing. We want stories tested immediately after development so the code is still
fresh in the developers mind.
While the developers work on the stories in this iteration, The BAs work on the next iterations stories.
For this process to be successful, you must have the right mix of BAs, developers, and QA.

In more detail the iterations look something like this:

Preparation Iteration

Day 1 Review high level stories as a team
Review included BAs, Sr Devs & PM
Pick stories for iteration
Do a walk-through to ensure all know what is expected
Review estimates based on discussion

Day 2 7 Iteration Prep
BAs get detailed requirements into stories
Sr Devs review any technical design impacts

Day 8 Final Review
Use the same team as for Day 1
BAs review stories in detail
Any omissions are noted
Stories re-estimated to ensure nothing has significantly changed

Day 9-10
Final story preparation
QA scenarios added

Development Iteration

Day (-1) Team Review
A retrospective meeting occurs to review what was accomplished during the last iteration, what happened
that was notable, (both positive and negative), and the stories to be developed in the next iteration.

Day 1 Development Starts
Stories are placed on the Cork Kanban Board ready for development. Developers pick up stories based on
their interest / knowledge / expertise

Day 2 8 Development Phase
Continue picking up stories and completing their development. QA develops test cases and tests stories as
they are completed.

Day 9 10 QA Clean-up
QA finishes testing while Developers fix bugs. Developers look at stories for next iteration

Ideal Development Cycle
If you can achieve the following workflow, you have created a sustainable development stream. Everyone is working
at an optimum rate and you can achieve the ability to deliver new functionality into Production after every iteration.

Yeah but!
It is challenging to do. Even if you have the right team balance of BAs, developers, and QA, you can have break-ins
from Production issues, vacations, illness and so on. Then you can get something more like this! This is what
happened to us:

This chart shows the impact of your QA team being distracted by Production issues for the entire first iteration. They
dont get started until the second, and not only that we are short QA resources. The Developers are done creating
functionality on schedule but QA is way behind them. Now you have a forced lull where you cant create new
functionality until QA catches up. Why? You cant keep adding untested code to the system because QA never
catches up and you can never release.
Team Communication
SCRUMS held every day to review what each team member did the day before, what they will be doing
that day and if they have any issues
Communication Wall We used all the walls around our collocated space to help with communication
Kanban Board has lanes for each phase of a storys development

Release Plan displays primary functionality in the release, the iteration schedule, and even
includes the expected business benefit. It reminds team members every day what we are doing
and why.

Customer Migration As customers moved onto the new system, we listed them on the wall. It
reinforced that this was a working system with customers using it daily
What has been done Every iteration, every story card was put up on the wall. We had hundreds
and hundreds. This showed what we had accomplished to the team as well as anyone who
wandered back into the team space.

Retrospectives
What have we done?
Demos developers showed what they did that iteration
Described functionality that could not be demoed was discussed
What is next?
Review the upcoming stories
What went well?
Acknowledge improvements
What can we approve?
Develop solutions as a team

Project Management in an Agile World
Agile does not mean that the project requires no management. Even the best-intentioned team can lose direction
and drift dangerously off course without a project manager reviewing progress constantly. To ensure a steady course
I used the following tools:
SCRUMs listen to daily reports, identify any follow up actions (technical challenges, progress).
Was imbedded in the team area keep your ears open for issues that may need your attention
Weekly status reports reporting up to management and stakeholders
Monthly performance reports budget & deliverable tracking & variance


Agile Actually Employed
So how well did we do? How much of the Agile manifesto did we implement?

Principles Our Reality
Welcome changing requirements, even late in
development. Agile processes harness change
for the customer's competitive advantage.
We only locked down the current iteration. Next iteration was
left open until ready to develop
Deliver working software frequently, from a couple of weeks to a
couple of months, with a preference to the shorter timescale.
Releases varied in length but monthly was preferred. Had
challenges getting them into Prod.
Business people and developers must work together daily
throughout the project.
Limited access to Bus Reps. BAs imbedded in the team.
They met weekly with the business
Build projects around motivated individuals. Had a highly skilled, senior team with mix of employees &
contractors
Give them the environment and support they need, and trust
them to get the job done.
All were co-located. Added pairing stations. Gave them
significant freedom to interpret requirements.
Working software is the primary measure of progress. True but other groups still wanted their traditional deliverables
CBT creation required locked down screens weeks before
the release
Agile processes promote sustainable development. The
sponsors, developers, and users should be able to maintain a
constant pace indefinitely.
Once a rhythm is attained, maintain it.
We struggled with this due to external impacts formal QA,
CBTs, existing production deployment processes
Continuous attention to technical excellence and good design
enhances agility.
Have the best team you can afford.
Simplicity--the art of maximizing the amount of work not done--is
essential.
Focus on delivering just what brings immediate business
value.
The best architectures, requirements, and designs emerge from
self-organizing teams.
This does work team dug out technical issues and addressed
them on the fly.
At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behaviour accordingly.
Retrospectives every 2 weeks.
The most efficient and effective method of conveying
information to and within a development team is face-to-face
conversation.
Focused on conversations over documentation. Team was co-
located.

Successes and Challenges
Successes Challenges / Opportunities
Team Functioning - self organizing, professional, really owned
the responsibility of developing a high quality system
Misaligned resourcing not enough QA to keep up with
demands; caused large drag on entire team
Focus on best return on time spent just in time requirements,
build only what is absolutely required
QA Effectiveness formal QA process caused the largest
amount of frustration & ineffectiveness; good example of a
non-agile approach causing friction.
Delivery got right stuff into Production Executive alignment
Agility change to meet companys priorities Detailed requirements gathering at beginning
Time for refactoring
An evolving database design will work
Handled key technology change midcourse replaced
Silverlight with HTML

What Did I learn?
Every project generates learnings. Since I had limited Agile experience before this project I learned a lot! Here are a
few of my key learnings:
1. Give up control! Your team does not need to be spoon-fed.
2. Increase your trust that your team will do the right things
3. You can still monitor and manage but it is in a different way you can let the team be self-organizing but
monitor progress closely. Include the team in any management decisions so they really own the resulting
actions.
4. Going Agile is not like flicking a light switch; it is an evolution.
5. There will be clashes with other groups that operate in more traditional ways. You must find a way to bridge
those gaps in methods and expectations. Generally, excellent communication plus joint decision making
where cross team impacts are felt reduce tension and improve the relationship.
6. Learn, adjust, learn some more.

About the Author
Dave Rose has been a Project Manager for over 20 years. He started managing the implementation of turnkey
medical office systems in 1990 and has progressed to managing software development and infrastructure projects in
a wide range of businesses and environments. Dave has developed expertise in managing the development of web-
based systems including SaaS and portal based solutions. His PM approach has evolved from waterfall through
hybrid RUP, Scrum, and Agile techniques to the focused Agile methodology employed on this project. He has a BSc
Computer Science from the University of Manitoba and his PMP designation from PMI.
Copyright
This material has been reproduced with the permission of the copyright owner. Unauthorized publication of this
material is strictly prohibited. For permission to re-produce this material, please contact any listed author.

PMI Agile Community of Practice

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PMI Agile Community of Practice

Uploaded by

Copyright:

Available Formats

Equipping PMI Members with Agile Skills and Knowledge

Experience Report : Agile Software Development Case Study

You might also like