Agile Management for Software Engineering: Dealing with Uncertainty
- Protecting the People Constraint
- Protecting the Time Constraint
- Protecting the Scope Constraint
- Protecting the Budget Constraint
- Protecting the Resource Constraints
- Local Safety
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
There are five main constraints in software development management: people, time, functionality, budget, and resources (excluding people). Agile methods recognize these constraints and seek to protect and exploit them [Beck 2000, p. 15].
Resources must be protected from uncertainty. Uncertainty manifests itself when the unplanned happens. A system can absorb uncertainty with the provision of buffers. Tom DeMarco wrote an entire book slack, about buffering resources in software [2001]!
In every case, a constraint can be protected by a buffer. A buffer would normally be allocated in the same unit of measure as the constraint is measured. Hence, people should be buffered with people, schedule with time, budget with money, functionality with requirements, and other resources with similar resources (see Table 4–1).
Protecting the People Constraint
All Agile methods recognize that software development is an innately human activity. It is performed by people. Therefore, people are the single most important potentially capacity constrained resource in software development.
As the single most important resource on a software project, people must be protected. There is more than one way to provide a buffer for the people. The most obvious is to have more developers than needed. The second is to assume that the people are only productive for a subset of the work day. My favorite number is 5.5 hours. This is a personal choice. Others may suggest different numbers. Buffers must also be introduced to accommodate vacations and ill-health. A wise manager will buffer a little more for unpredictable, life changing events such as a death, birth, marriage, terminal illness, and divorce and more esoteric ones such as fire at home, flood, earthquake, automobile accident, sports injury, and, most recently, military service. Typical American high technology employers with whom I have worked seem to assume that they get 48–49 weeks per year of labor from a software developer. Futhermore, they often assume that the employee will work an average of 9 to 10 hours per day when only paid for 8 hours. A good manager who understands that his people constraint must be buffered will assume much less. My personal choice is to allow 15% for vacation and other outage, that is, a 42–43 week work year, coupled to 5.5 hours of productivity each day.
Table 4–1 Types of constraints and suitable buffers.
|
Constraint |
Buffer with |
|
Scope (Inventory) |
Queue |
|
Schedule |
Time |
|
Budget |
Money |
|
People |
People |
|
Resources |
Resources |
When executives see these hard numbers written down, there is often an adverse psychological effect. Therefore, it is vital that senior management understands that software is an innately human activity and that software developers are not machines that can be switched on and off like the lights.
How big a people buffer is needed? The answer is that buffer size varies with uncertainty. The greater the uncertainty, the larger the buffer must be. There is some possibility that a project will suffer from no downtime or people outage. It is just possible that no one will get sick, get married, have a baby, or suffer a loss of a close family member. It may even be a time of year when no one is interested in taking a vacation. Such times are rare.
It is important that this people buffer is added to the project early. The so called J-curve effect on the production rate reported by Brooks is discussed in depth in Chapter 31. Brooks suggests that adding people later in a project is not effective; they must be added early [Brooks 1995, p.25].
Brooks' Law: Adding people to a late project makes it later.
Uncertainty will vary with the length of the project. With a very short project, there is little uncertainty about people. With a longer project, there is more scope for things to happen unexpectedly. However, it is better to think of software development as an on-going process where projects are simply inventory passing through a system of software production. In which case, it is reasonable to suggest that people-related uncertainty tends to level out at a predictable level. The numbers I gave above (43 weeks and 5.5 hours) are numbers based on my experience—my own empirical evidence. Others may observe different empirical data.