How We Became The Pongo Team
Marco Dani, Alberico Gualfetti, Luigi Mengoni
Unirel S.R.L.
Via Volturno 12
50019 Sesto F.no (FI), Italy
+39 055 340773
pongo@unirel.com
ABSTRACT
Process improvement has always been an extremely
complex undertaking. Among other things, it requires that
the people involved have a well developed capacity for
observation: only they can truly understand their problems
and they are the ones best suited to resolve these problems.
The experience of discovering Extreme Programming (XP)
values is central to the process improvement of a software
development team. By enhancing observation skills and
encouraging a willingness to change, team members
increase self-awareness, thus enabling them to make
decisions to improve. The Pongo team tells of their
journey, in the hopes that this will lead other teams to
become active participants in the process of change.
Keywords
Process improvement, XP values, team experience.
1 INTRODUCTION
Today's markets require software which is capable of being
adapted in real time to the continually changing
requirements of business. The Unirel company had for
some time expressed an interest in increasing effectiveness
by producing software "good, fast, and cheap." The goal
was to reach Level III, and ultimately Level IV of the
Capability Maturity Model (CMM). In June 2001 a
collaborative effort began with Francesco Cirillo, mentor at
XPLabs, to create the conditions which would allow
developers to work concretely toward these objectives.
What we initially approached as a course on the application
of good engineering practices became instead a journey that
led us to an understanding of why our past projects failed,
and then to discover the values we wished to adopt and
apply.
2 THE WAY WE WERE: WHY OUR PROJECTS
FAILED
Our experience began with Francesco posing the question,
“Are we or are we not a team?” to the ten developers who
signed on for the programme. After several weekly
sessions, only four answered this question affirmatively and
continued the mentoring experience.
Our next step was to reflect on the causes of project failure.
The study of traditional software development processes
and the failure of certain projects recorded in the literature
were the starting point for the creation of a map entitled
Francesco Cirillo
XPLabs S.R.L.
Via dei Castagni 22
01015 Sutri (VT), Italy
+39 0761 659037
francesco.cirillo@xplabs.com
“Why Our Projects Fail.” We had, in fact, failed with our
last project, yet we considered ourselves technically
talented. What we needed was a bit of formality, perhaps in
the form of a Unified Modeling Language (UML) diagram
or two. This would have solved our problem - or so we
believed. At first we thought that making the map would be
a simple exercise, though for the most part pointless. In the
end, we discovered things that we didn't expect in terms of
clarity and relevance. The map became more and more
reflective of our experience, and helped us recognize our
needs. As the map took shape, we came to realize that a
series of factors were contributing to our lack of success. In
summary, from the map the following points emerged:
• We do not have a direct relationship with the client.
• We don't know how to accurately interpret the requests of
our clients.
• We do gold plating.
• The client never provides acceptance tests.
• We have no way of determining the progress of our
projects.
• We don't know how to estimate.
• The client adds functionalities, but we can’t adapt our
planning.
• We don't know how to test. (“All the tests run, so why
doesn’t the system work?”)
• We don’t have a suite of automatized tests, so we spend
hours testing manually.
• We spend too much time fixing bugs.
• Management assigns us "project territory areas"
following a strategy of specialization.
• Developers are considered mere executors, with little
involvement or sense of responsibility – someone else
makes all the design decisions.
• We write programs alone.
• Developers write code with their own formatting, style
(naming of methods, classes, etc.), editors, tools
(makefile or shell script), compiler, even with a personal
way to make objects work.
• We have difficulties understanding other people’s code.
• We feel unproductive competition between developers.
• We suffer from the "up till now it was perfect, then
someone fiddled with it" syndrome.
• We don't share common values.
• “Just make it work” is the unspoken rule.
• The design of our software is rigid and immobile.
• We have to rethink, reorganize, rewrite parts of the
system when work is in progress.
• We don't know how to handle complexity - it increases
when it should decrease.
• The final phase of our projects is a “blood bath” –
accumulated delays cause stress, demotivation, and
frustration in everyone involved.
• We can not choose the projects we like.
• Work is not enjoyable.
There is no need to describe our shock and fatigue, in
seeing these truths black on white. Undoubtedly, the
resulting sensation was unpleasant, but who was to blame
but ourselves? We were the ones doing the writing. Though
analyzing ourselves was not something we enjoyed, we
needed to do it to move on.
Gradually, as we studied traditional software development
processes, we were encouraged by Francesco to ask
ourselves which one was most similar to ours. We realized
that our scanty ability to estimate, to analyze, or to design,
together with the fact that planning was determined by the
client, led us to choose the "value" of speed when facing
projects. The immediate consequences were the implicit
selection of a "code and fix" model that resulted in
underestimating risks, accumulating duplication in the
code, intense bug fixing, and increasing complexity. We
concluded that the more we strove for speed, the more
slowly we went, to the point of inevitable "throw away."
We certainly didn't expect to follow a strict iterative
incremental model, but at least a waterfall!
The more we learned and understood about software
engineering issues, the more a sort of shared consciousness
of our mistakes grew.
3 HOW WE ARRIVED AT XP VALUES: CHANGE
Understanding that the reason for our failure was the choice
of the “speed engine” was only the first step. We had come
to the point of no return. Now all team members recognized
how we were working and the mistakes we were making.
No one would accept continuing to work that way. We
asked ourselves what other values could substitute speed.
What engine?
One morning at Unirel, Francesco told us that our room
was too messy to work in; we needed to tidy up. As we
were doing so, we realized that most of the clutter was
concentrated on the bookcase, which hadn't been sorted out
for months. There was an accumulation of things used by
various people, some having nothing to do with the team.
More importantly there were things that had become
permanent fixtures, and other objects - belonging to the
gurus of the company - that were considered sacred.
Beyond that, we thought that it would take forever to
straighten it all out. Following Francesco's advice: we all
pitched in to reorganize the bookcase without a
coordinator, without first dividing up work areas, but by
talking to one another about every problem and every
decision, by doing simple things like setting out books two
by two to classify them, and finding the courage to touch
the "untouchable." Surprisingly, in a short time not only
was the bookcase tidied up, but there was much more space
available than what we had imagined when we started out.
Spontaneous, sudden order had emerged; things that didn't
belong to the team were removed, and most importantly
every member of the team knew the position of any given
object.
Another enlightening experience was the "challenge"
between two pairs of programmers involving how to make
a given mind map communicative. The first pair wanted to
proceed in an evolutionary way, "refactoring" and rewriting
the map again and again from scratch, though without
altering the contents. The second pair, instead, considered it
"a waste of time" to work by taking little steps, ripping up
maps and doing them over; they were convinced they could
draw the final map straight away, adding new items if the
need arose. That way, they thought they could save time on
useless rewrites. Surprisingly, it was actually the
"evolutionist" pair who delivered in less time: small steps
guided simple moves and countless rewrites and revamps
had produced a map that was so communicative that it won
unanimous approval from the whole team.
We sensed that through these experiences we had found a
way to work that was good, fast and cheap, and we could
still have fun! In processing feedback from team members,
what emerged was that our experiences had many common
elements: we had worked on the verge of chaos (at times
even creating disorder on purpose so as to be more free to
put things back in order); we had tidied up with simple
strategies, communicating continually, giving and receiving
constant feedback; we had shown courage in asking for
help when we needed it, and in touching the untouchable.
It was only natural to ask ourselves if these same values
could be applied to software development (at that time we
didn't know that behind these aspects were XP values - that
is, communication, simplicity, courage, and feedback; in
fact, at that point we didn’t even know what XP was). If, in
abstract terms, we could intuit analogies between the
experiences we had with Francesco and the development of
software (for example, working on the verge of chaos in
order to combat complexity), in concrete terms, we did not
know how the values that had emerged could fit into
programming.
Most of the team members felt growing confidence that
these values could constitute the new engine, capable of
enabling us to work successfully. However, one person
expressed opinions indicating that in critical conditions he
could possibly move in the opposite direction of the rest of
the team (e.g. allow throw away). This fact could have
constituted a future risk for the team. After painful internal
debate, he eventually decided to leave the programme. This
was a difficult moment, yet also a defining one; it
confirmed our motivation. Now we were truly a team.
In our search for a team name we liked the idea of linking it
to the quality that we felt was most necessary to support
change, namely, malleability. This characteristic evoked
our childhood experience of Play-doh, Pongo in Italian,
which was great fun and at the same time stimulated our
creativity. That's why our team chose the name Pongo. The
change had begun within ourselves.
At this point we - the Pongo team - decided to follow an
evolutionary development method. In January 2002, we
began a six-month full-immersion programme with
Francesco at XPLabs. Our objective was to maintain and
develop values on one hand, and on the other to experience
how through XP we could apply our new values engine to
programming in order to improve team process. A
description of the continual series of discoveries we made
at the center would be beyond the scope of this paper.
Suffice to say we learned how to find and use the tools to
improve our process.
4 THE WAY WE ARE NOW: RESULTS
Back in Florence, we immediately began applying our
discoveries to our ongoing activities. Our objective was to
develop software good, fast and cheap while working in an
enjoyable way. Here is a summary of the results we have
achieved so far:
• Teamwork. We don't work alone anymore, we share work
space. We learned that working together encourages
communication of differing viewpoints, and therefore
creates conditions for collaborative problem solving.
Working on a team stimulates creativity and favors the
emergence of ideas that enable the team to better regulate
complexity. Competition between developers is
eliminated, while respect for fellow team members is
enhanced. Work has become more enjoyable.
• Design. We let the code be our guide, rather than
imposing structures a priori. That way, code stays simple
and modifiable.
• Testing. We have revolutionized our approach to testing,
specifically:
• We have come to understand the purpose of tests
("doing analysis means finding the tests"), and how to
use them as a development tool. In other words, tests
now guide code writing. Result: we introduce fewer
bugs into the system, and design arises directly from
tests.
• Clients now provide acceptance tests.
• Through test-first we obtain a significant "coverage"
for code which allows us to work with more
confidence.
• The process of code writing is no longer a chore; in
fact, test-driven development is great fun.
• Writing tests lets new ideas emerge, both on how to
build applicative code and on new tests that were not
originally foreseen.
• We use tests as an instrument of knowledge: if we have
to use third party software or understand how a system
works, rather than read documentation, we write tests.
This activity may seem an expensive waste, but it
eliminates insecurity and ambiguity, since we know
exactly what the software does or does not do.
Moreover, a test that works is a tangible result.
• System-oriented approach. The team shares a system that
is continually nurtured and gradually enriched as we
work on different projects. High quality is maintained
and the enrichment of the system gives us speed and
economy.
• Pomodoro. Our work day is divided into half hour time
units by means of the "pomodoro," a tomato-shaped
kitchen timer [1]. We set the pomodoro for 25 minutes,
take a short break and then get back to work again. Every
four pomodoros we take a longer break (about 15
minutes). Over time we have come to realize the
importance of these breaks - they allow us to maintain
rhythm and enhance creativity. Using the pomodoro, we
"box" time; the effect of this is that the passing of time is
not as frightening. In fact, time is no longer an enemy,
but an ally, in the sense that it stimulates us to get things
done. Thanks to the pomodoro we have been able to
improve our estimates, since estimating brief units of
time is simple.
• Feedback. We are more aware of how we are working
due to feedback. In fact, the first pomodoro of the day is
dedicated to feedback, and this allows us to improve our
process day by day. We have learned to observe
ourselves. If something is not right we work to improve
it.
• Pair rotations. During our time at XPLabs pair rotations
were very frequent, to the point of one rotation every
pomodoro. Doing so made sharing our perception of the
progress of the project, or adopting new tools or
practices, or finding collaborative solutions to complex
problems, a natural part of the process. At first glance,
frequent rotations might seem to slow down progress, but
even today our experience is that overall we get an
increase in speed.
• Focus. Interruptions are eliminated (e.g. checking emails
or answering the phone), and this, combined with the use
of the pomodoro, allows us to work with more focus and
rhythm. The effect is that at the end of the day we
developers may be more tired, but not as stressed as we
would have been using "old" work methods. We have
accomplished more and produced concrete results. In
addition, we have acquired and are still developing skills
that go beyond specific programming abilities, for
example: learning techniques, proactive text reading,
keyboarding. As a result we can concentrate more on
what we are doing, make fewer errors, and enhance our
creativity.
• Metrics. We keep on working to improve our metrics. To
this end, we are creating, in collaboration with XPLabs, a
tracking and planning tool that will enable us, among
other things, to obtain Return On Investment (ROI)
directly from metrics.
• Communicative code. Having understood the importance
of "code that speaks," together we have sought to find
"our" way of making code speak. This, along with
"collective ownership" and the use of tests, has
eliminated the fear of touching other team members'
code. In addition, a better understanding of what a certain
snippet of code does has diminished the fear of accepting
change and also of rewriting a given portion of code from
scratch.
• Communicative tools. To communicate, we use mind
maps, wikis, metaphors (even colorful ones). Through
these tools, we are better able to communicate with other
team members (developers and clients).
• Development tools. We have gained familiarity with
environments and development tools which allow us to
be more effective, streamlining programming, testing,
refactoring, and integration. Also, sharing said
instruments aids in communication, and therefore
enhances the effectiveness of the entire team.
• Facing challenges. Fear of change, or facing new
activities, is no longer a cause for anxiety, but becomes
positive tension which moves us to act. When a situation
becomes difficult, we stop. (In the past we would have
kept going.) This allows us to be more lucid.
• Working hours. Two out of eight working hours a day are
dedicated to learning, so when the work day is through,
we don't feel the need to study or work (what's more, we
know that this would not be effective after such an
intense day), and we have more time to dedicate to the
family, and to other interests. Systematic overtime is
eliminated.
• Responsibility. We work with greater responsibility in
terms of the success of the project: while before a
developer was assigned the task of making some thing
work in some way, now he or she assumes responsibility,
along with the rest of the team, for delivering value to the
client. Work, as a result, is more motivating and
gratifying.
Maintaining these results requires continual effort on our
part. Often times we fail in doing so. This is human. We
perceive the danger in losing sight of our values, and we
immediately ask ourselves how to get them back in focus.
At times, this involves a great deal of effort, but we feel
that the delay in our reaction is continually diminishing.
Inter-Library Loans Project
The Pongo team worked on the Inter-Library Loans project
from September 2002 to January 2003. Here are some
considerations on the results obtained:
• Good. The team increased the quality of software
developed. Beyond the positive effects regarding quality,
communication with the client was also dealt with
successfully. In our experience, shifting from a monthly
delivery rate to a weekly one has significantly improved
communication and has enabled the team to receive more
feedback.
• Fast. The team is faster in delivery and has decreased
estimating error, which, from an average of 245% in the
first three stories, has dropped to 110% in the last three.
Though this percentage is still high we were able to cut
our errors in half, and we know how to reduce them even
further.
• Cheap. The team has introduced no bugs, reducing costs
related to bug detection to zero.
• Fun. The team works in a more enjoyable way, thanks to
attention to the work environment and work tools, the
focus on product quality, and the elimination of overtime.
5 CONCLUSION
We’ve been guided to the threshold and we’ve gone
through the door; now we are on our way. On our journey
we have encountered difficult obstacles as well as pleasant
surprises, and we know that there are more of both still to
come. We’ve evaluated our achievements up to this point
and concluded that the results we have obtained have made
the struggle worthwhile. We have changed both
professionally and personally. All of this is very exciting!
We are committed to keep growing and improving. We are
strongly motivated to go on.
REFERENCES
1. Cirillo, F. The Pomodoro Paper. Available soon on-line
at http://www.xplabs.com