Challenges and How to Overcome Them

The need for strong participation is more critical in the scrum approach than it is with traditional project management. The Scrum Master will speak each day in a high-intensity, high-speed meeting. Interchange of information occurs naturally and quickly and oftentimes, team members will effortlessly recombine to manage resource deficiencies such as missing workers.

We found that using a simple Pareto chart for attendance tracking makes it obvious who the nonparticipants really are. Furthermore, when we post it in an obvious location, we don’t even have to say anything to the guilty parties directly.

However, we shouldn’t have to go this far with team members—early successes, short meetings, and focus reinforce participation.

3.12.6.2 Poor Backlog Documentation

The speed of the development is determined in part by the knowledge of the scope of the project. This knowledge originates in the product backlog—at least that is where

the product scope is documented. When the backlog information is not clear or is insufficient, the team must constantly stop to generate at least enough of a backlog for the next sprint. The failure to develop a solid product backlog and maintain it delays project activities, but may not in itself be catastrophic to the development team’s objectives.

What do we find when we do root cause analyses on half-formed product back-logs? The following list provides some examples:

The team did not properly develop the work breakdown structure.

Customer involvement in requirements capture was insufficient.

The team did not understand the product backlog concept.

The team was accustomed to ad hoc decision-making.

Upper management is not supporting the scrum approach.

Of the listed items, the last one can be deadly. While it is possible to execute the scrum approach covertly, the initiative is more likely to succeed with management support.

In a nutshell, the product backlog process should follow these simple steps:

1. Receive or develop a product or service specification 2. Parse out the requirements

3. Derive any ancillary requirements 4. Identify top-level deliverable items

5. Use top-level deliverable items as top-level work breakdown structure elements 6. Decompose work breakdown structure to the atomic level

7. Use the atoms to populate the product backlog 8. Repeat as changes occur to the project

3.12.6.3 Poor Sprint Documentation

We should only see an inadequate sprint backlog if we haven’t done the initial work on the product backlog. We need to have a fully developed sprint backlog in order to estimate hours of work per “atom” so that we can represent the goal on the burndown chart. It is the difference between hour estimates and hours actual that generates the burndown chart image of our progress.

3.12.6.4 Lack of Reviews

In essence, when we are using scrum, we have two classes of reviews: the daily scrum meeting and the sprint retrospective/planning review at the end/beginning of each sprint duration. The daily scrum meeting is a lightweight thread, whereas the sprint meeting is a heavyweight process. If we apply the scrum approach with the required tools (daily meeting, sprint meeting), lack of reviews should never be a cause for a breakdown in performance. One of the main points of the scrum approach is that we should never get into a situation where lack of knowledge is causing project problems.

3.12.6.5 Atomization Difficulties

It is difficult to estimate the amount of time it takes to achieve a certain deliverable or product backlog without knowing the goal. Atomizing the work breakdown structure accomplishes at least X objectives:

1. Provides a brief task for use in the sprints

2. Allows for binary done/not-done reporting of completion, which allows project management software to represent percentage completion using a hierarchical roll-up

3. Makes estimation of task duration easier

4. Makes it unlikely that a given atom will extend beyond the end of the immediate sprint duration

Since we will measure our results using the burndown chart, we should encounter no major surprises. If our estimates are completely inaccurate, we will see the failure in the burndown chart as a significant deviation. In order to produce a sellable product by the end of the sprint, we will need to coordinate the atoms well enough so that we have something to sell.

We can coordinate the atoms by visualizing the product as a set of concentric rings or as a set of sets. The innermost ring is the core product (hardware or software) in minimum configuration. The core product provides the first release of sellable hardware or software. As we add a new ring or a superset, we produce another version of a sellable product. This approach requires substantial planning and a complete understanding of what constitutes a minimum configuration. The payoff literally occurs as we release sellable products to customer purchase orders and deliver revenue during the development process. Furthermore, the goal of producing sellable products at each sprint reduces our risk because we are never in the middle of a multi-month prototype development that may or may not be rejected by the customer.

3.12.6.6 Incomplete Understanding of Dependencies

In order for our project management software to properly calculate the critical path, we must construct our project, large or small, as a directed graph—a mathematical object with one antecedent-free node (the kickoff) and one consequent-free node (the closing meeting). We must connect all other nodes in our directed graph with at least one antecedent activity and at least one consequent activity. Any task subset of tasks that are not connected this way are called “hangers.” If a hanger has no schedule or budget dependency, then we might ask ourselves why we are executing the tasks immediately; after all, the hanger task is not dependent on anything else.

Dependencies are important in the scrum approach because we need to execute some tasks before we can execute other tasks. Using the directed graph (project management software) can help us develop this network diagram as well as provide a mathematically correct critical path analysis. We need to beware of software that

clutters up the screen with alleged critical paths—if the network has not been designed as we have described, we are looking at visual noise.

The atomic level work breakdown structure helps to eliminate the situation where we have missing tasks. Most project management software allows us to organize our directed graph hierarchically, representing the higher levels as “roll-ups.” On inspection, we should find no roll-ups with missing tasks or disconnected tasks.

Notes

1. C. E. Shannon, “A mathematical theory of communication,” Bell System Technical Jour-nal, vol. 27, (New York, NY: July and October 1948), 379 and 623

2. Richard Luecke, Creating Teams with an Edge, (Boston, MA: Harvard Business School Press, 2004), 97

3. Kim Heldman, Project Manager’s Spotlight on Risk Management, (San Francisco, CA:

Harbor Light Press, 2005), 20

Chapter 4

Complex Program Management

The more complex the project, the more variables and dependencies in the devel-oping organization, the more important is the requirement for clear and frequent communication.