An appreciative inquiry into an exceptionally

successful Agile project

Summary

Appreciative inquiry is a philosophy which believes that a team which inquires

into problems or difficult situations will keep finding more of the same but an
organization which tries to appreciate what is best in itself will discover more
and more of what is good. Appreciative Inquiry utilizes a cycle of 4 processes
• Discover: Identify the processes that work well
• Dream: Envision the processes that would work well in the future
• Design: Plan the new processes
• Deliver: Implement the proposed design

Our current project is a large, long development exercise with 40 people

working on it for about 10 months. It has been highly successful, it was
delivered on time, on budget and everyone starting from the client CIO to the
end users of the system have been very satisfied with the project. When we
conducted an Appreciative inquiry into our project, we
were genuinely surprised at the number of small things we had done
differently from our regular project and we were convinced that the impact of
all those added together to create the exceptional results.

In this experience report we will share the outputs of the 'discover' phase of
our appreciative inquiry into the project. We hope that looking at what worked
in our context will give you food for thought to apply to your own projects.

Session Type
60 min, Talk

Structure of the Session

Below is the outline of the structure of the session. It also provides some
examples of processes that worked for us, which we will describe in this
session.

Share the project context

• Size
o 40 people at peak
• Duration/Timelines
o 12 months
• Technology
o .Net
• Business Context
o Call Centre application for a Railway ticket retailer in the UK
o Critical to meet the timelines and the budget for 2009
• Results
o Share some of the quotes from the clients
Describe the processes that worked well

• Inception
o Covered NFRs in good detail
o Visited the live Call Centre before the inception
o Had access to the old call centre app 2-3 weeks before inception
o Took detailed notes for each and every session during the
inception
 Use of mindmaps to structure the notes
 Keeping daily notes
• Release planning
o Ensuring that stories were created for handling NFRs. These
stories were estimated and made part of the release
plan.(Performance was a "Feature")
o Focused on getting the simple booking flow working end to
end as soon as possible to ensure that we eliminate risk.
o This was a technique followed across features (get something end
to end working rather than complete every bit and piece in the
feature - the stories were split, prioritized and played that way)
• Development
o Easy and uncomplicated machine setup.
o Task list for each story
• Testing
o QAs never lagged in terms of story completion.
o Focus on getting stories QA complete (including automation)
in the same iteration
o Running regression tests daily (well, almost)
o Retry logic handled to circumvent regression environment timing
issues - enabled to get Regression coverage to 95+%, only genuine
failures caught after that - no false negatives
• Business Analysis
o QA and BA wall along with usual story wall.
 BA wall enabled BA to track how stories are moving in
analysis pipeline and whether we will have enough work
coming up for devs
 Also helped in eliciting dev help in analysing technical /
service stories
 BAs could sign up for story analysis and pick up WIP story if
one of the BAs is not in
 QAs when have bandwidth could look at future stories that
are complete on BA wall and start writing test scenarios for
those stories
• Project Management and Execution
o Built a working prototype very early using HTMLs, JS and dummy
aspxs.
 Impact: Devs could focus purely on building the core domain
functionality. Most of the work for linking pages together,
interraction patterns etc was already done.
  Impact: We could show the prototype the the end users (Call
centre agents in Mumbai) and get very valueable feedback
on usability. It was easy to incorporate any changes in the
prototype and in the actual app going forward since it was
done so early.
 Impact: It also eased our conversations with the SMEs
about upcoming functionality. We could enhance the
prototype with
o Devs working as BA/QA without ceremony around it
 Impact: Ensured that the gap between Dev complete and
QA comeplete never increased
 Impact: Ensured better analysis of the stories since BAs
could pair with the Devs for technical analysis whenever
needed
o Use of mindmaps instead of ppt for showcases
 Impact: We were able to get the showcases mindmaps
created very quickly
 Impact: Audience liked the fact that the mindmaps allowed
them to view the agenda at all times
 Impact: We were able to capture comments
o Story kickoffs instead of IPM tasking
• User Experience/ UI Design
o Aditya(Usability Expert) was involved right from the begining of the
project.
 Impact: We were able to focus on usability and user
interaction patterns early on. The development team, along
with the customer team, reached a concensus on how
different kind of user interractions would be handled in the
app.
o Visited the actual Call centre to get feedback on HTML prototype
early to get feedback from actual users
 Impact: We gathered a lot of context about what the current
app does. What are the important features etc via the call
centre visits
o Standardized on the behavior of our UI elements pretty early (eg.
How will all panels collapse/expand, how will panels respond to
keyboard shortcuts, how will our search results be shown
o Had Ramakant (HTML/CSS expert) on the team right from the
beginning.
 Impact: Devs did not need to spend too much time in getting
HTML/CSS correct. This was very efficient, we were able to
create UI much quicker
o Praveen (Java Script expert) joined the team early on. He is a UI
specialist with a lot of experience in Java Script.
 Impact: This meant the other devs did not get stuck too
much with Java Script issues
o Javascript unit testing.
 Impact: It made the javascript code to be clean as we had to
write tests.
• Deployment
o Automation of deployment (one click install) across QA, UAT
environments
 Impact: Deployment to any QA and UAT was easy and
quick. Could be done by anyone on the team.
• People/Communication
o Lightweight retros using the Learning Matrix (Feedback wall)
 put your points up as soon as they happen, lesser chances
of points being forgotten
 Impact: The discussions used to take just 15-20 min - much
faster
o Impact: We were able to do the retros very frequently and
consistently
o Team played picnic/board games at outings
 Team outings were not about just having dinner/lunch
 Impact: Bonded the team together
o Team room isolated from the rest of the office
 The Call Centre team was located in a big sized room, this
helped the team members to bond with each other and share
some lighter moments at work that helped in keeping the
motivation high
 This helped in instant communication for certain day-to-day
activities like environment issues, smoke and build failures
etc.
 Allowed the team to chill out, play music etc. without
worrying about whether they were disturbing the other teams

Take questions from the audience

Key Learnings and Outcomes

• Gain insights into some of the practices that worked for a large
successful project
• Pick up some new ideas to try out in your project
• Learn how some of the practices evolved over a period of time in our
project. The evolution path maybe as interesting to learn about as the
actual practice

Speaker Profiles

Chirag Doshi
Chirag has over 8 years of experience in software development in various
roles developer, analyst, architect and agile coach. In the last 4.5 years of his
work with ThoughtWorks he has been part of agile teams of different sizes
ranging from 2 to almost 200.

Dhaval Doshi
Dhaval has over 2 years of experience in software development. He has been
working as a Developer in various big and small Agile projects in
ThoughtWorks. He has developed in Java, Ruby and C#. He has submitted a
couple of papers for the IEEE magazine and likes to conduct guest lectures at
Engineering colleges.

We propose to present this at both the Mumbai and Bangalore conferences.