Warning: Unknown: Unable to allocate memory for pool. in Unknown on line 0 Warning: require(): Unable to allocate memory for pool. in /var/www/html/slideee/www/index.php on line 8 Warning: require(): Unable to allocate memory for pool. in /var/www/html/slideee/www/index.php on line 9 Warning: require_once(): Unable to allocate memory for pool. in /var/www/html/slideee/www/index.php on line 11 Warning: include_once(): Unable to allocate memory for pool. in /var/www/html/slideee/libs/Smarty.class.php on line 89 Warning: include_once(): Unable to allocate memory for pool. in /var/www/html/slideee/libs/Smarty.class.php on line 90 Warning: include_once(): Unable to allocate memory for pool. in /var/www/html/slideee/libs/Smarty.class.php on line 91 Warning: include_once(): Unable to allocate memory for pool. in /var/www/html/slideee/libs/Smarty.class.php on line 92 Warning: include_once(): Unable to allocate memory for pool. in /var/www/html/slideee/libs/Smarty.class.php on line 93 Warning: include_once(): Unable to allocate memory for pool. in /var/www/html/slideee/libs/Smarty.class.php on line 94 Warning: include_once(): Unable to allocate memory for pool. in /var/www/html/slideee/libs/Smarty.class.php on line 95 Warning: require_once(): Unable to allocate memory for pool. in /var/www/html/slideee/www/index.php on line 12 Warning: require_once(): Unable to allocate memory for pool. in /var/www/html/slideee/libs/funkce.php on line 2 Warning: require_once(): Unable to allocate memory for pool. in /var/www/html/slideee/www/index.php on line 13 Warning: require_once(): Unable to allocate memory for pool. in /var/www/html/slideee/libs/DbSlideWeb.php on line 2 Warning: require_once(): Unable to allocate memory for pool. in /var/www/html/slideee/libs/DbSlide.php on line 2 Warning: require(): Unable to allocate memory for pool. in /var/www/html/slideee/libs/LoggedPDO.php on line 2 Warning: require_once(): Unable to allocate memory for pool. in /var/www/html/slideee/libs/DbSlideWeb.php on line 3 Warning: include(): Unable to allocate memory for pool. in /var/www/html/slideee/www/index.php on line 14 Warning: require_once(): Unable to allocate memory for pool. in /var/www/html/slideee/libs/ErrorHandler/includer.php on line 6 One XP Experience: Introducing Agile (XP) Software Development into a Culture that is Willing but not Ready, SlideSearchEngine.com

One XP Experience: Introducing Agile (XP) Software Development into a Culture that is Willing but not Ready

50 %
50 %
Information about One XP Experience: Introducing Agile (XP) Software Development into a...

Published on December 19, 2007

Author: leip

Source: slideshare.net


Paper presented at CASCON 2004

One XP Experience: Introducing Agile (XP) Software De- velopment into a Culture that is Willing but not Ready F. Grossman1 J. Bergin1 D. Leip2 S. Merritt1 O. Gotel1 Pace University1 IBM2 Computer Science & Information Systems Hawthorne Lab – Corp. Webmaster Team {grossman, berginf, smerritt, ogotel} @ pace.edu Leip @ us.ibm.com tions. This has worked well in many situations but Abstract less well in others. In particular, it is not suffi- ciently responsive to changing requirements or to The main question to be asked is quot;Does Extreme situations in which the ultimate clients have diffi- Programming (XP) make sense as a development culty stating stable requirements with precision. methodology in a diverse, multidisciplinary web The latter can arise when the business needs are development environment? This environment volatile and also when the technology opportuni- includes diverse, and perhaps, distributed teams ties are not well understood by the quot;customer.quot; requiring close coordination with multidiscipli- Another difficulty is that the development team nary skills -- information architecture, visual de- can be isolated from the ultimate client of the sys- sign, XML, Java and others. The potential is to tem by a long process in which strategies are set make the development process more responsive to and information architects and visual designers users' needs and changing business requirements. (and others) contribute their work to the overall This could have high impact on outcomes of the project. The implication is that a question on re- development process, decreasing cost, decreasing quirements from the software developers must time to deployment, and increasing user satisfac- filter back to the decision makers through many tion. The challenges are to adapt and reconcile the other people and groups, and the answer then fil- corporate and the agile culture processes and ters forward through the work of those groups, methodologies without seriously compromising resulting in long delays. During these delays it is either. We will discuss our experience from con- difficult for the development team to be produc- ception into implementation of XP through the tive on the project unless they make (likely incor- first release that incorporates several iteration rect) assumptions about what is required. cycles. We will discuss the positive and negative forces and how they have or have not been re- The above unhappy scenario is not unique to solved to date. IBM’s development team, actually, and has been observed in many organizations. A response to 1 Introduction this has been the development of agile method- ologies that tend to shorten the distance between Corporate software development teams, such as decision-makers and developers and to increase IBM’s own internal web development teams, have flexibility. Whereas the traditional development traditionally used heavyweight waterfall method- methodology envisions gathering all the require- ologies for developing most web-based applica- ments at once before other work begins, agile development works by gathering requirements Copyright © 2004 Dr. Fred Grossman, Dr. Joseph Ber- quot;just in time.quot; The development team works gin, and IBM Corp. Permission to copy is granted pro- closely with a designated quot;customerquot; who makes vided the original copyright notice is reproduced in all business decisions and who specifies important copies made.

features of the growing application determined by changing business requirements. This could have the immediate needs prioritized in business-value high impact on outcomes of the development order. The quot;customerquot; in effect steers the team process, decreasing cost, decreasing time to mar- toward the goal over the life of the project, and ket, and increasing user satisfaction. the developers realize the current features/needs The challenges are to adapt and reconcile the cor- on short iterative cycles. Every few weeks the porate and the agile culture processes and meth- customer has business value delivered by the pro- odologies without seriously compromising either. ject team. The cost of change in this scenario is These involve recognizing and understanding exactly the cost of adding a new feature, making • who the XP quot;Customerquot; really is change manageable. The result is that it much • test-first development is unnatural to several easier to hit a target that could not easily be seen at the beginning of the project. of the disciplines • pairing with a limited staff and diverse staff- Extreme Programming (XP) is one example of discipline sets such an agile methodology. It is a high discipline • XP assumes that all developers have more or process in which a number of synergistic practices less the same kind of skills, e.g., Java pro- bring business value to the customer in short (two gramming, but in a multidisciplinary team week) iterations with deployable software coming this is not the case at a slightly slower (four to six weeks) rate. At • the interface between the agile and the non- any time, the business stakeholder has a good idea of the current state of the project and also the cost agile aspects of the project and the organiza- of continuing. Normally the cost per feature rises tion • team members work on multiple projects over the life of a project while the value per fea- ture declines (build the high value things first). which affects maintaining sustainable pace When the curves cross, it is time to quit. One im- and scheduling portant overriding feature of an XP project is that • different practices/culture for different parts iteration and release schedules never slip, though of the team -- the 12 XP practices may not be some of the tasks may not be completed (feature natural or even valid for different sorts of slip). The consequence is everyone really knows practitioners both the value of the current quot;buildquot; and the cost • distance , or more precisely lack of strong of continuing. communication, is expensive Others have investigated using XP or other agile We will discuss our experience from conception methods as the official corporate software devel- into implementation of XP through the first re- opment methodology [11]. This paper discusses lease that incorporates several iteration cycles. early experience of applying XP to a single, albeit We will discuss the positive and negative forces significant, project in the ibm.com domain that and how they were or were not resolved. has characteristics that may not make it particu- larly suited to their traditional (waterfall) devel- 2 XP and Web Projects opment methodology. For this project it would be difficult to specify requirements and design Web development projects require the skills from choices well in advance, necessitating many ques- such disciplines as information architects, visual tions back and forth. With the traditional method- designers, programmers (XML, HTML, Java), ology, the ensuing time lags would cause prob- and user-centered design specialists. They each lems. have their own established practices and bring different perspectives to the web project devel- The main question to be asked is quot;Does XP make opment. [12] sense as a development methodology in the Will XP work in a culture where ibm.com environment?quot; This environment in- • traditional development methodology is wa- cludes distributed teams and close coordination terfall with information architects, visual designers and • there are a large number of stakeholders in others. The potential is to make the development diverse organizational roles and responsibili- process more responsive to users' needs and 2

• ties (management distributed across inde- Small releases and short iterations pendent authorities) • Metaphor • diverse skills (information architects, visual • Simple design designers, XML, HTML and Java program- • Testing mers) require a multidisciplinary team with • Refactoring continuous synchronization and integration • Pair programming • This paper explores the early decisions about the Collective ownership introduction of XP into the ibm.com development • Continuous integration environment and some of the early experience • 40-hour week (sustainable pace) (successes and problems). We examine the inter- • action of organizational culture and agile devel- On-site customer • opment methodology, and to what extent organ- Coding standards izational and methodology changes are necessary to successfully employ an agile web development In the next sections we will discuss which aspects process. of these practices were easily adopted and worked from the beginning, and which were more diffi- Traditionally this organization operates in a cult to inculcate. We also incorporated some addi- staged waterfall scheme in which information tional practices, e.g., daily stand-up meetings and architects and strategy specialists work with real retrospectives after each iteration cycle. customers to develop a complete set of require- 2.2 Introducing XP to a cus- ments for a project. This specification is refined tomer: a representative customer through a process of showing alternatives to real users. This specification then goes to a team of is willing visual designers who realize the designs of the Stakeholder managers representing strategy and information architects. At this point the require- design, that we thought might be the “customer”, ments and external design work is finished, but it were given a short overview of XP from a cus- is only then that the programmers begin the task tomer perspective (XP in an Hour). As it turned of implementing the functionality and actually out, only one of these stakeholder representatives creating web pages and the application structure. (design) would be a quot;customerquot; for the XP pro- In the past, the programming team thought of the ject. information architects and visual designers as their customer; but this is a long way from the real Each agreed to select a member of their group to customer. It became obvious that a question from be a potential onsite customer. These two cus- the programmers on the team about requirements tomer representatives would attend the training would potentially take weeks to be answered, and sessions for the team. As it turned out, neither of a change in the real requirements of the real cus- these selected customer representatives became tomers would only filter to the programming team real customers on the XP team. More will be said after weeks of work. Therefore there was no way about this later. to be agile solely within the software developers’ domain. Instead, a decision was made to include 3 Training the development everyone with essential skills in the development team: the developers are will- of the project in a quot;whole teamquot; approach. This puts the team close to the real customer, but also ing implies that the skills of the team members are not interchangeable. The Webmaster development team wanted to try XP. They had read some of the XP literature [1, 2, 12] and believed that it might work well in their 2.1 XP Practices development environment. The team was primar- Kent Beck in his seminal work [1] specified 12 ily composed of two programmer skill groups -- XP practices: XML/HTML and Java. The initial plan was to • The Planning Game select an initial XP project that was not mission 3

critical and whose requirements and design speci- nally considered to be directed at programmers. fications could not be completely determined in There are a number of available exercises that are advance of development efforts. used to train diverse groups quickly in XP prac- tices. One of the most common is the Extreme Hour [8] in which people draw pictures at the Two of the authors (Bergin and Grossman) were direction of a quot;customerquot; who writes stories speci- brought in to train the team and to act as coaches fying requirements for the picture. While it is for the initial XP project. The entire Webmaster quick, it isn't very deep. Two of the authors of this development team (including the distance mem- paper have developed a more elaborate quot;gamequot; bers) was assembled for two half days and one [4] that takes about a day, including a retrospec- full day in between. This amounted to about 24 tive, and includes most of the XP practices. Its people including programmers, strategists, infor- important features are: mation architects, visual designers and user- centered specialists. • it is accessible to anyone -- developers, cus- tomers, managers Note that this training session was held one month • it gives a basic understanding of the agile XP after the quot;XP in an Hourquot; presentation to the an- practices and how they fit together ticipated customer. • it expects the participants will make many The training methodology used was the Extreme mistakes in following the rules (XP practices) Construction Game [4]. This took the full day. that cause them problems in the game, pro- The two half days were used for an introduction viding grist for the important follow up retro- to XP (XP in an Hour) and two retrospectives [6]. spective. The first retrospective was to look at the way web projects have been developed in the past by this The basic idea of Extreme Construction should be group. They were asked to envision a composite familiar to anyone who has been to kindergarten. project that was representative of all the projects The facilitators gather a large collection of simple that they had worked on. This was held prior to construction materials, from paper and glue to the Extreme Construction Game. As a result of modeling clay, sticks, scissors, and the like. Some this retrospective of prior project development of the participants are chosen to be quot;customersquot; projects, most of what was determined to be in and they come up with an idea for something to need of improvement should be resolved using be built with the available materials. Teams of agile development practices. The second retro- about 10 participants work with a customer. In spective was held on the second half day follow- our game session, one customer decided to spec- ing the day of the Extreme Construction Game, ify a quot;playgroundquot; and the other a quot;castlequot; com- and was a review of the game and the XP process plete with dragon. The customers then write sto- overall as they understood it. ries for features of their project. The rest of the team estimates the stories and computes a quot;veloc- After this training session, the team members ityquot; as in XP. The customer then chooses impor- went back to their normal project work. It would tant stories from those estimated up to the given be two months before the actual project work velocity and the team then begins a short (20-30 would begin. During this two-month period, addi- minute) iteration. We enforced pairing and test- tional quot;XP in an Hourquot; sessions were held with first development for the construction phase, and various management personnel from the stake- emphasized the importance of communication holder divisions of the organization. with the customer. 3.1 Extreme Construction Game The facilitators watch what is going on and coach Once it was decided that the team included people the process, but mostly prepare for a retrospective with many diverse skills, it became necessary to in which the team tries to discuss what should initially train everyone in XP practices. Tradition- have happened, what did happen, and how the ally an XP team includes a few non-programmers, process could have been improved. The partici- e.g., the customer, but this was an extreme case as pants came away thinking that they had a good programmers were actually in the minority. On idea of XP, but in fact it was quite shallow and the other hand, XP and its practices were origi- 4

needed much reinforcement. In particular, we tomerquot; representatives in attendance revealed that have not yet determined a manner in which to this was probably not a valid assumption, at least reinforce the concept of test-first development in not if we wanted to get the maximum benefit from anything but a superficial way. an agile approach. The roles of these quot;customerquot; representatives were strategy and information Many mistakes were made, of course, that caused architecture, and in the waterfall approach to pro- the construction to be less efficient and effective ject development, they did play the role of the than it could have been: customer. What became obvious was that these • assuming (wrongly) that the developers roles (or at least the information architect role) are knew what the customer wanted rather actually part of the developer group and not the than asking the onsite customer customer group since they play essential roles in • stories were not well written by the cus- the creation of delivered artefacts for the project. tomer Thus it was necessary to push the role boundary • turning design into a big bottleneck up between the developer and the customer back. front. The question was, how far. Throughout we have • building infrastructure that wasn't needed attempted to enforce the quot;whole teamquot; concept in which everyone considers herself to be a quot;devel- as the project evolved • pairing was abandoned when time was operquot; who embraces the XP values: communica- tion, simplicity, feedback, and courage. running out for an iteration • estimates were (not very good) guess- 4.2 Who is the XP customer? work Initially, it was assumed that the XP quot;customerquot; An additional problem is that many of the people was to be the Webmaster's traditional customer, that we trained in this way were not part of the i.e., those who gave the specifications to the pro- real project team, including both of the real cus- grammers. These typically were the information tomer representatives. architects and the visual designers. However as 4 The composition of the XP stated previously, these roles were now incorpo- team rated as developers on the XP team. So then who is to play the XP customer role? As in any XP project, the team consists of devel- opers, customer representative(s), tracker(s), The obvious place to start was with those who coach(es) and manager (big boss). What makes would normally provide the specifications for web our team different is that the developers and cus- development projects. Initially managers from tomers come from diverse and distinct organiza- these groups (strategy, information architecture tional areas and with diverse non-overlapping and and visual design) were presented with an over- non-shared skill sets. This presents both a chal- view of the XP methodology focussing on the lenge and an opportunity. quot;customerquot; role. The quot;customerquot; is willing. The initial multidisciplinary team was composed of developers (information architect, visual de- 5 Thinking agile in a highly signer, XML & Java programmers), trackers (pro- disciplined, structured and ject manager for webmaster programmers and project manager for the design group), coaches, distributed culture and a customer entity. When a software development project is done 4.1 Who are the XP developers in utilizing an agile methodology such as XP, the a web development project? agile thinking is focussed on getting the code written, tested and accepted by the customer -- At the onset of discussions about doing an XP pair programming, small releases, simple design, project, both the Webmaster and the XP test first, refactoring, collective ownership, con- trainer/coaches assumed that the XP developers tinuous integration. It is usually clear who the would be the Webmaster programmers developers are and who the customer is. The agile (XML/HTML and Java). However, after the train- practices fit nicely into the organization, which as ing session, discussions with the original quot;cus- 5

a result of doing an agile development has be- gives them the ability to do this and have a robust come agile. But note that for most agile projects, product reducing duplicate effort. the primary development task is programming. The project has a fixed delivery date and a strong Here this is not the case, with information archi- sense of what high-level functionality and “de- tects, especially, taking a key creative role. sign” must be in place in order to deploy. 7 The XP practices in the Now consider a scenario in which the developers come from different parts of the organization with context of the culture diverse kinds of skills and different management reporting lines, and where the boundary between The project has been agile since its inception. the XP developer and the XP customer is blurred There is more to XP then the practices. In fact, because they come from the same group. In our Kent Beck does not list them in his seminal work, web development environment, it is clear that the Extreme Programming Explained [1], until the XML and Java programmers are developers. reader is into the last two-thirds of the text. While Their management reporting lines are clear and the focus of bringing XP into a project tends to consistent with traditional software development stress the practices, they are really instantiations organizations. of the four values of XP – communication, sim- plicity, feedback and courage. Robinson and However, the multidisciplinary team also includes Sharp [10] talk about the XP culture and the sig- developers who are information architects and nificance of the XP practices, and present empiri- visual designers. They have a management report- cal evidence that the XP practices create and sup- ing line separate and distinct from the program- port a community in which the XP values are sus- mers. Yet they work on the same customer stories tainable. with the programmers and participate in the esti- mation process and velocity determinations that It is for that reason that we intended to introduce drive the planning game. What's more they are and use all twelve practices immediately. How- still operating in a quot;waterfall-likequot; culture in ever, this did not actually occur. The following which large amounts of information architecture describes which practices fit into the existing cul- and design are expected to take place before a set ture well and were successfully used, and which of XP stories can be written to develop what they are requiring more effort and adaptation. have architected and designed. As Kent Beck says, quot;The biggest barrier to the success of an XP It should be noted that the project is going very project is [business] culture [1]quot;. well. The customer is happy with the functionality In the multidisciplinary quot;whole teamquot; approach that they are getting and the developers are happy that we are following, when the customer writes a with what they are able to deliver. This is happen- story, all the developers (information architects, ing in spite of the fact that the practices are not visual designers, XML programmers and Java yet well installed into the culture, and some of the programmers) will consider it for customer ques- most important practices – pairing, test-first de- tions, estimation and tasking. velopment, common code ownership, and con- tinuous integration – have not been used very 6 The Project much in the early iterations. The coaches have explained to the team that this is not unusual. The Against standard wisdom of not picking a mission power of the synergistic effect of using all the critical project as the first pilot XP project, we practices together is only going to become impor- did, in fact, pick an important project. We did this tant as the project size and complexity begin to because the business stakeholders and the Web- grow. XP has also allowed the project to progress master did not think that it would be possible to further in a short time than previous methodolo- complete the project in the desired schedule using gies would have allowed. a traditional waterfall model. Requirements are assumed to change. They sub- 7.1 The practices that worked mit regularly to user testing, and then make adap- We continuously reinforced the notion that while tations. This is done often. In the traditional mode many of the practices might seem to have value as they built prototypes (not fully functional). XP 6

a stand-alone method, the power of the XP ap- One special aspect of this project needs to be proach is they are synergistic and are designed to mentioned. The staged nature of the process has work together. The acceptance and observance of not disappeared completely. The information ar- the practices is an evolutionary process. What we chitects must do their work before the visual de- describe here are some observations of what signers do their tasks, and both must complete worked and why. before the programmers (XML and Java) can fin- ish. We win in two ways here, however. We learned that usually each set of skills can begin 7.1.1 The Planning Game (story writ- before the one it depends upon completes, provid- ing and prioritizing) ing quite a lot of overlap. Second, the short itera- tions have kept this staging simple and quick, The Planning Game is an activity that develops without requiring management, and yet able to and depends upon a sense of common purpose, respond quickly to changes. responsibility and understanding. A large amount of discussion takes place among the “whole 7.1.3 Metaphor team”, which includes the customer, and a lot of “what ifs” are considered. In fact it is the only Since the project is a redevelopment of an existing time when our entire team is together in one web site, everyone on the team understands the place. This is important because the customer is essence of the project. Additionally there are de- represented by two organizational entities that are sign mock-ups and prototypes produced by the working together to produce a single end product strategy, design and site architecture groups, as (web site), but have different areas of responsibil- well as preliminary feedback from various sets of ity. Each customer entity contributes different users. stories and has their own story priorities. This has not been a problem, and the two customer entities 7.1.4 Simple design work and coordinate very well. If anything, this has been overdone. The rule quot;do The first planning game produced about 40 stories the simplest thing that could possibly workquot; was and took more than a full day. Subsequent ses- overused a bit at the beginning. Eventually every- sions have been taking one half day or less. The one learned that you do what you know you have project is using two-week iteration cycles and the to do and you do it well, not skimping on the es- customer has not had any difficulty in prioritizing sentials. So the developers are building a quality and selecting stories for each iteration. product without overbuilding it or anticipating the customer too much. There is a bit of disconnect 7.1.2 Small releases and short itera- between the customer who is used to simpler pro- tions jects, and the team who knows what it requires to It was easy to convince everyone to use a two- build a stable, scalable product, but this has been week iteration cycle, and all have been pleased relatively minor. The team is building what is with the results. In one case, we tried a longer needed today, keeping flexible for changes that three-week iteration due to holiday considera- will occur tomorrow. tions, and the results were not as satisfactory. This solidified the resolve to work in small bits. Unfor- 7.1.5 40-hour week (sustainable pace) tunately we were not initially able to convince the customer to think in terms of releases, and as a XP is not just about the quality of code, but it also result they were unhappy at the end of an iteration about the quality of life. It is not just about work- when they didn't have any new business value. ing a 40-hour week; the goal is for each developer This pushed them back toward the proper path. to work at a comfortable pace so that they can The first release is usually an anomaly anyway, so leave at the end of the day without feeling not much has been lost. Most of the stories written stressed and exhausted, and then be fresh when are sized at around two ideal developer days, and they return the next day. Each team member this has made a good fit with a two-week itera- should be in control of setting their divide be- tion. A story larger than six ideal days won't fit tween work and home, and to be able to move into an iteration unless it is broken into tasks, and between the two comfortably. This also gives this forces the team to keep the work units small. business value to the business stakeholders since 7

the developers are able to do their best work at all 7.1.7 Coding standards times, making far fewer errors than when stressed This has not been formalized, but is about to be. and tired. Most of the team has worked closely in the past, We have included this practice in our success though not in pairing. Styles are similar and peo- column because the overall atmosphere in the XP ple seem comfortable with the style used. As part room is calm and relaxed. There have been some of our push to increase pairing and test-first de- instances where because of the initial shortage of velopment, we are also trying to get a statement of developers, some found it necessary to shoulder the coding standard that everyone will agree to. more of the load than is normally expected in an XP project. But even in these cases, a sustainable 7.1.8 Additional practices not in the pace was maintained. Once the team expanded, this was no longer an issue. original twelve Stand-up meetings We now have a thermometer drawn on a white The stand-up is a short (15 minutes) daily meeting board that is kept up to date measuring the quot;tem- of the whole onsite team. This includes the pro- peraturequot; of the iteration, i.e., the risk of non- grammers, tracker, coach, manager and customer. completion of the current tasks. It has only gone Missing are the design group members – informa- high once. Everyone can see at a glance the cur- tion architects, visual designers and their cus- rent state. The daily stand-up meeting ends with tomer representative. They are located at a differ- resetting the thermometer. ent site, and their absence is offset by telephone conversations when necessary. While we believe It isn't always easy to ensure that people aren't that their presence on site would be beneficial, it overworked in this environment since everyone has not yet been shown to be problematic. has some responsibility for other projects. The coaches are vigilant about this, and one of the During these meetings each team member shares programmers has expressed his thanks for provid- experiences and issues. Everyone is kept up to ing him some space in which to do his best work date on the progress. Issues such as infrastructure, by relieving outside pressures. tools, XP practices are discussed as necessary. Protracted discussions are continued after the The sustainable pace was reinforced because of meeting with the appropriate parties as necessary. the high degree of communication among the The stand-up meetings enhance the sense of team both in the Planning Game and during the community and help to further the XP culture development cycles. We see the beginning of a development for the team. self-managing and self-organizing community with a clear acceptance of a sense of shared re- Retrospective sponsibility. As mentioned elsewhere, we did two quot;retrospec- tivesquot; as part of the training process. One was to 7.1.6 On-site customer set a baseline against which this project could later be measured for success, and the other to Even though the XP customer is representing sev- solidify the Extreme Construction learning. We eral different stakeholder groups, there is one cus- have also scheduled one day per iteration to use tomer representative on the team who is always for the Planning Game and for iteration retrospec- available on site. While this has been problematic tives. The half-day for retrospectives also pro- in many XP projects, for our project this has vides a bit of schedule slippage, when necessary, worked extremely well. The customer quickly in which case the retrospective is forgone for that learned how to steer the project and how to write iteration. This has been infrequently needed, and appropriate XP stories. Developers regularly ap- the frequent mini-retrospectives have been very proached the customer for answers to questions valuable in pointing out the effects of not main- about a story. The customer also has not had any taining the practices when that has occurred. It inhibitions about approaching the developer for has been a great way to reinforce learning. This information about status and to volunteer addi- has also been a time during which the XP values tional or clarifying information about a story. 8

have been embraced and reinforced – communica- here, but, again, it seems to be coming together tion, feedback and courage. after a few iterations. Pair coaching It has also taken a while for the team to become Since this is a first for the organization, two ex- comfortable with a velocity that is a small fraction ternal coaches (among the authors) are part of the of available time. They now recognize how much team. One or both are available nearly every day: they do that is not associated with the task at both for Planning Game and retrospectives. We hand, so this is improving also. However, the have fallen into a practice quite naturally that is team initially did not have sufficient time avail- much like pair programming. One of us will take able to estimate new stories as they were written, the lead in coaching and will say most of what is making the Planning Game sessions longer than needed at the time. The other watches the process, they should have been. This too is improving, and thinks more strategically about what is occur- especially as the customer has been willing to say ring and makes comments as necessary. This that getting estimates was more important than combining of the micro and macro views of the making progress in at least one situation. The situation is very valuable. team is developing a rhythm, also, which helps. Another issue of concern is that the customer did 7.2 The practices with issues not want to set release dates. They were content to As was previously stated, we intended to intro- view each iteration as a release. This was prob- duce and use all twelve practices immediately. lematic because it permitted the customer to im- However, this did not actually occur. The follow- pose an XP-violating pressure on the developers ing describes which practices did not fit well into to move at the customer’s pace rather than the the existing culture or for which the culture was developer’s pace. We have since convinced the not ready without more effort and adaptation. customer as to the wisdom of thinking in terms of multiple iteration release cycles. This should im- 7.2.1 Planning game (estimating, ve- prove the situation. locity) 7.2.2 Test-first development and ac- While we have faithfully practiced the planning ceptance testing game, with help from the coaches, some aspects have been less than smoothly done. The team has This has been the most difficult aspect and leaves had a hard time picking up the concept of quot;ideal us at some risk. We started the project with a team timequot; for purposes of estimating, instead lapsing only partially trained (either that or never get quite frequently to estimating in elapsed time. The started) and without all infrastructure in place. customer has also done this. This is especially While the programmers have written unit tests, difficult here since most of the staff has responsi- these are usually done after the fact. Until re- bilities for several projects, and one person's typi- cently, however, there has been no platform on cal day is quite different from another's. This is which to share the tests, so each programmer has improving, but it has taken time and effort. We a few tests that can't effectively be run by others. are also starting to decouple the idea of a story This is being addressed, and a solid testing archi- point and an ideal developer day, making it more tecture for unit tests is being established. abstract, which makes it easier to think about. This may sound backwards, but it is true as the Similarly, we have had, and continue to have, team develops its skill. problems in automating acceptance tests. This is partly due to the nature of the project, but also due There also has been difficulty in determining a to both unfamiliarity with the technique and a lack velocity each period. The concept of quot;yesterday's of appropriate testing infrastructure. A new fix- weather,quot; using the story points actually com- ture [3] for fitnesse/fit was developed by one of pleted in the previous iteration as the basis of ve- the coaches to aid in this. locity in the next, has not worked well. Things have been too volatile. People coming and going, Most important in this difficulty, however, is the and stories vastly different in kind have hurt us lack of experience with test-first development and 9

some scepticism about it. The programmers are was minimal pairing by the Java programmers not yet convinced that testing speeds you up, when the part time programmers were available to rather than slows you down. We recently had a pair with the full time programmer. training session in which this was addressed, both We have stressed the value and importance of intellectually, and with a hands-on demonstration. pairing all along knowing that it would be diffi- It remains in need of improvement. cult to do under the circumstances. Since the Java 7.2.3 Refactoring programmer resources were increased, pairing has increased to the extent that pairing has become The team has not yet done much refactoring since less of an issue. In this organization, pairing is we are still in the early stages of development, used to satisfy the code review process require- and there hasn't been much need yet. On the other ment. There is already a sense that this could hand, the current lack of sufficient tests will make prove to be a more effective and efficient review this especially difficult when it occurs, since the process than the traditional code walkthrough tests are not in place to tell you that you have bro- sessions. ken something when you inevitably must refactor. 7.2.5 Continuous integration 7.2.4 Pair programming Since we started without a common infrastructure The developer team consists of members with (everyone was working on their own local work- different skills (information architects, visual de- station), this has been a difficulty. A test server signers, XML/HTML and Java programmers) and has now been established on which to maintain as such, they are not interchangeable. Initially the integrated system, and the automated tests, but there were two full-time XML/HTML program- the continuing lack of tests hurts us here again. mers, one full-time Java programmer, two one- The customer sees and approves the completed third-time Java programmers, two information individual stories, but it isn't until late in the itera- architects and one visual designer. After the third tion that he sees things working together. Every- two-week iteration, two more full-time Java pro- one agrees that this needs work. grammers were added and one of the part-time Java programmers became available full time. 7.2.6 Collective ownership This has not really been much of a difficulty, ex- There was a strong desire to pair from the begin- cept that initially we had only one full-time Java ning. As an example of this, Govind Nishar, one programmer, so he became the quot;ownerquot; of the of the Java programmers, read the following quo- code. He has no issues with collective ownership; tation from Homer’s Iliad at one of the daily it is just that he knows more about the code than stand-up meetings. It was discussed briefly and anyone else. The pairing difficulties mentioned everyone understood and appreciated its import. above have contributed to this, and as that im- proves, it is expected that collective code owner- …If some other man would go along with ship will be successfully in place. In general, as me there would be more comfort in it, with most of these issues, the developers are will- and greater confidence. When two go to- ing. gether, one of them at least looks for- ward to see what is best; a man by him- 8 Management Support self, though he be careful, still has less Many large companies such as IBM, have in- mind in him than two, and his wits have vested heavily into highly disciplined, well docu- less weight. Homer, The Iliad, Book mented software engineering practices that can be Ten, lines 222-226 measured against the Software Engineering Insti- tute’s Capability Maturity Model [9] or the even What has made pairing problematic has been the newer Capability Maturity Model Integration lack of bodies with which to pair. Even though (CMMI) [5]. These models offer much to comfort there were three and a fraction programmers management, and also comfort customers in working, they had different skill sets and were commercial engagements. Most of the agile soft- working on different aspects of the development - ware development practices, such as XP, are ori- - XML, HTML pages and Java servlets. There 10

ented in a different direction. As a result, indi- of their top talent is to be flexible around certain viduals who have bought into the philosophy of work-life trade-offs, such as an employee who these models might be faced with a greater chal- wants to follow a spouse to another location. lenge to see the value of a methodology such as Where outsourced application development ser- XP. vices are used it is also unlikely that the develop- ment team and customer will be co-located. Lack Even so, executive support has been good for pi- of communication (not necessarily distance) is loting the methodology. Management in the IT expensive in XP. While there has been some work organization and the business or customer organi- done on distributed extreme programming [7] zation are optimistic, and are hopeful that XP can [13], effective methods for distributed pair pro- help us become more agile in meeting the needs gramming, sharing XP user stories, dealing with of the business. off-site customers, trackers or coaches, or con- ducting daily stand-up meetings, or release plan- Some of the nomenclature used in the XP world ning meetings, are not widely understood or used. however can clash with the business world. For example, in XP, planning is done through some- 9.2 Managing User Stories thing known as “the Planning Game”. While it is Many people in the IT industry are not nearly as possible to sell corporate executives on the merits experienced or good at applying discipline to of XP, such as lower cost of change, improved managing paper documents as they are electronic schedule tracking, frequent deliverables, etc., no- documents. Story cards are prone to being lost menclature such as “the Planning Game” makes inside a reference book, taken offsite inadver- the sell harder. In our case, after observing some tently, or ending up on the floor to be swept up by management wince when hearing the term in the cleaning folks. While there are some inherent some early management briefings, we started advantages to using the cards, such as the limited simply referring to it as “the Planning Process”, amount of text that can fit onto the card, most of which everyone seemed perfectly comfortable those advantages can be replicated in a spread- with. Terms such as “Game” tri

Add a comment