Extreme Project Management for Architects
One of the things I like about Extreme Programming (XP) is that its advocates gladly share their experiences using it. This sharing contributes in many ways to its increasing value as a project management process. We can all review, comment, and learn from each other.
With this end in mind, I offer the following report on an architectural project completed recently using XPM practices. XPM is an acronym for Extreme Project Management, my version of a set of practices based on Extreme Programming. It shows one way XP practices can be adapted to a non-software project. I hope others using or considering similar practices will find this report useful for their own endeavors.
In this report, I list each current XPM practice (as of July 2005) along with a brief synopsis, and then briefly describe our experiences using the practice. Click on this link for the complete list of XPM practices.
The project consists of three county-run facilities on a 18-acre sloping site: a 360 person juvenile detention center, a courtroom complex with related judicial facilities, and a support facility including food service, medical and administrative functions. The site includes parking for over 300 vehicles, traffic areas, play yards and exercise facilities. The budget for construction is over 100 million dollars.
Our work was based on an earlier pre-approved design that had to be modified to meet the construction budget and satisfy some additional design requirements. We had 6 weeks to complete schematics, another 6 for design development, and 20 weeks to complete construction documents. Architectural work was divided between two firms. Our firm handled the exterior, including building and site design, while the other firm handled the interior, including structural, mechanical, and electrical.
The project was design/build and fast-tracked. While we were completing our work, the contractor was getting bids from subcontractors, even during schematics. During the construction documents phase, we put out five separate bid packages. We were able to start construction before completing the CDs.
Work was coordinated via weekly meetings attended by the contractor, architects, consultants, and often others. Each party would send one or more representatives to each meeting. These were not XPM meetings. Ours was the only firm that used XPM practices.
In discussions below, I'll refer to our team as the in-house team, and the larger team consisting of the contractor, architects, and consultants as the construction team.
Our firm had originally intended to assign the work to three separate in-house teams using traditional roles like project architects, job captains, designers and drafters. However XPM practices work best when the entire team works together, so after deciding to use XPM we chose to use a single team for the entire project. Team size varied over the course of the project, with plus or minus eleven members, which is close to the maximum comfortable size for a single XPM team.
XPM practices are task-based with little need for titles and roles. However, we weren't able to abandon roles completely, especially for tasks requiring interaction outside the firm. Our team consisted of a project manager, project architect, designer, spec writer, and a diverse group of 5 or 6 more architects, licensed and unlicensed, with experience ranging from more than 20 years to fresh out of university. My role, as XPM advocate, was to teach and facilitate the XPM practices.
Most team members worked full-time on the project, but some worked on other projects as well. The project manager and spec writer handled several other projects. I participated part-time, usually only for stand-ups and planning meetings.
The project architect, designer, and a few architects had not yet been hired when the project got underway. We had to interview, hire, and bring them up to speed in addition to meeting our fixed set of timelines.
Theory: XPM is more easily adopted in firms where teamwork is encouraged, where workspaces are open rather than private, and where management structure tends toward flexibility and adaptability rather than command and control. More important, XPM requires buy-in by management and staff.
Reality: Members of this firm were used to communicating openly, working together, and improving existing practices. They already had an open workspace. The firm was familiar with XPM through a lecture I had given a month before and everyone, management and staff, was enthusiastic about trying it, subject to one condition: periodic reassessment.
Normally, XPM practices are improved and adapted via regularly scheduled retrospectives. We went further. Since no one had used XPM before, we subjected the process itself to periodic evaluation. After each project phase, we asked the team "should we continue using XPM or not"? In each case, the answer was yes.
Theory: XPM practices tend to keep team members aligned, focused, and informed. The project kickoff meeting is where it begins. The entire team gets together to discuss the project, its objectives, and processes.
Reality: We gathered the team for an afternoon and discussed the project, processes, and objectives in detail. Some teams create a written project charter that formally lists the items discussed, but we skipped this step. Instead we kept a list of "measures of success". Each team member was asked: For you personally, what would happen on this project for you to consider it a success? A wild success? We kept the list for evaluation, discussion and updating after each project phase. The list helped us realize the different kinds of value we could get from this project. We came up with 30 different measures in four categories: team success, XPM success, communication success and project success.
Ideally, a project kickoff meeting includes all people working on the project: client, contractor, and consultants as well as the in-house project team. Our project kickoff meeting included only the firm principal and in-house project team. By default, the principal and project manager informally represented others who were missing.
Theory: A project plan provides management and team members with an overview of the project. It can be used for budgeting and staffing projections. It's a collection of all the tasks required to complete the project. Tasks are coarse-grained with the understanding that they will be broken down into more detail later.
Reality: We created a fairly coarse-grained project plan, broken down by project phases, using a spreadsheet:
We estimated time for each task in ideal hours and multiplied that by a fixed hourly rate to get an approximate dollar estimate for each task. We used a high hourly rate to compensate for the fact that we were estimating in ideal hours, not actual hours. Ideal hours are the time a task would take if you could work on it uninterrupted.
We kept the project plan in its spreadsheet format. We didn't start creating task cards until we created our release plans.
Theory: A release plan contains all the tasks required for one specific phase of a project. Like a project plan, it provides an overview and can be used for budgeting and staffing projections. Again, it's coarse-grained, with the expectation that it will be expanded later during weekly planning meetings.
Reality: We generated release plan task cards directly from the project plan spreadsheet for schematics and design development. We imported the spreadsheet into a word processor and printed sheets of 3 x 5 index cards using the word processor's mail-merge feature. We supplemented the original set of cards each week with hand-made cards. We stored the release plan in a multi-pocket expandable envelope, but later found that an index card box with tabs works better.
We handled the CD phase release plan differently. Most of us know what's required to complete a set of construction documents, so for the CD phase, the entire team created the release plan. We first defined categories of deliverables like site plans, elevations, floor plans, and several categories of details. We then broke into pairs to create sets of task cards, by hand, for each of the categories. We ran the process like an XPM project, in 15-minute iterations, changing pairs each iteration, until we completed task cards for all categories. We then estimated each task using a similar pairing process. Although the team-developed release plan was an interesting experiment, we later found that the tasks were too fine-grained and hard to manage. Some of the tasks were ambiguous and many were near-duplicates.
During the CD phase, we had to issue five separate bid packages for work that would start prior to completing the CDs. We should have created a separate release plan for each. Instead we used the CD release plan and added additional tasks during weekly planning meetings on an ad-hoc basis. Consequently we had difficulty determining what was in or out of the packages and whether or not we could meet the schedule. In one instance, the team had to work overtime to meet a deadline.
Theory: A placeholder/progress set is a progress set of deliverables, with placeholders for sheets or items that are not complete yet. Over time, the placeholders are replaced with the actual deliverables. The placeholders show what remains to be done, while the progress set shows what has been done. The set includes drawings, specifications, contracts, calculations, color boards, and anything else required to be delivered to the client, contractor, consultants, building officials, etc.
Reality: During schematics we created a cartoon set because it was required by the client. The cartoon set served as a placeholder set . We maintained progress sets for the other project phases, usually without placeholders. We maintained two or three progress sets at a time during CDs, one for the overall CD package and others for each separate bid package.
We handled updates to the progress set as an iterative task. One of the team members volunteered to maintain the progress set and coordinate the work at the same time. This proved fairly effective and efficient except when the coordinator was overloaded with work, out sick, or on vacation. No one else felt comfortable taking the task over. We hadn't made it a paired or rotating task.
I use the terms "iteration" and "week" interchangeably because an XPM iteration is typically a week long.
Theory: In XPM, we create an iteration plan each week. That is, we select a set of tasks to be done during the current iteration. Since the entire team is together to create the iteration plan, we add a retrospective and progress review meeting at the same time for convenience and efficiency.
Reality: We held weekly planning meetings without fail, even if the PM was unable to attend. Iterations began on Thursdays rather than Mondays. Mondays would have worked better for time accounting but we chose Thursdays because the PM and PA had to attend construction team meetings on Wednesdays; meetings which always generated new tasks and announcements.
We started our planning meetings promptly at 9:30 AM. This allowed team members to set up their day and respond to critical issues before the meeting. Meetings at 9 AM, we discovered, are too early.
Even combining three meetings and related discussions, we were always able to complete planning meetings before noon. On a few occasions, we postponed the retrospective and progress review to save time, but we always created a new iteration plan.
Theory: In XPM, we deliver visible value each iteration. We want to see measurable progress in the form of deliverables. The deliverables are represented by the placeholder/progress set, so the customer and team review it at each weekly planning meeting. The review gives us an opportunity to discuss and celebrate our progress as a team.
Reality: Although we completed significant amounts of work each week, we didn't follow this practice. We created a progress set, but didn't review it as a team. Instead we sometimes discussed status or tasks required as a result of recent construction team meetings. Team members' sense of satisfaction and understanding would probably have increased if we had followed this practice regularly.
Theory: In XPM, we try to continuously improve our practices. Each week we ask team members if there was anything during the past iteration that kept them from working at maximum speed, anything we should think of changing. We supplement weekly retrospectives with one-on-ones and milestone retrospectives, which are discussed later.
Reality: Since retrospectives are scheduled weekly, we kept them short, usually less than half an hour. We didn't try to resolve every issue as soon as it was brought up. We would post issues on the task board, and leave them there until they were resolved. We took a photo of the task board each week for our records. Weekly retrospectives were very valuable. They provided a setting to discuss problems and complaints as well as practice improvements.
Theory: An iteration plan is a list of tasks expected to be completed during the coming week. Tasks are selected by the customer or customer proxy (usually the PM or PA) from the release plan to include the highest priority items. Additional tasks are added during the meeting as required. The number of task-points selected is based on team velocity and availability. Task cards are read one by one during the planning meeting and discussed in enough detail so they are understood and can be reasonably re-estimated by team members.
Reality: For efficiency, tasks for the current iteration should be selected by one of the team members prior to the planning meeting. We usually selected tasks during the planning meeting instead.
Reading each task card aloud gave everyone an opportunity to question its intent and compare it with work already done. We often discovered tasks that were unnecessary or already completed. At the same time, we also discovered tasks that would be required but had been forgotten. Someone would create a new task card on the spot.
Many of the tasks, especially later in the project, needed little or no discussion because they were either similar to tasks done before or everyone knew what was involved. We also often chose not to re-estimate tasks, leaving the initial estimate as-is.
We would usually select more points than we expected to complete, so at the beginning of each planning session, we would re-evaluate whether or not the tasks remaining from the prior iteration should be completed or postponed.
Theory: If the same team members work on a project the same number of hours each week, you can expect a fairly constant amount of work to be completed each iteration. In XPM, we measure work on tasks in points. A point is equal to an ideal hour of work on a task. We call the number of points completed each iteration the team's velocity and we choose tasks for the coming iteration by choosing the same number of points as last iteration. If our velocity was 100 points last week, we choose 100 points this week.
Reality: On our project, staff availability varied each week due to vacations, holidays, and work on other projects. So we added another factor into the equation: team availability. That is, the number of hours team members expect to be available to work on the project. We use it like this: If team velocity was 100 points last week and availability was 120 hours, but this week availability is only 60 hours, or 50% of last week, we choose only 50 points worth of tasks this week.
We tracked both availability and velocity each iteration. For availability, each team member would post the number of hours he or she expected to work on tasks during the coming iteration. We didn't include time expected to be spent in meetings or on non-tasks. The total was the team availability. For velocity, someone would collect the prior iteration's task cards, then count and total the number of actual hours spent on each task.
Theory: XPM has two complementary practices related to task cards. Create a card for every task, and don't work without a card. The objective of these practices is to confine the team's efforts to those tasks required to complete the project effectively, no more and no less.
We create a card for every task because we want to decide which tasks to choose based on objective comparisons with all other required tasks. If we don't have a card for a task, we can't compare it with others. In addition, having a card for a task means it will be subject to scrutiny by the entire team during the planning meeting.
Reality: We created cards primarily for creating deliverables; rarely for trivial tasks like making phone calls or answering emails. We did create some task cards as placeholders for things we wanted to recall in the future, even if they took just a few minutes. We called those zero-point tasks.
Anyone can create a new task card at any time, and eventually our hand-made task cards began to lack consistency. So we set up a template for task cards. It identified the location for all task card components. We included the card author's name, so the person doing a task would know who to go to for more information. We also placed the original and revised estimates, and actual time spent in a specified location on the card so we could find it easily.
Theory: Iterative tasks are those that occur each day, week, or other recurring time period: attending weekly meetings, updating progress sets, uploading drawings, maintaining filing systems. They require about the same amount of time and effort each time period and their scope of work doesn't change over time. Thus, they can be factored out of task selection and velocity calculations.
Reality: We originally created task cards and tracked iterative tasks for a few iterations. We quickly decided it was not worth the effort. Thus, this practice of factoring out iterative tasks is a result of our experiences. It was not a listed XPM practice when we started the project.
Most iterative tasks require consistency and continuity, and are best handled by a single person, so we usually had one person sign up for each iterative task for the project's duration. Some iterative tasks were assigned by default. For example, consultants and clients expect to meet with the project architect, not someone else.
Factoring out iterative tasks simplifies tracking, but we're still experimenting with this approach. We are considering reusing the same iterative task cards over each week, color-coded to stand out from non-iterative tasks. In addition, assigning one person to any task creates bottlenecks when that person is overworked or unavailable. It limits opportunities for cross-training and distances the person from the team. I'd suggest that teams experiment with rotating tasks and more pairing for iterative tasks.
Theory: After selecting the week's tasks, we stack them in categories (site plan, doors, windows, etc.) and leave them on the task board for selection by team members. Team members are expected to select and complete one task at a time unless tasks are related. To select a task, a team member takes the card and posts it beneath his or her name so everyone can see who is working on what task. After the task is complete, they place the card in the "done" stack of cards and select another.
Reality: Selecting, rather than being assigned tasks, gave team members more of a sense of ownership. It worked especially well with inexperienced and new team members. They could choose tasks that didn't require an extensive understanding of the project yet meshed with their experience and background.
Theory: In XPM, we generate and post weekly reports so team members and others can see the results of our efforts. We try to make the reports visible and graphic.
Reality: Over time, we posted a variety of reports and charts, simplifying and improving them as the project progressed. The most valuable were:
Once set up, the charts and spreadsheets were easy to update and maintain, and well worth the effort. The charts provided a nice visual way to display our progress.
Theory: A stand-up meeting is a short meeting, held each day, in which each team member states what they did yesterday, what they expect to do today, and what obstacles are in the way. It's an excellent way to coordinate tasks, bring up issues, get recognition for work done, and make commitments for work to be done.
Reality: We held stand-ups daily, usually at 9:30 AM. All available team members would attend, promptly. Some early meetings tended to be lengthy, but after several complaints, we were able to reduce time to about 15 minutes, even with 12 or 13 members present. Meetings lasted longer if a topic of interest came up.
About mid-project, we added an additional requirement that team members show as well as tell what they had completed. It's easy to do for most architectural tasks and provides a strong visual image of completed work.
Overall, stand-ups were extremely beneficial. They contributed very much to keeping the team aligned, focused, and informed.
Theory: Begin each stand-up with team announcements related to the project. Any team member can make an announcement.
Reality: Announcements were almost always short and pertinent. Team members would arrange to hold longer discussions in a separate meeting after the stand-up.
Theory: An XPM project is controlled by task cards. We decide on the most important tasks to do each iteration at the weekly planning meeting, and work on those tasks and only those tasks. If additional tasks are discovered during an iteration, we make a new task card and decide if the task needs to be completed this iteration or if it can be postponed until later.
Reality: This practice worked very well for us except for a few cases where someone would ask a team member to complete a "high priority" task without a card. Over time, we made efforts to eliminate such requests.
Theory: A task card conveys the essence of a task, often in a single sentence, like "sketch north elevation". It contains a minimum amount of information. It serves as a reminder for one or more face-to-face conversations to occur later between the card's author and person completing the task. The purpose of those conversations is to clarify the scope of work and level of quality (LOQ).
Reality: For most tasks, scope and LOQ were clear from planning meeting discussions. Where unclear, team members discussed the task with others. There were some lapses. When scope wasn't clarified, we usually did more than required. Pairing would probably have reduced this overwork.
Theory: Writing tests before completing a task helps clarify what's expected. Tests tell you what's required and what's not. They help you define scope and level of quality. They reduce the amount of time spent on a task because you limit your efforts to those required to pass the tests. You are unlikely to do more work than is required. After you complete a task, tests give you confidence that what you've done is correct and complete.
Reality: In lieu of writing tests, we used an accelerated peer review process. Each task, as it was completed, was reviewed by another team member, and then integrated into the drawing set. This one-task-at-a-time review process gave team members almost instant feedback.
We discussed creating tests for tasks, but abandoned the practice early in the project. The amount of time and energy we were spending discussing tests and the testing process was impairing our ability to get work done.
Theory: Prototypes help team members establish a defined level of quality for repetitive tasks.
Reality: We created only a few prototypes. Instead, by default, we ended up using the first of a series of similar drawings as the prototype. This wasn't completely effective, because not all team members knew that such a prototype had been created. We could have formalized the practice by identifying prototypes in daily stand-up meetings.
In another case, instead of creating prototypes, the entire team held a meeting to discuss what would and would not be included in our exterior window details. Team members agreed that this process was as valuable as creating prototypes.
Theory: After a team member completes a task, he or she updates the progress set, revises the estimate, and then puts the task card in the "done" card stack.
Reality: The team followed this practice quite faithfully. We used the actual hours spent as noted on each task card to generate progress reports. Actual times were usually fairly close to estimates, probably because most tasks took less than four hours duration, and rarely over eight.
I added meeting practices recently to the list of XPM practices, as a result of experiences on this project. Meetings are a significant part of architecture. It makes sense for team members to agree to practices that will enable them to work more effectively.
Theory: Keep meetings short and focused by limiting the number of topics and participants to those absolutely necessary. More meetings may be required, but they can often be handled in one-on-ones or short stand-ups.
Reality: Except for planning meetings, most of our in-house meetings were short and focused stand-ups. We had less control over outside meetings. They tended to be longer, covered more topics, and, based on participant reports, seemed less productive.
Theory: Meetings can easily go off track and waste everyone's time if meeting objectives aren't clearly understood and agreed to.
Reality: We try to state the meeting objective at the beginning of each meeting unless it's obvious.
Theory: Create a task card for every meeting.
Reality: Our earliest sets of task cards focused on deliverables. We tended to ignore meetings until a day or two before. We would sometimes have to scramble to prepare materials for an upcoming meeting. Writing a task card for each meeting served as a reminder to prepare ahead of time.
Theory: Most meetings generate action items for the team. Meeting attendees are expected to create a separate task card for each item. If the task must be completed before the current iteration, the card is placed in the "to do" stack of cards and announced in the next stand-up meeting. If the task can be done later, the card is stored with the release plan, to be discussed in the next appropriate planning meeting.
Reality: While this practice seems simple, it usually takes conscious effort to make it a habit.
Theory: We rely on attendees to inform the team of significant decisions made during meetings with clients, contractors, consultants and others. Attendees are expected to mention significant items in stand-up or planning meetings. Keep announcements brief. Hold detailed discussions later in ad-hoc stand-up meetings with interested parties.
Reality: Early in the project, team members complained that announcements were evolving into discussions and were taking too long. We improved by making a conscious effort to limit our discussions.
Theory: Meetings (and some tasks) generate unplanned tasks that must be done during the current iteration. Unplanned tasks are disruptive but inevitable. If you track them over time, you can anticipate and plan for them.
Reality: We decided during CDs to track unplanned tasks by adding the comment "new" on the top-right corner of each unplanned task card. We tracked unplanned tasks by counting points for the "new" cards separately from normal task cards. Our velocity was the sum of normal plus unanticipated task points. About 30% of our tasks were unplanned. That is, they were unanticipated at the beginning of the iteration.
Theory: In addition to weekly retrospectives, hold more comprehensive retrospectives at the end of each project phase.
Reality: We held a retrospective at the end of SD, DD and CD phases. They were a combination of celebration and retrospective. Each lasted a few hours. We usually discussed and updated our "measures of success" list during the meeting.
XPM guidelines are practices that don't have well defined triggers. They're often diffused rather than triggered by recurring events. Some are repeated continually, others only occasionally.
Theory: One-on-ones supplement weekly retrospectives. They provide an opportunity for team members to discuss issues on a more personal level; issues they would be uncomfortable discussing in a team meeting.
Reality: Early in the project, I started discussing XPM and other issues in one-on-ones with individual team members. Meetings were short and unscheduled, often focusing on personal issues. In one case, I sent a questionnaire to each team member and discussed the issues raised in the questionnaire. I then summarized, categorized, and posted the responses. The categories were things we wanted to do more of, less of, or continue the same way. We used the responses for future team improvements, just as we would do in a retrospective.
Team members felt that one-on-ones were a valuable supplement to retrospectives, so I've added them to the list of XPM practices.
Theory: Communication improves when team members work together in the same room. Ad-hoc meetings are easier to arrange, decisions are made faster, and information is quickly disseminated.
Reality: The existing office arrangement of open cubicles made this practice fairly easy to follow. Team members swapped cubicles with other staff so they could be closer together. Team members were used to working in this type of environment with its associated distractions. We placed the task board, on wheels, in the same area. We held stand-up meetings in the aisle that separated two groups of cubicles.
We did run out of space, so the last two members to join the team were separated by about ten feet from the original cluster. Although not a major disruption, they both noted at one retrospective that they felt a little left out.
Theory: Pairing, where two people work together to complete a task, provides several benefits to the team. It gives both members a chance to learn and share knowledge, provides continuous peer review, and offsets the apparent duplication of effort with speedier task completion.
Reality: We didn't insist that tasks be completed by pairs. Instead, we recommended that team members decide on their own how much pairing to do. We suggested partial pairing, where team members pair at the beginning and end of a task. At the beginning to discuss alternative ways to handle the task, and at the end to review the completed task for correctness and completeness. Simply encouraging pairing seems to set up an atmosphere where team members are comfortable sharing information, asking questions and giving advice.
Although team members paired at times, recognized pairing benefits, and expressed a desire to pair more, only about 10% of the tasks were done using pairing or partial pairing.
Theory: In XPM, tasks are assigned to the team, not to individuals. Any team member can complete any task. Team members cooperate and the project moves faster because delays caused by bottlenecks are rare. Task cards facilitate this process because team members choose each task they want to work on.
Reality: We used task cards for most tasks, even iterative ones. We didn't create task cards for tasks done by the project manager or project architect. The PM and PA did tasks they thought were necessary without creating or selecting cards. Consequently, there was little discussion about their tasks, and never any pairing. Similarly, we didn't create task cards for writing specifications, which were done by our in-house spec writer.
Theory: In order to effectively distribute responsibility, anyone must be able to work on any document. The team owns the documents and anyone can change anything.
Reality: We followed this practice consistently for drawings. Early in the project some team members found it distressing. Working on so many different types of drawings was challenging at first. Allowing others to change "their" drawing was also daunting. Over time, however, all agreed that the practice saved time and rapidly increased learning opportunities.
Specifications were done exclusively by our in-house spec writer. Team members discussed products and materials with him, and he updated the specifications. This process didn't create bottlenecks due to the spec writer's efficiency, but it also didn't provide opportunities for other team members to learn about the intricacies of writing specifications.
Theory: There are several different customers for architectural tasks. Our prime customer is usually the client, but we also perform tasks for the benefit of consultants, contractors, review agencies, and others. Ideally, our customers are available at any time to offer feedback and make decisions. Realistically, our customers are only rarely available. When they're not available, we assign proxies to represent them.
Reality: We hadn't formally initiated this practice when we started the project. The PM or PA implicitly represented the client. Team members attended meetings with "customers" and reported back. We didn't see the need for a proxy until several misunderstandings occurred involving the same consultant. One of the team members volunteered to represent that consultant. The proxy provided the required frequent and informal contact to prevent future misunderstandings.
Theory: Office standards help insure consistency in contract documents. They need not be exhaustive however. Prototypes, adapted specifically to the project, are more effective.
Reality: Standards for this project were established by the client. We had to adapt our drafting standards to theirs, which we did without much difficulty. The office staff held regularly-scheduled meetings to discuss and resolve CAD-related issues.
Theory: An XPM team works at full capacity each day. We recognize that a team becomes less efficient when required to work more than a reasonable number of hours so we try to minimize the necessity for overtime by proper planning.
Reality: Except for one instance, we were able to meet all our deadlines without overtime. In that one case, other construction team members couldn't make the deadline either, so it was extended.
Theory: Base decisions on experiments rather than speculation. Instead of long drawn-out discussions, determine a course of action based on the simplest thing that could possibly work, then monitor and evaluate the results.
Reality: We followed this practice a few times, with positive results. In one case, we were not sure how to handle daily drawing coordination. Should we ignore daily coordination? Coordinate weekly? At the end of a phase? Should everyone do their own coordination? Pair to coordinate? We could have discussed this issue for hours. Instead, we decided to make coordination an iterative task and let someone sign up for it. We evaluated the results in our weekly retrospectives and decided to continue the process.
Theory: Deliver early and often in order to get feedback. In XPM, we develop incrementally, improving a little bit each iteration. People make better decisions when they can see one or more of the proposed solutions.
Reality: On this project, we were required to present our work to the construction team during weekly progress meetings. These weekly meetings tied nicely into the XPM practices and were very effective for generating feedback.
Theory: For each task, do the minimum amount of work required to complete the task. No more and no less. Improve incrementally based on customer feedback.
Reality: We followed this practice but would have benefited even more if we could have gotten more rapid feedback from the contractor and consultants.
Theory: Creating alternatives provides a quick way to generate feedback.
Reality: We created alternatives, especially during design, but didn't capitalize on this practice during production because it took too long to get feedback. On the other hand, when only in-house feedback was required, the process was very effective.
Theory: XPM practices are habits for a team to agree to, then adapt to the current project's needs. Our objective is a successful project, not conformance to a set of practices.
Reality: The entire team agreed to try the XPM practices, and over time, we did adapt them, sometimes consciously via retrospectives, sometimes unconsciously or by default. If a practice didn't "stick", we didn't force it.
Theory: Provide an open office environment where ideas can flow freely.
Reality: The office environment in this case was already well-suited to XPM before we decided to adopt it. The production space was open with movable cubicle partitions and adequate room for ad-hoc meetings, bulletin boards and task boards.
Ours was the only team on this project using XPM, but we had to coordinate with other teams who were not. This wasn't a major problem because the entire construction team had to adhere to the same rigid schedule. However, at times, we got ahead of the rest of the construction team. We needed answers to questions they weren't ready to deal with yet, so we had to delay or guess at some solutions.
Some members of the construction team were initially uncomfortable with our XPM tasking approach. Early in the project, we were asked to provide a list of job titles along with corresponding in-house contacts. We provided only a partial list, with an explanation of our practices. Over time, as we responded quickly to technical requests and met all deadlines, our XPM approach became a non-issue.
I've listed the current XPM practices, and discussed how we implemented or adapted them on a fairly large architectural project. Even though we neglected some of the more significant practices like pairing and testing, we consider the project a success and are using similar practices on other projects in the office right now.
Click here for a version of this page that's more suitable for printing. After printing, click the back-arrow of your browser to return to the original format with an index alongside.
I welcome your comments and suggestions. See contact us for more information.
Copyright 2005, Dennis V. O'Neill