Extreme Project Management for Architects
Extreme Project Management (XPM) is project delivery process. It consists of a series of practices to help manage projects more effectively. The practices help you control project schedules, assign work tasks, and assure that work is done efficiently and correctly.
XPM is based on a highly successful software delivery process called Extreme Programming (XP). XP was developed fairly recently in response to problems that plagued other software development processes.
XPM is an adaptation of the practices of XP from software to other fields like architecture.
This paper provides an overview of XPM from a practical "how to" viewpoint. I'll list the XP practices and talk about how to use them in architecture for planning and quality control. I'll cover topics only briefly, with the intent of expanding on them later.
I'm both an architect and software developer. I had been writing software for over ten years before XP was introduced. To make a long story short, I started using XP practices and it literally changed my life: I was able to derive solutions faster. I was confident the work I did was right. My work improved continually. Bottom line: I produced much better work and took less time to do it.
Over time, I started thinking about adapting XP practices to architecture. This paper is the result of that thinking. XP practices can be readily and beneficially adapted to architecture. This paper shows how.
XP is a popular and effective software delivery process. Although developed fairly recently, XP has already attracted a large following of software developers, managers and customers. Its appeal for them: it works better than other software delivery methods.
XP is team-oriented and customer-focused. Teams range in size from small to medium with the customer as an integral part of the team. XP practices help the team determine and deliver exactly what the customer wants, even if the requirements change over time. The practices also insure that the team delivers high-quality error-free products.
Underlying XP are the values of simplicity, communication, feedback, and courage, which you will see evidence of in the practices themselves.
That's all I want to say about XP for now because I want to focus on XPM. There is plenty of information available on XP: at least seven books with more in progress, web sites, discussion groups, news groups, seminars, consultants and more. A good overview of XP is at www.xprogramming.com.
XPM practices can be divided into two types: planning practices and quality control practices. Planning practices consist of the Release Plan and the Weekly Plan. The rest of the practices focus on quality control and are used daily.
In this paper, I'll first address XPM planning practices, then XPM quality control practices.
One of the cornerstones of XP is simplicity, and XPM follows suit. XPM planning practices are simple. You don't need critical path methods or project management software. All you need are index cards and common sense.
Here's an overview of how to run an XPM project:
The first step in running an Extreme project is to create a Release Plan. The Release Plan describes all the work to be done for the current project phase. It is usually created by the project manager, aided by team members, before work begins. Create a separate Release Plan for each work phase: schematics, design development, contract documents, etc.
Here's how to create an XPM Release Plan:
When you have a card for every task, you've finished the Release Plan. The Release Plan is just a stack of index cards.Here are some planning guidelines:
The Release Plan is not cast in stone. It can and probably will change during the course of the project. Time estimates are not fixed either. They probably will be modified by the team members during weekly planning meetings.
A detailed Release Plan is easy and won't take long to create, even for a large project. You can use spreadsheets, prior projects, and checklists to facilitate the process.
For more information, see release planning tips.
The Weekly Planning Meeting is an integral part of the XPM planning process. The purpose of the meeting is to assign the week's tasks. All team members attend. The meeting usually begins with a retrospective, which I'll talk about later.
It is important that the time interval between meetings be consistent. Meetings should be held weekly, at the same day, time, and place each week.
Prior to the meeting, the project manager selects tasks for the week. Task cards for work remaining are usually arranged on a table in stacks, by priority or by weeks. The PM goes through the stacks, chooses the highest priority tasks, and brings them into the meeting. The number of tasks selected should be based on the prior week's velocity.
Velocity is the number of points (ideal hours) completed by the team per week. The idea behind velocity is simple: If a team did 100 points last week, it will do 100 points this week.
The concept behind velocity is this:
Two powerful features of velocity:
Back to the planning meeting. The objective is to assign tasks for the week.
One by one, choose, read aloud, and discuss each task card. Purpose of the discussion is to:
After all cards have been reviewed, organized, and placed on the task board, team members begin signing up for tasks by posting a selected card beneath their name. When a task is complete, they update the time estimate, put the Task Card in the "Done" pile and select another card.
The Weekly Plan corresponds to the Iteration Plan in XP. We call the time interval an iteration.
We've briefly discussed the Release Plan and Weekly Plan, two simple practices to assure that appropriate tasks are identified, assigned and tracked.
Before moving on, I should mention that new task cards must sometimes be added during an iteration. They usually represent high-priority tasks that can't be delayed. They are discussed and estimated during a stand-up meeting, and posted as before. Lower priority tasks of similar duration are removed to compensate.
Now I want to talk about the daily XPM practices. They help assure that tasks are done efficiently and correctly.
Daily XPM practices help keep the team aligned, focused, and informed and help insure that tasks are done efficiently and correctly. The practices are integrated. Like concrete reinforced with steel, they are designed so the strengths of one compensate for the weaknesses of another. As a consequence, an XPM practice can't be ignored. If you can't follow an XPM practice, you should substitute alternatives that provide similar benefits.One of the most important of the XPM practices is testing.
In XP, you test "everything that could possibly break". Tests are automated so they can be repeated each time you make a change.
Testing is best feedback mechanism there is. Its results are immediate, unbiased and accurate. Without testing, XP simply would not work. XP values testing so much, it mandates that "no code is written without a test".
XP won't work without testing, nor will XPM. For every task, we need to be able to determine:
To simplify this discussion, when I talk about tests from now on, I am including testing alternatives as well.
In XPM there are two types of tests:
This process is called Test Driven (or Iterative, or Incremental) Development in XP. Based on using feedback to determine the next step, it's a very effective and timesaving practice for developing software.
A similar process can be used for developing XPM tests in architecture. Instead of writing a comprehensive list of tests for a task, we would instead determine the minimum effort that would satisfy the requirement. If that is insufficient, ask what else is required, and continue until all requirements are met.
Iterative Development may not be as quite as important to architects, however, because most of our work, at least in the CD phase, is repetitive.
Most architectural projects follow the same or a similar path. We know we'll have to draw door and window details, research products and materials, write specifications, and prepare a cost estimate - no matter which project we are working on. The same tasks are repeated on each project. Thus, we have two advantages. We can:
I'll discuss how to maximize these advantages at the end of the paper.
Testing provides instant feedback that what we've done is correct and complete. There is no better mechanism to give us that level of confidence. Where we can't provide automated software tests, we can develop alternatives. It's a wise investment because our tests can be used both now and in the future.
In the following sections, I'll briefly mention some other XP practices. They help keep the team aligned, focused, and informed. Most can be adapted directly to XPM as-is.
In XP, tasks are completed by pairs, not individuals. Two people work together to complete each task, switching pairs frequently. Pairs also work together to create the tests and verify that they've passed.
Pairing may seem like a duplication of effort, but consider the alternatives. In order to achieve the same level of quality, communication and knowledge transfer, you need more meetings, memos, notes, emails, standards, and other office artifacts; all of which are time-consuming and difficult to sustain.
Everyone working on the project works together in the same room, with visual and vocal contact.
In XP, you are expected to maintain a complete, working, end-to-end system at all times. Other than stubs, which are place holders for unimplemented features, everything included works correctly; otherwise it's not included.
Example in architecture:
Everyone owns all the documents. Any pair can make changes as long as the tests still pass. Working in pairs insures that changes are appropriate.
Examples in architecture:
XP requires teams to agree on and adhere to a set of standards. However, standards are added only as needed and unused standards are eliminated. In other words, standards, although required, are kept to a minimum. For example, instead of a detailed written standard, provide an example, annotated if necessary. Require that all work look like the example.
XPers "refactor" existing code to remove duplication and make their intent more clear. All tests must pass before and after doing a refactoring. To reduce oversights, refactoring is done in pairs. Tests and processes can be refactored as well as deliverables.
Retrospectives are held at frequent intervals in order to identify and modify processes that aren't working effectively.
Stand up meetings are held frequently to facilitate communication and keep team members informed.
Before beginning each project, the entire team meets to discuss project goals and priorities.
Team members work hard and at a pace that can be sustained over time. They rarely work overtime.
Display important information in a prominent location, for everyone to see. We post all task cards for the current iteration on the task board. Everyone can see who is working on what, what tasks have been completed, and what tasks remain.
We usually post a project progress chart. It charts the number of points completed and remaining after each iteration. The slope of the chart can be projected to point at the completion date.
Customer is available at all times to answer questions, make decisions, offer feedback.
Some XPM practices are unique to architecture. As with XP practices, they help keep the team aligned, focused, and informed.
We use prototypes, in addition to standards, to insure consistency and establish a level of quality. Prototypes are like standards adapted to a specific task. For more information, see using prototypes.
From day one, we provide a model of our final objective, updated as we progress. We can instantly see the work we've done and the work that remains. For more information, see working cartoon set.
I've discussed the most significant XP practices, listed their benefits and talked about how they can be adapted to architectural project management.
XP practices evolve over time. The XP community is very active and all XP practices are subjected to intense scrutiny and discussion. Similar scrutiny should be applied to XPM practices as well, not losing sight of our real objective: to efficiently produce high quality work.
To help make it happen, I've set up the following:
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 2004 - 2006, Dennis V. O'Neill