C H A P T E R  5

Project Management

Development and project management teams need one another; they have complementary roles to play in the game of building valuable software. Unfortunately, the relationship between developers and project managers can be somewhat uncomfortable; the amount of discomfort can range from mild irritation to outright hostility and mistrust. The discomfort is often caused by bad practices on both sides; developers often hide bad news, and project managers often pester developers with too many project management overhead tasks. Agile software development techniques help tremendously to mitigate some of these problems.

This chapter outlines the relationship between developers and project managers. Clearly defined roles, responsibilities, and accountabilities are necessary to make any relationship work. The roles are discussed in light of Agile software development in an APEX context. Next, we compare Agile software development with the traditional waterfall approach to project management. Developers need to be aware of the differences between Agile and the waterfall approach because many project managers have had many years of waterfall training and experience. Knowing the differences will help developers to communicate with their project managers more effectively. Finally, we will compare classical project management with Agile software development. Surprisingly, there is a good fit between classical project management and Agile software development. They complement each other nicely albeit with a bit of reshuffling of time lines and the addition of some Agile techniques that are specific to software development. As you read this chapter, keep the Agile value in mind that states “ ...we have come to value responding to change over following a plan.” And more importantly, remember that the item on the right, the plan, does have significant value.

Developer and Project Manager Roles

Developers dislike the overhead that is associated with project management; the project management overhead interferes with their primary purpose, developing software. Project managers dislike the absence and unreliability of time and status data; the missing or bad project management data prevents project managers from fulfilling their primary purpose, which is effectively managing the project and communicating with all of the stakeholders. This section looks at both perspectives.

Developer Perspective

As developers, our primary purpose in life is to develop high-quality and valuable software. This is our professional passion. The environment in which we develop software is usually a project environment. In a project environment, developers have secondary duties, which involve the following:

• Recording past time
• Reporting current status
• Estimating future time

Imagine being a Formula One race car driver. Your primary purpose and passion is to drive fast and win races. Exhilarating stuff. However, your environment consists of a car, race track, and pits where the car is serviced. Two or three times during a race, you must leave the race track and stop in the pits, where your crew changes all four of your tires, cleans your cooling air ducts, adjusts your front wings for more or less down force, and then sends you on your way. The pit stops are mandatory—without them you cannot finish the race, let alone win. The goal, therefore, is to minimize the time you spend in the pits so you can maximize the time you spend racing on the track. Formula One race car teams practice pit stops relentlessly so they are done effectively and efficiently. For example, a Formula One car is stationary in the pits for 2.9 seconds on a good pit stop; a bad pit stop is 3.4 seconds. We developers can learn a lot from the Formula One race car world.

The developer's secondary duties are like the pit stops in a Formula One race. The secondary duties pull the developer away from the primary activity of developing software; however, if they are not done and done well, there is high risk that the project will fail or be cancelled all together. Developers, therefore, must take the secondary duties seriously and organize them so that they are done well in a minimum amount of time. Similarly, management must play its part by taking care not to heap on so many secondary duties as to crowd out the primary.

Agile software development principles and techniques help to minimize the project overhead by emphasizing lightweight project governance. For example, the principles of “ face to face conversation is the best form of communication” and “ close, daily co-operation between business people and developers” encourage frequent verbal communication over formal written documentation. Of course, you must bear in mind that important decisions must be written down or they will be forgotten or misunderstood by some of the stakeholders. You must strike a balance between verbal and written communication and remember the Agile Manifesto's caveat that says “ ...while there is value in the items on the right, we value the items on the left more.” Written requirements and design documents have value; just remember to keep them as terse as possible, making them both short and effective.

APEX provides tools that are effective in minimizing project management overhead. The edit page in Application Builder is linked directly to the To Do page in Team Development (see Figure 5-1). The upper right corner of the page contains four links, three of which go directly to the Team Development To Do, Bug, and Feedback pages. Of special interest here is the link to the To Do page (see Figure 5-2), where a developer can quickly navigate to a To Do that is associated with the current page. The To Do landing page, in this case, contains an interactive report that is pre-filtered for the current application, the current page, and for a status that is less than 100% complete. One additional click takes the developer to the individual To Do page, where the To Do's status is updated and the estimated time is replaced with the actual time (see Figure 5-3). This activity should take well under 60 seconds. By taking your development “pit stops” seriously, you will keep your “pit stop” time to a minimum, which will give you more time for the fun stuff, like developing software.

Figure 5-1. Links to Team Development in Application Builder

Figure 5-2. To Do landing page from Application Builder

Figure 5-3. Updating a To Do's status and estimated time

Project Manager Perspective

Project managers, according to the Project Management Institute (PMI), spend a high proportion of their time communicating. They must orchestrate a project so that everyone's time is respected and used optimally. In order for them to perform effectively in a software development environment, they need accurate time recording, task status information, and good-quality time estimates from developers. Without these inputs, they are effectively blind, which makes them very uncomfortable indeed.

How can a project manager take advantage of Agile and APEX to encourage the developers to supply the needed data? The first step is the realization that moving from classical project management to Agile requires a major shift in attitude for the classical project manager. The one particular value in the Agile Manifesto that gives many classical project managers trouble is “ ...we have come to value responding to change over following a plan.” A plan is static—it is out of date before the ink on the paper is dry. It is important to remember that while the plan has value, the planning process has more value. This thought was captured by Dwight D. Eisenhower when he said, “ In preparing for battle I have always found that plans are useless, but planning is indispensable.” The Agile technique of holding a daily stand-up meeting acts as an effective steering mechanism for a project. A plan is put into place and is adjusted every day in response to the previous day's accomplishments or failures. Kent Beck, one of the signatories of the Agile Manifesto and proponent of Extreme Programming, likens the daily stand-up meeting to driving a car. The car is pointed in a direction (the plan), and then, as the car moves forward, the driver constantly makes minor direction changes with the steering wheel (the planning process) to keep the car on the road. If you don't steer, you eventually drive off the road.

An important artifact in a project plan is the work breakdown structure (WBS). In a classical project management environment, the WBS is fully fleshed out in great detail before work begins. The WBS is used to both estimate the cost and schedule of a project and to control the project as it unfolds. The failure of this approach in the software world is one of the reasons that Agile was born.

The Agile approach to building a WBS is to keep the WBS at a high level and flesh out the details only when the work on an iteration begins. Project managers must avoid micro-managing their developers. Micro-managing flies in the face of the Agile principle “ projects are built around motivated individuals, who should be trusted.”

APEX's Team Development module is a good tool for organizing a project's high-level Features and To Dos (tasks). Each team must decide how much or how little detail to capture in Team Development. Several rules of thumb will be needed to define what is captured formally in Team Development. For example, create a To Do for tasks that do the following:

• Take more than four hours to complete
• Affect one or more other To Dos—in other words, tasks that have dependencies

A detailed WBS is necessary to complete a line item in the To Do list. The detailed WBS can reside in a developer's head or be written on a scrap of paper (see Figure 5-4). There is no need to spend the time capturing micro-details in the formal electronic WBS, as the micro-historical data is generally worthless. The value of the micro-WBS resides in the immediate process of getting the work done. Personally I prefer a micro-WBS that is written on a scrap of paper over the “in the head” WBS. Writing the WBS down forces the developer to think through all of the steps; often an obscure step is identified that would be otherwise missed. Missing snippets of code are very difficult to find and fix, especially when a second developer inherits the code; mind reading is difficult, especially when one of the minds is no longer available. Another valuable benefit to an informal, written WBS is that you can pick up where you left off when you are interrupted.

Figure 5-4. Programmer's personal work breakdown structure (WBS) for a small task

A developer trait that is valuable to project managers is honesty. Project managers must encourage and promote honest communication with developers. Agile's promotion of the daily stand-up meeting is one of the best ways to encourage this honesty. In this forum, problems are exposed early. When problems are exposed early, then there is more time available to address and fix them. Failing early in a project is always better than failing late in a project.

Agile vs. Waterfall

Agile software development was born in a rebellion against waterfall project management. Waterfall project management is one of the reasons for the software industry's horrible record of project failures. Failure is defined as projects being significantly late, overbudget, poor quality, or cancelled.

In a nutshell, waterfall software development refers to carrying out the following processes sequentially (see Figure 5-5):

• Gather requirements
• Design
• Build
• Test and debug
• Implement

Each phase is completed before moving on to the next phase. Detailed reviews are conducted before the stakeholders sign the phase completion documents. The model is simple and understandable.

Figure 5-5. Waterfall project management

In theory, rigorous planning at the beginning of a project finds most requirement and design bugs before construction begins. Bugs are easier and cheaper to fix in the planning stage when compared to finding and fixing the same bug after construction begins. Waterfall software is heavy in the documentation area. Thick documents capture the requirements and design and have value when the project's personnel changes.

In practice, waterfall project management works well in some industries like construction; however, in the software industry, it has failed. There are several reasons for this failure. The software industry is new and is not yet fully mature when compared to industries like construction, which has thousands of years of experience. Our hardware and software platforms change dramatically every year, whereas most other industries measure change in decades and even centuries; the art of bricklaying has not changed much in over a hundred years. Our users' expectations constantly move our goalposts with regards to quality. In short, heavy upfront planning in this dynamic environment is risky; a two-year detailed IT plan is doomed within six months. Agile recognizes this situation and plans for it by keeping the upfront planning at a high level and leaving the detailed planning to individual, small iterations that occur as the project unfolds. Taking a lesson from the manufacturing industry, we can think of this as “just in time planning.”

Agile software development is now being officially supported by the Project Management Institute (PMI). In 2011, PMI added an Agile certification to its suite of professional credentials. The “PMI Agile Certified Practitioner (PMI-ACP)” now stands beside PMI's most well-known credential, the “Project Management Professional (PMP).” PMI's online bookstore and suite of project management white papers are now filled with books and articles dealing with Agile software development. Agile is now mainstream.

Agile Complements Traditional Project Management

The Project Management Institute (PMI) was formed by an altruistic group of project professionals who recognized that there is a great deal of commonality in how all industries manage projects. PMI was born in the 1970s and is now one of the world's largest international professional membership organizations. Its membership has passed the half-million mark, with active chapters in more than 185 countries. PMI is responsible for one of the world's most common and sought-after project management credentials, the Project Management Professional (PMP). PMI maintains and publishes A Guide to the Project Management Body of Knowledge (PMBOK Guide); this guide is one of the main texts studied by certified project managers. PMI is the bastion of traditional project management theory, practice, and techniques.

If you are a software developer in a medium- to a large-size organization, chances are that one or more of your project managers have earned their PMP designation. This chapter steps through the key aspects of traditional project management and shows how Agile complements traditional project management. This material will help you communicate effectively with your project managers.

The PMBOK Guide is organized around five project management process groups.

• Initiating
• Planning
• Executing
• Monitoring and Controlling
• Closing

There are nine knowledge areas that relate to the process groups.

• Integration Management
• Scope Management
• Time Management
• Cost Management
• Quality Management
• Human Resources Management
• Communication Management
• Risk Management
• Procurement Management

As an experienced and skilled software developer, you will probably recognize and relate to all of the process groups and knowledge areas. The headings are intuitive.

The only process group that touches all of the knowledge areas is the planning process. This fact probably accounts for why traditional project managers put so much time and effort into planning. Planning accounts for a large proportion of their training.

The matrix of project management process groups and knowledge areas consists of 26 areas that contain specific outputs and activities.

• Initiating
  • Integration Management
  • Communication Management
• Planning
  • Integration Management
  • Scope Management
  • Time Management
  • Cost Management
  • Quality Management
  • Human Resources Management
  • Communication Management
  • Risk Management
  • Procurement Management
• Executing
  • Integration Management
  • Quality Management
  • Human Resources Management
  • Communication Management
  • Procurement Management
• Monitoring and Controlling
  • Integration Management
  • Scope Management
  • Time Management
  • Cost Management
  • Quality Management
  • Communication Management
  • Risk Management
  • Procurement Management
• Closing
  • Integration Management
  • Procurement Management

Both Agile and traditional project management deal with all process groups and knowledge areas. The main difference between traditional project management and Agile is in the timing. Traditional project management tends to organize projects in a waterfall-like manner, in which the requirement gathering and design are done in great detail before the executing process begins. Does traditional project management dictate that waterfall be used exclusively? No. Traditional project management actually recognizes that there is significant overlap between the five process groups. Figure 5-6 illustrates what the five process groups look like when they are executed sequentially. The only process group that spans the entire project is Monitoring and Control. Strict waterfall project management rarely occurs because the requirements and design must be adjusted to account for bugs, omissions, and minor changes in the requirements and design. Figure 5-7 illustrates the level of interaction between the process groups over time from the perspective of PMI's traditional view of project management. Often, this time-based view is based on project phases that generally have longer time scales than Agile's short and time-bound iterations.

Figure 5-6. Waterfall view of project process interaction

Figure 5-7. Traditional project management view of project process interaction

Agile builds on traditional project management by acknowledging the existence of all of the traditional process groups. Figure 5-8 illustrates how Agile deals with the timing of project management by subdividing the overall (macro) project plan into iterations (micro) project plans. The overall initiation and planning processes are done at a high level. The planning and estimates are fleshed out only to the point where budgetary figures for cost and schedule are deemed reliable enough to get permission to begin the project. Note that you can produce reliable budgetary figures accurately without being overly precise.

Figure 5-8. Agile view of project process interaction

Planning poker is a methodology that is useful in the area of estimating budgetary time for both overall project estimates and individual iteration estimates. Planning poker is sometimes called scrum poker, which acknowledges its birthplace. Planning poker gives each person in a group of experienced software professionals a deck of cards that contains a Fibonacci sequence, one number per card. The sequence is 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, and 89. Note that you could easily substitute any set of relative terms for the Fibonacci sequence; small, medium, large, and extra-large can be used just as effectively. The game is played by selecting a software feature or a task and having each player put down a card that represents his or her estimate of the relative effort required to complete the feature or task. If everyone plays the same card, the number is recorded and the team moves on to the next feature. If different cards are played then the team members discuss why they picked their number. Discussion continues until a consensus is reached. After the relative values of effort for each feature or task have been established, then time values are assigned to the relative numbers so that the schedule can be estimated. A Fibonacci two could be two hours, two days, two weeks, or two months, depending on the planning scale.

Agile Mapping to Traditional Project Management

This section steps through the traditional project management process groups and knowledge areas to illustrate how APEX and Agile fit into the traditional view of project management. Understanding this mapping helps us software developers to communicate with our project managers and helps us understand what is required of us from a project management perspective, so that we can minimize our project management overhead without compromising the project management quality.

Initiating

The start of a project or an iteration requires a kick-off. The initiating process covers both.

Integration Management: Initiating

Traditional project management calls for a project charter to be written to initiate the project. The project charter's main purpose is to define the project's scope, costs, schedule, and probability of success to a point where higher management can feel comfortable giving permission to begin the project.

A developer's input to the project charter is generally confined to the technical viability of the riskier requirements and estimating the high-level amount of effort that is required to construct the application's features.

The beginning of an iteration is much different. Developers are intimately involved with all aspects of an iteration. Developers work closely with the business team to hammer out the requirements. The number of features that are included in an iteration is dictated by the development team's time estimates.

Communication Management: Initiating

Project managers are responsible for identifying all of the stakeholders at the beginning of a project. Once the stakeholders are identified, your role as a developer is to reach out to the stakeholders with whom you will be working. The two main teams that need to be contacted are the business and testing teams. A face-to-face kick-off meeting is an ideal venue, where everyone meets and shakes hands. This is the “forming” stage of the “forming, storming, norming, performing” group development model (as described by Bruce Tuckman in 1965—see http://en.wikipedia.org/wiki/Tuckman's_stages_of_group_development).

Planning

The planning process group touches all nine project management knowledge areas.

Integration Management: Planning

The main output of integration management in the high-level planning process is the project management plan. One of the Agile methodologies is selected or a home-grown methodology is defined.

Scope Management: Planning

Part of the high-level planning process is scope refinement. The project charter already contains a high-level scope; however, it might need further technical work related to dependencies before individual features can be sequenced.

Scope management at the beginning of an iteration consists of picking a small number of features and tasks that can be reliably completed in the iteration's allotted time.

Time Management: Planning

Time management in the software industry is one of the most important aspects of project planning, both at the overall level and at the iteration level. Time in our world equates to money.

The outputs of time management at both the overall and iteration scales are as follows:

• Sequence of activities
• Resource estimates
• Activity duration
• Schedule

The overall sequence of activities should be ordered so that high-value features are delivered to the customer first. When the overall project is managed this way, the customer will have received valuable working software even if the project is cancelled before its scheduled finish. In an iteration, the sequence is often governed only by the technical dependencies.

The sequence in which features are delivered dictates when resources are scheduled to work on the project. Some resources—DBAs, for example—are not full-time team members; they parachute into the project for short stints and then leave.

Duration estimating is vitally important for both the overall project and individual iterations. Duration drives the schedule.

Building the project schedule involves translating time durations into calendar dates. Each feature and task is matched to an available resource, and the time duration is converted to calendar duration by accounting for the availability of the resource, the amount of time that the resource has available for the project work, and the pace at which the resource works; a senior resource will have a faster pace than a junior resource.

Cost Management: Planning

Cost management is usually owned by the project manager, the accounting team, or higher-level management. Developers normally deal with cost indirectly by using time as their currency.

Quality Management: Planning

Quality management at the overall planning stage is often spoken of in terms of performance requirements, online help availability, and ease-of-use. Developers, based on the high-level requirements, tell the other teams what is technically achievable. For example, the developers might say that most queries will run in under one second except for a few that will take five seconds. If the business users demand that the five-second queries be reduced to one second, then the developers must articulate if the one-second target can be hit and, if so, what impact it will have on cost and schedule.

Quality management at the iteration level is a developer's sweet spot. There is a huge amount of passion involved here when a highly motivated and skilled team of developers is involved. Agile's principle of “continuous attention to technical excellence and good design” comes to the fore in this area when the team plans for quality by formulating a rules and guidelines document (see Chapter 7).

Human Resource Management: Planning

Many organizations manage human resources from the top down. Management identifies the roles, responsibilities, skill sets, and reporting relationships that are required by the project; then they assign people to the roles.

Agile works with a bottom-up philosophy that is based on the Agile principles of “ projects are built around motivated individuals, who should be trusted” and “ self-organizing teams.” At the beginning of a project, many of the team members are new to each other and unsure of the roles they will play; therefore, they will go through the “storming” part of the “forming, storming, norming, performing” team development model. The “storming” quickly moves on to the “norming” when the individual team members possess a good level of emotional maturity. In my opinion, Agile requires a high level of emotional maturity to be successful. This is an area where a skilled project manager adds a great deal of value by mentoring team members who need help in this critical soft-skill area.

Communication Management: Planning

Traditional project management calls for setting up a communication plan. Information must flow from the shop floor up to high-level management and stakeholders. This plan must be in place for both traditional and Agile project environments. APEX offers several tools and techniques that can automate much of the communication overhead (see Chapter 8).

In an Agile environment, the working environment is generally much different from the traditional setup. First, individual office cubes are replaced with an open office environment that has no walls. Privacy is respected by setting up a closed-door area where team members can make their private phone calls and write private e-mails. Second, the development, business, and testing teams set up their workstations to be as close as possible physically. If physical co-location is not possible, then remote communication technologies must be set up so that conference calls and screen sharing sessions are quick and easy to organize on short notice. Co-location and remote communication technology directly support Agile's principles of “ close, daily co-operation between business people and developers” and “ face-to-face conversation is the best form of communication.” Working in a big, open room might sound like a recipe for disaster where everyone is constantly being interrupted either directly or indirectly by background chatter. There are several Agile techniques that mitigate the potential open office chaos. The daily stand-up meeting is used to communicate many of the routine status updates. The team can agree to a scheduled “heads-down” time, when phones and e-mails are turned off and conversation is kept to a minimum. Team members who need to discuss an issue can move to a closed-door boardroom so as not to disturb their teammates. On a lighter note, I worked in an open environment with a PhD mathematician who was tasked with coding very tricky three-dimensional underground views of an underground mining property. He donned a pair of bright orange industrial ear protectors when he needed some serious heads-down time. Everyone respected him and his time.

Risk Management: Planning

Risk planning involves looking into a crystal ball to predict what can go wrong with a project and what positive opportunities might present themselves. PMI's PMBOK Guide devotes an entire chapter to risk management that outlines a formal and heavyweight approach to risk planning. The high-level outline is as follows:

• Create a risk management plan
• Identify the risks
• Perform qualitative risk analysis
• Perform quantitative risk analysis
• Plan risk responses

Designing a comprehensive risk management strategy can be a costly undertaking when it is done according to the PMBOK. Justification for doing a comprehensive risk management plan becomes clear only after you perform the quantitative risk analysis, in which hard-dollar figures are assigned to the risks. It is like the chicken and egg causality dilemma.

The traditional approach works well when planning for business risks. Business risks are external to the Agile software development world.

Agile, by virtue of its iterative nature, can be thought of as a “self-healing” environment when it comes to managing negative technical risks. Negative risks can be mitigated by addressing risky technical assumptions early in the project. This gives the team time to wrestle with the problem and experiment with various solutions. A small proof-of-concept project is a good mechanism for experimenting with risky code; the risky code can be fully developed and debugged without breaking the main line production code.

Agile, by virtue of its iterative nature, is well suited to take advantage of positive risks. A positive risk is one that moves you toward a desired goal or opportunity. Often, as mentioned earlier, new and better ideas pop up during development as the developers learn about the business and the business users learn about the technology. Synergy is a wonderful thing to observe and in which to participate. It is fun and invigorating. Adjusting a plan based on new and better ideas usually leads to a better product as long as the overall cost and schedule are kept within reasonable bounds.

Procurement Management: Planning

Procurement, in the software industry, involves the purchase of third-party software and hardware. Traditional project management processes handle this very well. Agile does not speak to procurement management.

Executing

The executing process group is the place where developers live. This is where they do the professional thing that they love, building high-quality valuable software. This is the process group in which the high-level project plan is diced into small iterations that are organized and run as micro-projects. Each micro-project, or iteration, itself incorporates all five process groups: initiating, planning, executing, monitoring and control, and closing. The five process groups, of course, are run in an extremely compressed fashion at this level, with very little formality.

The executing process is like stepping on the accelerator in our Formula One race car analogy. We point the car in a direction and go.

Integration Management: Executing

Traditional integration management in the executing process group encompasses a wide range of activities. The project manager handles activities that involve external teams that are not directly involved in software development. Examples are as follows:

• Managing staff
• Acquiring materials, tools, equipment, and facilities that are needed
• Managing external communication channels (status reports to management, etc.)
• Manage sellers and suppliers

The development team handles all aspects of developing code. Examples are as follows:

• Create project deliverables
• Implement the planned methods and standards
• Generate project data such as actual time to complete a task and task status
• Collect and document lessons learned

Agile's principle of “ self-organizing teams” kicks in here.

Quality Management: Executing

Managing quality is a joy to most dedicated developers. In this context, managing quality entails building working software that is built in accordance with the team's standards that are embodied in its rules and guidelines document (see Chapter 7).

Human Resources Management: Executing

Earl Weaver, manager for baseball's Baltimore Orioles, once said, “It's easy to manage when you have good players.” This is especially true in the Agile software development environment, where you have a team of skilled and highly motivated developers who actively contribute on a “ self-organized team” that is supported by management that believes and acts on the principle that “ projects are built around motivated individuals, who should be trusted.” In this environment, the team takes care of itself with little formal input from the project manager. The project manager is involved only when new resources need to be found and added to the team or when team members are finished and need to be moved on to other projects.

Communication Management: Executing

Communication management during the project executing process consists of, well, communicating. The project manager is responsible for keeping all of the external stakeholders informed of the project's progress. External status reports can be done on a daily, weekly, or monthly basis depending on the individual stakeholders' needs and roles.

The accuracy and reliability of the project manager's status reports depend heavily on the developers' care and attention to recording the actual time they spent on a task and the developers' honesty when reporting their progress on a task. This area of communication between the developers and the project manager is one where tension can exist. Developers can tend to procrastinate when it comes to time recording. Developers can tend to resort to green shifting when reporting their progress on a task. Green shifting refers to the human tendency of avoiding reporting bad news. In a software context, developers will often report a task as green, meaning it is on schedule, when it is, in fact, behind schedule or should be classed as yellow. The same shift is applied when a task should be classed as red, meaning that a deadline will be missed; the developer reports it as yellow, meaning it is only behind schedule. Green shifting drives project managers nuts because they end up with a lot of egg on their faces when a task that has been reported as green for two weeks suddenly turns up red on the last day of an iteration. This nasty surprise raises the blood pressure of everyone involved and erodes any sense of trust between parties involved in the project.

Agile helps guard against green shifting through the daily stand-up meeting. If a piece of working software is starting to slip, it will be noticed early in the iteration. Remedial action can then be quickly taken to get the task back on track. Agile also recommends that the team's progress be published on a public chart that is highly visible to the team. This encourages the team members to record their elapsed time and task status immediately when a task is completed.

APEX's team development module helps in this area by making it easy to enter high-level tasks in the To Do repository and easy to update the actual elapsed time and current status with just a few mouse clicks and keystrokes.

Procurement Management: Executing

Procurement management, during the executing process, consists of buying and installing third-party software and hardware. This task is outside the Agile environment.

Monitoring and Controlling

The monitoring and controlling process is concerned about where we are, how we got here, and where we go next.

The monitoring and controlling process is like steering in our Formula One race car analogy. We are constantly making adjustments to the car's direction to keep it on the road. We use the lessons learned on previous corners to help us navigate through the corners that are coming up.

Integration Management: Monitoring and Controlling

Traditional integration management in the monitoring and controlling process group is concerned with ensuring that the project conforms to the original project plan. When a project veers from the original project plan, steps are taken to record the changes via a change control process, whereby the original plan documentation is amended to reflect the changes.

One of Agile's core values is “ responding to change over following a plan.” This sounds like heresy to a traditional project manager; however, it is a reality in the software industry. An Agile project starts out knowing that it will probably not conform to the high-level plan 100% of the time and that following a plan doggedly in spite of obvious changing conditions is foolish. An analogy could be a road trip from New York to the West Coast—Seattle, for example. We start out thinking we should get to Seattle via a northern route. On the way, we hit a snowstorm and veer to the south to avoid it. In doing so, we find ourselves going through Dallas instead of Chicago, and by doing so we discover that we like warmer weather over the cold. Since we are already on a southern course, we decide to change our goal to San Francisco because it is warmer than Seattle. Going further we find our way blocked by the Rocky Mountains and decide it will take too much fuel to traverse them. Again we head south to avoid the mountains and find ourselves going through Nevada, which is not just warm, but hot. We like it and adjust our final goal from San Francisco to San Diego. In the end, we have reached the high-level goal of reaching the West Coast. In changing our plans on the fly, we have avoided a snowstorm, which would have slowed us considerably, and avoided traversing high mountains, which would have increased our fuel costs. In the end, we ended up in a lovely and warm city on the West Coast, which is a much better place for us to be (my apologies to Seattle, which is, in fact, a lovely city albeit a bit rainy in the winter).

Scope Management: Monitoring and Controlling

Scope management in the monitoring and controlling process group consists of the following:

• Verifying scope
• Controlling scope

The project customer verifies scope by accepting the software products as they are delivered.

Scope control, in an Agile context, is not too concerned when the planned features are changed or dropped or when new features are added. These changes are expected. What must be controlled, however, is the overall budget and schedule. Costs and schedule must remain close to the original, agreed-on estimates in the face of changing requirements and deliverables.

Time Management: Monitoring and Controlling

Time management, in an Agile context, is tightly related to scope management. Agile's principle of “ welcoming changing requirements, even late in development” must be respected but respected within the scheduled amount of time. A late project is counted as a failed project.

Cost Management: Monitoring and Controlling

Cost management is done from the same perspective as time management. Changing requirements are welcomed, providing the overall cost targets are hit. An overbudget project is counted as a failed project.

Quality Management: Monitoring and Controlling

Quality management requires a great deal of interaction and communication between the development, testing, and business teams. Ideally, these three teams should be co-located so that they can take advantage of the Agile principles of “ close, daily co-operation between business people and developers” and “ face-to-face conversation is the best form of communication.”

The testing team is responsible for ensuring that the software works mechanically. The testing team looks for software bugs and must articulately communicate the bug details to the developers so that the bug can be reliably reproduced and fixed.

The business team is responsible for ensuring that the software fulfills the business requirements. The business team looks for flaws, omissions, and possible improvements in the requirements and design.

All three teams will find that the APEX Team Development feedback module (see Chapter 6) provides significant help with quality management by providing the teams with an efficient closed feedback loop.

Communication Management: Monitoring and Controlling

Communication management consists of reporting project performance. Upper management and external stakeholders are kept in the information loop in both the traditional and Agile worlds via status reports.

APEX's Team Development does an efficient job of producing status reports when

• The developers keep the repository up to date.
• The project manager configures Team Development effectively (see Chapter 6).

The development team uses the daily stand-up meeting to keep abreast of progress. Often, the testing and business teams are encouraged to participate in these meetings as observers. These meetings ultimately save a lot of time because the meetings can replace hundreds of e-mails over the life of a project.

Risk Management: Monitoring and Controlling

The entire project team must always be alert for the appearance of both negative and positive risks. In the traditional project management environment, risks can be overlooked and do not make themselves known until late in the project. Negative risks that surface late in a project can cause serious cost and schedule over-runs. Positive risks that surface late in a project represent lost opportunity, which can be extremely costly in a seriously competitive environment.

Agile's reliance on daily stand-up meetings mitigates the hidden risk problem. For example, the daily stand-up meeting quickly alerts the entire team to a potential risk when a developer is a day late with a task that should have taken four hours. It is hard to hide a problem in this venue. The issue is dealt with as soon as it is found, no matter if it is a developer, design, or requirements issue. The ultimate solution might not be quick if it involves a major shift in design or requirements, but at least it is out in the open, where its potential effect on cost and schedule is known.

Procurement Management: Monitoring and Controlling

Procurement management, in the monitoring and controlling process group, entails managing the procurement contracts. Did we receive the goods and services that were expected? Were the suppliers paid? These tasks are usually outside Agile's frame of reference.

Closing

The closing process group is important to the overall project as well as the individual iterations.

Integration Management: Closing

Closing a completed project is much more than just stopping work and handing the resulting product over to an operations team with a handshake. The work required is as follows:

• Transition the product to operations with appropriate training and documentation
• Obtain official and explicit acceptance from the project sponsor—this is extremely important when you expect payment for the work.
• Archive the project documentation and update the company's asset register

Closing an iteration generally involves the following:

• Review the features that were delivered
• Return undelivered features to the product backlog for future scheduling
• Conduct an iteration retrospective meeting in which team performance is evaluated and improvements are suggested

Procurement Management: Closing

All procurements must be closed at the end of a project. The company's asset register is updated, product documentation is filed properly, and suppliers are paid. This is generally handled by administrative staff and is not part of Agile software development.

Summary

This chapter's primary goal is to help developers understand where they fit in their project management environment. Their main role is to develop high-quality working software. Their secondary role, which is also important to the wider team, is to feed the project management data repository with accurate and timely data. This secondary role competes with the primary role for time; however, since the secondary role is mandatory and important, developers must take it seriously and organize their time so that the role is fulfilled quickly and accurately, so as to minimize the amount of time spent away from software development. APEX's Team Development module helps developers to fulfill their project management data entry duties quickly and accurately with a minimum of downtime.

Communicating with project managers is a fact of life. Comparing Agile to the waterfall style of project management and to the traditional view of project management gives developers the background that is required to speak in terms that resonate with a traditional project manager.