How We Became The Pongo Team

Marco Dani, Alberico Gualfetti, Luigi Mengoni Unirel S.R.L. Via Volturno 12 50019 Sesto (FI), Italy +39 055 340773
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. 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 2

Francesco Cirillo XPLabs S.R.L. Via dei Castagni 22 01015 Sutri (VT), Italy +39 0761 659037
“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 following a strategy of specialization. territory areas"

• 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

Sign up to vote on this title
UsefulNot useful