Agile Modeling Logo

AM Throughout the XP Lifecycle

To explain how the practices of AM can be applied on an XP I will work through a portion of the SWA Online Case Study and show how modeling is used throughout the XP lifecycle. XP has a project lifecycle? Yes. Figure 1 depicts a high-level view of the XP project lifecycle, modified from (Wells, 2001) to indicate a mapping of Beck's (2000) project phases (the Death phase, not shown, would follow maintenance). Although the term phase may bring connotations of waterfall development the fact is that phases can occur iteratively, something that is apparent in Figure 1 by the fact that it is possible to move back and forth between the Planning, Iterate to Release, and Productionizing phases. Phases aren't necessarily long - the Planning phase may only take several hours for example. Furthermore, XP teams typically don't think of themselves as working in phases, they just think of themselves as working.

Having said this it makes it easier to think about the development effort one phase at a time so let's examine each one in turn:

  1. Exploration Phase
  2. Planning Phase
  3. Iterations to Release Phase
  4. Productionizing Phase
  5. Maintenance Phase

Figure 1. The XP project lifecycle.

XP project lifecycle

1. Exploration Phase

The first phase that an XP project experiences is the Exploration phase (Beck, 2000), encompassing the initial requirements modeling and initial architectural modeling aspects of the agile software development lifecycle. This phase includes development of the architectural spike and the development of the initial user stories. From a requirements point of view he suggests that you require enough material in the user stories to make a first good release and the developers should be sufficiently confident that they can't estimate any better without actually implementing the system. Every project has a scope, something that is typically based on a collection of initial requirements for your system. Although the XP lifecycle presented in Figure 1 does not explicitly include a specific scope definition task it implies one with user stories being an input into release planning. User stories are a primary driver of the XP methodology - they provide high-level requirements for your system and are the critical input into your planning process. The implication is that you need a collection of user stories, anywhere from a handful to several dozen, to get your XP project started.

However, there's a potential problem. When a project begins a software approach may not have been chosen for it, this is often a decision that is made once a better understanding of the scope of the effort is understood and people have been identified to the work on the project because as Cockburn (2002) suggests you want to choose the process that best aligns with the nature of your project, team, and organizational culture. The implication is that if the decision hasn't yet been made to take an XP approach then the people performing the IRUF effort may choose to create something other than user stories - shall statements, features, and use cases are common options. If this is your situation you will need to convert these artifacts into user stories. Luckily shall statements and features are very similar to user stories so that should be straightforward and because use cases typically have greater scope than user stories the easiest approach is to simply declare them to be user stories and then go about splitting them as you normally would to reduce them to a manageable size.

For example, assume that your original IRUF efforts resulted in the use case diagram of Figure 2 and you have decided to take an XP approach to development. Therefore you need to translate these use cases into a collection of user stories, both of these artifacts are described in the article Artifacts for Agile Modeling, several of which are presented in Figure 3. The Place Order use case has been "converted" into a collection of eleven user stories whereas the Search For Item(s) use case simply became a single user story because it was a relatively simple use case. Luckily the team that had identified the initial requirements had written up reasonably good description for the Place Order use case, see Agile Requirements Modeling, so all we needed to do was work through the description and introduce user stories as appropriate, writing each user story on an individual index card. Why index cards? Index cards are easy to work with, both when we are writing them as well as using them to plan our project - several people can work on them simultaneously as a team by simply moving them around on a table or tacking them to a bulletin board. As part of our Release Planning effort we may discover that we need to split some of these proposed user stories further, but for now they should prove sufficient.

Figure 2. A high-level use case diagram for SWA Online.

Use case diagram for SWA Online

An important concept to recognize is that the user stories presented in Figure 3 may be sufficient for now because they provide enough insight for us to begin development. Yes, as the project progress we would need to identify user stories for other aspects of the system, particularly order fulfillment and inventory management, but placing orders is clearly our number one priority for SWA Online so these are the user stories that we can start with. Remember, we develop software incrementally, not as one "big bang", so it's valid to work this way. Having said that it's also important to recognize that we could also work through all of the use cases indicated in Figure 2 and identify a large collection of user stories to be used as input into the Release Planning phase. We could also do something in between these two extremes and flesh out the high priority use cases at first, likely choosing to explore the Manage Inventory and Fulfill Order use cases in addition to Place Order and Search for Inventory Items, and leave the rest for later. Which approach would I take? The one requiring the identification of the least number of user stories that gets our stakeholders to the point where they are confident that we understand the system's scope enough to move forward into development of the first release.

Figure 3. User stories for the Place Order and Search For Item(s) use cases:

  1. The customer wants to review an order online to verify it before scheduling it for fulfillment.
  2. The customer wants to receive an email summary of an order when the order is scheduled for fulfillment.
  3. The customer wants the option to update an order before scheduling it for fulfillment.
  4. The customer adds an item to an existing order.
  5. The customer removes an item from an existing order.
  6. Customers search for inventory item(s) to add to an order.
  7. The customer indicates their shipping address for an order.
  8. The customer indicates a different billing address for an order.
  9. The customer indicates that their billing address is the same as their shipping address.
  10. The customer wants to see the subtotal before taxes, discounts, and shipping & handling for an order.
  11. The customer wants to see a grand total for an order.
  12. The customer wants to see applicable taxes, discounts, and shipping and handling charges for an order.

Of course, it might just have been more effective to write the first two or three user stories and then create a few screen sketches of what the supporting UI looks like. Different teams will find different modeling strategies work for them.

The second aspect of the Exploration phase focuses on your system architecture. Architecture within an XP project is less formal than in traditional methodologies, with a preference for keeping your system flexible - XP recommends that you embrace change, as does AM, whereas architecture-driven approaches advise you to build the skeleton the system first because some things are difficult to change (Wake, 2002). The XP approach is to identify a metaphor that describes how you intend to build your system. The metaphor acts as a conceptual framework, identifying key objects and providing insight into their interfaces. The metaphor is defined during an architectural spike early in the project, during the first iteration or during a pre-iteration that is sometimes referred to as a zero-feature release (ZFR) (Wake, 2002). Beck (2000) suggests that user stories for the first iteration be chosen so that will force you to "create the whole system, even if it is in skeletal form." So, is it during a pre-iteration/architectural spike that the system metaphor is identified, as suggested in Figure 1, or is it during the first iteration? It doesn't really matter as long as it's done at the beginning of your project. This ambiguity was one of the reasons why Agile Model Driven Development (AMDD) includes initial modeling, including initial architectural modeling and initial requirements modeling, to make it explicit that your architecture should be considered before getting actively involved in construction iterations.

Just because XP focuses on a system metaphor that doesn't imply that you are not going to have an architecture, nor does it imply that you're not going to have any architectural diagrams. For example, Newkirk and Martin (2001)[1] created a high-level diagram overviewing their architecture to enable them to better understand what it was they were building, and a similar whiteboard sketch is presented in Figure 4 for SWA Online. Notice how it combines UML use case diagram notation for actors, the stick figures, as well as free-form diagramming - the AM principle Content Is More Important Than Representation advises that it's more important to model your ideas properly than it is to use sanctioned diagramming notation or to make your diagrams look pretty. This diagram also shows an application of the AM principles of Depict Models Simply and Create Simple Content: it is just good enough to indicate our proposed technical architecture and no more.

Figure 4. An architectural overview for SWA Online.

Architectural overview diagram - sort of a UML deployment diagram

The diagram of Figure 4 would be drawn by the development team, following the AM practice Model With Others as described in Agile Architectural Modeling, standing up around a white board. It is based on the user stories of Figure 3 as well as the use case diagram, and corresponding use cases, depicted in Figure 2. The team isn't going to ignore the material captured by the use case diagram and use cases just because they're not official XP artifacts, whatever that means, instead we would follow the AM practice Reuse Existing Resources and take advantage of them. You can see that our candidate architecture seems to handle both order placement and order fulfillment activities. The team has also indicated two aspects of the architecture that it feels are uncertain - it believes it can place a shipment pickup request via XML to shippers and calculate applicable taxes via a commercial off the shelf (COTS) system - by labeling them with question marks (Ambler, 2001a, Ambler, 2002). At some point we will need to do spikes for these aspects of the system to determine if they are feasible, and potentially include these tasks as part of our initial architecture spike (just enough code to show that this candidate architecture will work).

When applying AM's practices on an XP project remember that a primary value of XP, as of AM, is communication. The value isn't in the models that you create, it is in the modeling effort itself - the fact that a model has helped you to understand what your stakeholders want, or how you intend to fulfill their needs, or that has helped you to communicate what you are doing is what is important. Although we may choose to follow AM's Display Models Publicly practice and leave Figure 4 on the whiteboard for awhile the fact is that it doesn't really provide a lot of value to our team anymore, except perhaps to indicate that we still have two outstanding issues to address. Because the team was involved in its creation, and because they are now developing to the technical vision captured in the diagram, they know the technical architecture and likely will not need to look at the diagram again. Other people may learn about your architecture, perhaps through osmotic communication (Cockburn, 2002) described in the Communication article as they walk by it, and perhaps you'll choose to show the diagram to your stakeholders to help you to explain your approach (a good example of applying AM's Model to Communicate practice).

Although Figure 4 provides some insight into your technical architecture it really doesn't provide much insight into your system metaphor. For SWA Online traditional a grocery store metaphor would be a likely candidate. An order is just like a shopping cart, customers browse through your online store placing items into their carts, pull items that they don't want out of their carts, and eventually take their carts to the checkout where taxes, fees, discounts, and their order total are calculated. The selected items would be then placed in boxes and shipped to us, similar to the way that bag-boys in grocery stores put our purchased items in bags and give them to us. The development team would have discussed this metaphor in parallel to sketching the overview diagram, perhaps drawing a free-form sketch such as the one presented in Figure 5 on a another section of whiteboard, just as AM's Create Several Models in Parallel practice suggests. This sketch would very likely be erased once the team had agreed on the metaphor, having served its purpose - the team followed the AM practice Model to Understand and now the practice Discard Temporary Models would apply.

Figure 5. A sketch drawn while identifying a metaphor for the system.

Sketch for system metaphor

2. Planning Phase

Following the Exploration phase is the Planning phase (Beck, 2000), the purpose of which is for you and your customers to agree on a date by which the smallest, most valuable set of user stories will be implemented. When you are release planning you will brainstorm what the tasks for a given user story (Wake, 2002), writing a task card for each task. A task card, see Figure 6 for examples, typically lists a text description of what you need to do to accomplish the task. Sometimes a task card may be described using a model instead of text, for example Newkirk and Martin (2001) [2] provide an example where a task was described as a sketch of an HTML page similar to the one presented in Figure 7. The team may have simply sketched this figure on a whiteboard, or used a combination of Post It notes and flip chart paper to create an essential user interface prototype at first, and once they were happy with what they had quickly transcribed it onto an index card. Both a whiteboard and Post It notes are far more flexible than pen and paper, so they are a better option for you when initially thinking through the design of a user interface component such as this one. The reason why you want to transcribe your sketch onto a card is to have a record of your design to base your coding efforts on during the next iteration, and cards are the preferred medium of choice to do so - distributed teams might choose to record tasks electronically, perhaps in a Wiki (Leuf Cunningham, 2001) or other collaborative environment. In this case a sketch of the screen is a more effective description of the task than free-form text.

Figure 6. Example task cards pertaining to searching for items.

Submit Search to DB

Parse the criteria customer defined from the search page.

Convert wild cards (*, _) to SQL equivalents.

Build SQL SELECT statement based on search criteria, ordering by the item number.

Invoke statement in DB

Build Search Result Page

If a database or network error is detected, build a standard error page indicating the problem. Otherwise:

At the top of the page indicate the number of items in the result set.

If no items resulted from search display the text message "No items found based on your criteria". Otherwise:

List the resulting databases rows on the page, listing the item number, item name, unit price, and a link that leads to detailed information for the specific item.

Figure 7. A hand-drawn sketch representing what needs to be built for the item search page.

UI design sketch for a seach page

Modeling is clearly a potential activity during this phase. For example Figure 8 depicts a sketch representing the logic of a task - the team chose to create this sketch instead of write text for it because they were more comfortable with a quick diagram. This is perfectly fine, the AM principle Model With A Purpose advises that you should know your audience and create models that reflect their needs (in this case your team itself is the audience of the task cards), and the AM practice Apply the Right Artifact(s) advises you to create the best type of model suited for the task at hand.

Figure 8. A sketch representing the logic of a task.

Build seach results page logic diagram

3. Iterations to Release Phase

The Iterations to Release Phase (Beck, 2000) encompasses the primary effort of an XP project, more typically referred to as construction iterations or simply iterations, as this is where your major development efforts including modeling, programming, testing, and integration occur. Figure 9 (Wells, 2000) depicts the lifecycle for an iteration. Iteration planning is the same type of effort as release planning, described above, the only difference being that the focus is on the user stories assigned to the current iteration. When you are working on iteration N you will find that new user stories, ones that have not been estimated, have been added in therefore you need to go through the effort of identifying tasks so you may accurately estimate each user story. After estimating the new stories, and perhaps revisiting the other stories just to be on the safe site, you may find that you have too many or too few stories for the iteration and will need to move stories to/from other iterations.

Figure 9. The XP iteration lifecycle.

XP Iteration lifecycle

From the point of view of modeling, the interesting aspect of an iteration is in the development aspect of Figure 9, a detailed lifecycle for which is presented in Figure 10 (Wells, 2000). A lot of the modeling that occurs during development happens in stand-up meetings where the team gathers to discuss what they are currently working on, often asking for advice regarding how to approach a specific issue. When this happens it is quite common to discuss the issue around a whiteboard, drawing sketches as needed to enhance the communication effort. Stand up meetings are called exactly that because everyone stands up when attending them, which tends to make them brief (Beck & Fowler, 2001). Figure 10 hints at the idea that after the stand-up meeting the team breaks up into pairs to work on their parts of the system.

Figure 10. The XP development lifecycle.

XP Development lifecycle

An alternate view is presented in Figure 11 that depicts a typical XP developer's day (Wake, 2002). It explicitly shows that people pair up after the stand-up meeting, often starting with a quick design session as required to formulate an initial design strategy for what they are working on. A fundamental aspect of XP is that people work together in pairs, following a practice called Pair Programming, which would have been more appropriately called Pair Development, which is defined as a dialog between two people trying to simultaneously program (and analyze and design and test) and understand how to program better (Beck, 2000). XP developers will hold a quick design session, what AM calls an ad-hoc or impromptu modeling session (see the article Rethinking Modeling Sessions), whenever they are not sure how to proceed with programming (Jeffries, Anderson, & Hendrickson, 2001). The basic idea is that you get a few people together to work through the issue, in other words follow AM's Model to Understand practice, to spend a few minutes discussing ideas and modeling as necessary. You will naturally want to follow the practice Apply the Right Artifact(s) and work on the type of models that are appropriate to the issue you are discussing, for example CRC cards are a good option if you are exploring the structure of your code and an essential user interface prototype may be just the thing if you are exploring the design of your user interface. You'll sometimes find that a design issue will require several models, perhaps you need to create both a CRC model and an essential UI prototype to fully explore the problem, and will therefore want to follow the practices Create Several Models in Parallel and Iterate to Another Artifact. These modeling sessions are typically very short, hence the name quick design session, lasting anywhere from ten to thirty minutes. To gain feedback regarding your design you want to quickly get back to coding, following the practice Prove it With Code, to determine if your approach works or not. If it does then great, if not then back to the whiteboard for another quick design session.

Figure 11. The typical day of an XP Developer.

Typical day for an XP programmer

3.1 Case Study: Searching for Items

Let's work through an example. Figure 6 includes a task called "Submit Search to DB". Let's assume that we've already built things in the past such as this - we need to pull information out of an HTML response, replace any wild cards within the criteria with SQL equivalents (e.g. replace * with %), build a string representing an SQL statement, and submit the string to our database - and therefore don't need to spike anything. What modeling would we consider doing? Pulling information out of the HTML response is fairly easy to code as is replacing wild cards within the text. We may even want to consider refactoring our existing code, if we haven't already done so, to include classes or components that implement the two common services. Building an SQL statement is also straightforward, you simply write code to concatenate strings together, although it hints at something we may want to model: our database design. To build an appropriate SQL statement we need to know the layout of the database, including the names of tables and columns as well as the type of the column. Knowing what indices exist for the tables we are accessing, and any relevant stored procedures for searching those tables, provides some insight into potential performance and implementation issues that we want to consider. Many development teams will create and maintain a physical data model that depicts some or all of this information. Very good data modeling tools exist to do this, tools that will not only generate the DDL (data definition language) that you need to create the tables in your database and triggers on those tables but will also reverse-engineer existing legacy schemas as well so you can understand legacy data schemas that you may need to access. As your project progresses your team updates the data model, automatically generating the database code that they require, to reflect new requirements. In the case of this task you would want to ensure that your database includes columns that store the name of an item, the item number, the item category (e.g. clothing, electronic goods), and the price as Figure 7 implies. Luckily your team has a physical data model in place, see Figure 12, for the work you have already done and it indicates that this information exists in the database. However, you notice that the primary key of the Item table is not the Item_Number column but instead is Item_OID, a persistent object identifier something that data professionals often refer to as a surrogate key (Ambler, 2001e). The issue is that according to the task card we must order the results by order number, something that is easy to achieve via SQL's "ORDER BY" clause, albeit something that may have slow performance because the primary key isn't the same column we are sorting on. The implication is that if we find that we have performance problems we may want to use our CASE tool to add and generate a secondary index based on Item_Number as a potential solution. Agile Modeling

Figure 12. A simple data model for SWA Online.

Data model for SWA Online

The idea of using a CASE tool on an XP project to maintain your DB schema brings up an interesting issue - do you train everyone on how to use the CASE tool? On the SWA Online team we have one person, Brendan, who is working on his certification as an Oracle DBA and is very eager to do any database-related work and has been working with the tool for several years now. We also have Marion, someone who has been developing for years and who has significant database and data modeling experience who also has worked with the tool. Other developers on the project - Henri, Ed, Marc, and Tyler - have all paired with Brendan and Marion from time to time to work on the data aspects of the project but have minimal experience with the tool. Should you train the others on the tool? Right now your project team is working smoothly, you have two people intimately familiar with the tool and four that could use it if they needed to. If anyone wanted to learn about the tool some more they would be more than welcome to pair up with Brendan or Marion whenever a database-related task came up, and if they wanted formal training I would in fact consider giving it to them at the time. Would I send everyone to go on the training course? Likely not because it wouldn't provide a lot of value to do so.

How does everyone stay up to speed about the data model? First, during the stand-up meetings everyday anyone who has made a change to the database schema the previous day should say so. Second, the data model is a good candidate for printing and putting up on the wall, as the practice Display Models Publicly suggests. This way when you're having quick design sessions and you need to consider a database change you have the schema in front of you, and if you like you can even hand-draw changes as you talk about them. Note that you don't need to print out your diagram every time you make a tiny change, let AM's practice Update Only When it Hurts guide you with this (most people can live with a diagram that has a few hand-drawings on it). If you do make it a habit to print your diagrams I highly suggest investing in a plotter - taping printer-size pages together quickly becomes tedious.

3.2 Case Study: Totaling an Order

Let's work through another example. Figure 3 includes a user story that describes the totaling of an order, indicating that the system calculates applicable taxes, discounts, and shipping and handling charges for an order. Working through XP's Planning Game practice you quickly realize that this user story is quite large and decide to split it into three separate stories, one for taxes, one for discounts, and one for shipping and handling charges. Our customers decide to make the discount user story low priority, so we put it at the bottom of our stack of story cards, and the other two are given high priority and assigned to this iteration. Because this is SWA Enterprise's first foray into selling directly to consumers it has never had to deal with complex taxation or shipping issues before. You've got a problem, what do you do?

The first step is to recognize that you need to identify requirements for these two user stories, the source of which is your on-site customer. You ask Wendy, your customer, to help explain these user stories to you - an example of Q&A from Figure 11. During Q&A the customer is available to provide immediate answers, often to make decisions regarding how something should work or to provide information to the developers. Luckily Wendy has previously worked in your existing shipping department so has some idea how shipping and handling charges may work, however, she does not have any knowledge of tax rules. She tells you that for now assume a flat shipping and handling charge of $5 and that your state tax of 6.5% is the only applicable tax and it should be applied to all products that SWA Online will carry. She agrees to add the appropriate acceptance tests for these two decisions to the test suite that she has been evolving throughout the project. She also tells you that she will look into both issues for you and get back to you in the next day or so.

Often the customer will be asked to write an acceptance test answering the question or sometimes to write a new story (Wake, 2002). This is an interesting aspect of XP - instead of writing a detailed requirements document and then developing based on its contents XP teams instead build up a collection of acceptance tests with their stakeholders and ensure that their system fulfills those acceptance tests. This leads many XP developers to claim that acceptance tests are requirements, and you know what, they're right.

You now have a place to start because your customer has made a decision. Yes, the details are likely to change when more information is available but that's no problem because you'll deal with the changes when you know about them - After all, you're part of an XP team so you embrace change. As Figure 11 indicates you get into a Test-Code-Refactor cycle and start coding. With XP, you start with a test so that you know when you are done. You design and implement just enough to get that test running, and whenever you see a chance to make the design simpler do so through refactoring.

Later that day Wendy drops by your desk as you and your pair are working away. She tells you that she has left a voice mail with someone in accounting who should be able to explain the relevant tax rules to you. She has also gotten in contact with a friend of hers, Jake Blues, who works at Fly-By-Nite Shipping, the courier whom SWA Enterprises intends to use for the first release of the system. Jake is available tomorrow morning at 9 am for a half-hour conference call which Wendy wants the two of you to attend. You also take the opportunity to show the work that you have gotten done on the user story, showing that a line has been added to the order summary indicating the shipping and handling charges and the new total for the order (the original subtotal plus the new charges). She doesn't like the way it looks on the screen, you got the alignment wrong, so you promise to correct the problem.

The next morning you, your current pair, and Wendy get together in a meeting room and call Jake. The three of you agree to take notes to ensure that you record the information from Jake. Jake informs you that Fly-By-Night negotiates shipping rates with its clients and provides an electronic spreadsheet once a quarter of the rates for that quarter, a sample of which he emailed to Wendy earlier that morning. There are two basic reasons why a new spreadsheet is produced quarterly - the overall rates may change based on changing costs for the shipping company, fuel being the main factor, and the amount of business that you do with them (the more you ship, the lower your rates). The spreadsheet is generated by Fly-By-Night's accounting department and is provided to their customers no less than two weeks in advance of any rate changes. Within the spreadsheet the rates vary by the weight of the package being shipped, the size of the box, and the distance the package is going. Weight is measured in ranges - for example < 6 oz., 6 to 12 oz., and so on - as is the size of the box. Distance, on the other hand, is measured in zones. Jake asks you for your fax number so he can send you a map indicating the zones. The zones are fairly straightforward, working outwards from their major distribution center in rough circles. The good news is that an entire state is either in a zone or it is out of it and this zone system has been in place for almost ten years and hasn't changed for seven years now. He provides you with a few more details and offers to be available via phone and email if you have any more questions.

After the phone call the three of you walk back to your work area and decide to have a quick design session to understand your approach to implement the calculation of shipping and handling charges. Wendy points out that not only do we need to charge the right amount for Fly-By-Night's fees we also need to cover our own internal fees too. Wendy remembers that the accounting department feels that $0.50 a shipment was a fair price but she would need to verify that with them. More importantly, you need to understand how to calculate the shipper's portion of the fees. The three of you start by working through some CRC cards, presented in Figure 13, to identify the potential classes and responsibilities that you believe you need. In parallel you also sketch a UML sequence diagram, presented in Figure 14, which shows the interaction between the classes to support this functionality. You work back and forth between the two models for about ten minutes until you think you have a good strategy for implementing the calculation so you're ready to start coding. As you work on these models you also discuss how you will need to test this functionality, information that Wendy records on index cards, one for each acceptance test.

Figure 13. CRC cards relevant to calculating shipping costs.

Shipping Cost Calculator

Knows SWA costs

Calculate shipping cost for an order

Determine box size for order

Determine weight for an order

Determine zone for an order

Shipping Cost Matrix


Shipping Cost Matrix

Knows applicability dates

Knows box size ranges

Knows weight ranges

Knows delivery zones

Knows shipment cost for a given box size and weight range within a delivery zone


Knows delivery zone the state is in


Knows ship-to address

Knows order items

Calculate shipping and handling costs

Shipping Cost Calculator

Order Item

Order Item

Knows number of items ordered

Knows item



Knows weight

Knows width

Knows height

Knows breath

An interesting observation is that the CRC cards of Figure 13 and the UML sequence diagram of Figure 14 aren't perfectly consistent with one another. That's ok. In general, agile models don't need to be in sync with one another, they just need to be good enough and these two models are. When you discover that two artifacts are out of sync you should follow the practice Update Only When it Hurts and fix them only if provides positive value to your project.

Figure 14. A sequence diagram for calculating shipping costs.

Sequence diagram for shipping charges

During this process you followed the AM practices:

You're just about to start coding when Wendy points out that you're not done yet. You need to introduce a new user story for accepting the spreadsheet from Fly-By-Night Shipping and getting the new figures into the system. She indicates that this is a high priority item that will likely need to be included in the next iteration. You realize that your team may want to follow the practice Formalize Contract Models and put together a short document describing this interface to the shipping company. It would likely include a paragraph or two describing the process of receiving the spreadsheet, an example of the spreadsheet itself, and a description of the import process (either automatic or manual depending on your solution). This document would become part of your overall system documentation.

Later that day Wendy hears back from the accountant she contacted regarding the tax rules. It appears that if you ship a product to someone within this state then a state tax of 6.5% applies for all products, otherwise no sales taxes are collected. He also indicated that individual states are in the process of considering laws that require the collection of taxes for online sales where the shipping address is in their state, and he feels that it is very likely that some states will pass these laws within the year. He also indicated that the Federal Government is considering a value added tax (VAT) of 3% on online sales although it is unlikely that this will come about any time soon. Finally, he pointed out that most foreign countries have duties and sales taxes that would be applicable once SWA Online went international. This information has made Wendy a little nervous. What would happen if the tax rules changed suddenly? You reply that the project team would act accordingly at that time. She asks whether or not you need a big design session to ensure that your system can handle these changes. You reply that you don't want to overbuild your system to implement functionality that you may not ever need, and you certainly wouldn't want to have to maintain that additional code over time either. But she's still worried, she wants to make sure that the team understands that the way you handle tax will need to change over time. So you suggest a compromise - instead of overbuilding your software why don't we simply record these potential requirements and describe them to the rest of the team at tomorrow's stand up meeting? Wendy's accepts this idea, it's worked well in the past, and you quickly write up some index cards as depicted in Figure 15.

Figure 15. Recording the potential requirements regarding tax rules as change cases.

Change Case: Individual States Introduce Online Sales Tax

Likelihood: Very likely within 6 to 12 months

Potential Impact:

We'll need to collect taxes according to each individual state.

We will need to remit taxes and transaction information as appropriate to each state.

Change Case: Federal Government Introduces Online Sales Tax

Likelihood: Unlikely within the next two years

Potential Impact:

We'll need to collect federal sales taxes accordingly.

We will also need to remit taxes and transaction information as appropriate to the government.

Change Case: Foreign Countries Levy Duties and Taxes on Shipments

Likelihood: Certain once we go international

Potential Impact:

Minimal if we use a shipper that handles this for us.

Otherwise we will need to calculate and remit taxes and duties to each country accordingly.

4. Productionizing Phase

XP's Productionizing phase (Beck, 2000) is very close to the deployment phase in the agile software development lifecycle and encompassing the Acceptance Testing and Small Releases part of Figure 1. He states that there is typically some process for certifying that the software is ready to go into production, potentially what I call "testing in the large" techniques (Ambler, 1999; Ambler & Constantine, 2002) such as system testing, load testing, and installation testing to name a few. During this phase you will slow down the rate at which you evolve the software, evolution doesn't stop, but the risk of whether something should go into the next release become important. Note that on some projects this phase is little different than a typical construction iteration, the major difference being that you release your system into your production environment instead of into your development sandbox.

So how does AM apply in this phase? In two ways. First, you may find that you need to model as part of your rework efforts resulting from newly discovered defects. Second, this point in your project is a good time to consider cleaning up your documentation. Although the XP philosophy is write very clear, understandable code and to include effective comments in the code as necessary, the reality is that you still need supporting documentation. Remember that you have a wide range of stakeholders, including users, senior management, operations staff, and support staff. These people do not have access to the code, nor would many of them understand it even if they did, so they will require other forms of documentation. This documentation should be at the request of stakeholders, as the AM principle maximize stakeholder ROI points out it's their resources that are being invested in the documentation therefore they have the final word on what should be done. I prefer to write documentation such as this late in the project lifecycle because what you are writing about, the system, has become relatively stable for the current release and therefore the documentation you write will be stable too. You may also need to produce these documents (following the principles described in Agile Documentation):

  1. System documentation. For developers, including maintenance professionals, this is the most important type of documentation. The purpose of this document is to provide an overview of the system and to help people understand the system. Common information in this document includes an overview of the technical architecture, the business architecture, the high-level requirements for the system, a summary of critical design decisions, architecture-level diagrams, and important design models (if any).

  2. Operations documentation. This documentation typically includes an indication of the dependencies that your system is involved with; the nature of its interaction with other systems, databases, and files; references to backup procedures; a list of contact points for your system and how to reach them; a summary of the availability/reliability requirements for your system; an indication of the expected load profile of your system; and troubleshooting guidelines.

  3. Support documentation. This documentation includes training materials specific to support staff; all user documentation to use as reference when solving problems; a trouble-shooting guide; escalation procedures for handling difficult problems; and a list of contact points within the maintenance team.

  4. User documentation. Your users may require a reference manual, a usage guide, a support guide, and even training materials. It's important that you distinguish between these different types of documents because the way that each one is used varies: one is for quick lookups, one is for discovering about how to work with the system, one is for how to obtain additional help, and one is for training.

5. Maintenance Phase

The XP Maintenance phase (Beck, 2000) is the normal state of XP projects because you keep evolving them over time. This phase encompasses the Planning, Iterations to Release, and Productionizing phases for releases 2 through N of your system. By implication it also includes the activities of the agile software development lifecycle's Production phase for the current release(s) of your system in production. It is important to recognize that systems built taking an XP approach are put into production just like systems built using any other approach. Production issues, such as operations and support, are outside of the scope of both AM and XP. However, it is important to recognize that your team needs to take production-related issues into account which is why AM explicitly includes operations and support staff as potential project stakeholders. Remember, there is little value building a system if you can't deploy it and then keep it in production.