Dealing with Uncertainty

Mike characterized traditional approaches as trying to manage out uncertainty in the effort to achieve predictable results. This strategy essentially involves determining up front the key aspects of the project (scope, budget, and schedule) and then seeking to minimize changes to it throughout the project. Unfortunately, virtually all software development is faced with a multitude of uncertainties. Trying to drive them out means conflicting with reality, which leads to a common litany of project problems such as: over budget, over schedule, scope achieved but business not satisfied (business objectives not met), and excessive cost for realized value.

Agile adopts the opposite philosophy: manage for uncertainty. Kent Beck used the term "embrace change" when first introducing Extreme Programming, and this is a common goal of all Agile methods. This is achieved through several strategies:

• Requirements are defined and implemented throughout the project, making it trivial to accommodate changes. The next section below discusses this in more detail.
• Providing frequent feedback via working software mitigates many of the risks of traditional development projects.
• Prioritizing user stories and first implementing the ones with the highest value / highest risk maximizes the return on investment and mitigates a number of common risks.
• Often Agile projects explicitly allow for the project to be stopped or brought to a close at any point if the business owner determines that there is no benefit in proceeding with the remaining requirements.

One of Mike's though-provoking points was that using an Agile method is a risk-mitigation strategy that mitigates many of the common risks associated with software development projects.

Deriving instead of Fixing Scope

One key aspect of project management is managing the iron triangle of scope, cost (budget), and time (schedule). In a traditional waterfall project the scope is defined first, the effort required to implement this scope is then estimated, and finally the budget and time required are derived from this estimate. This approach is maintained throughout the project: controls are often put in place to minimize changes to the scope and changes that are deemed necessary then typically require adjustments to the budget and/or schedule.

Fixing the scope up front is inherently flawed due to the nature of software development:

• Business requirements almost always change over time. I have seen statistics mentioned on the order of 1% change in requirements per month.
• Software development is inherently a learning activity. The business typically gains clarity about their requirements as they are analyzed and implemented. Insight is also gained into how the solution / system can best meet these requirements.
• One technique from lean software development is set-based concurrent engineering, which aims to defer decisions to the last possible moment when the most information is available. This helps ensure that the best possible decision is made and hence minimizes waste caused by bad decisions (one of the main objectives of lean). Fixing scope up front requires making decisions at the worst possible time – when the least is known.

Agile addresses this problem by making scope flexible. While an Agile project can (and usually does) start with a high-level backlog of features or epics, the specific user stories selected for implementation are determined throughout the project, iteration by iteration. I have heard some say that Agile makes the project scope easy to change, but in reality the scope is not being changed at all – it is being defined throughout the project. The total scope achieved in a project is hence a function of the project schedule: the more iterations and releases available, the more that can be done. Going back to the triangle of scope, cost, and time, this means that time is the main variable being controlled, from which budget and scope can be derived.

Conclusion

I really enjoyed the clarity of thinking Mike brought to the topic of Agile project management. Considering that Mike has given this presentation at major software development conferences that require $$$ to attend, I really appreciated having the opportunity to see it for free in my home town. I am a little surprised that there are not more people taking advantage of these opportunities. If you live in the Edmonton area I strongly encourage you to attend the Agile Edmonton meetings.

Why do I feel that the release when ready strategy is generally best? The objective behind creating software is to have it fulfill a function, and to do this it must work properly. My definition of ready software is essentially a more precise way of saying that the software works. If the software does not work properly, why would you release it prematurely? There are a variety of factors responsible for the large amounts of premature software being released:

• Politics: A mandated budget or release date with no basis in reality or an arbitrary reduction in the schedule after it has been estimated are both problematic. In fact, such practices could be considered a fourth release 'strategy': release by management fiat. A more subtle case when politics has a negative impact is when it is onerous to change the budget or release date due to the bureaucracy and paperwork involved.
• Fixed Resources: There are situations where the amount of time or budget is fixed and cannot be changed. One example is software changes due to new legislation that comes into effect at a certain date, such as the recent change in the start time of daylight saving time. Startups often have limited funds, and need to have a software release to market before that money is exhausted.
• Competition: There is a commonly-held perception that being first-to-market is a competitive advantage, and this belief causes marketing departments to push for accelerated release schedules.
• Demand for Features: For both commercial and enterprise software, consumers and users generally demand more features over quality. After people start using the software and discovering problems, then they might begin to demand higher quality. Even then, sometimes the users are not the purchasers, as is the case for most business and enterprises software. This demand for more features influences development teams to include just one more feature rather than spend the time necessary to ensure the software is ready for release (i.e. via code reviews and testing).
• Ignorance: Managers who do not understand software development may come to believe that the software is ready to release when it really is not. This is a common risk of producing software prototypes.

These factors can make it difficult to impossible for a development team to apply the release when ready strategy. It is possible, however, to adapt to a release by schedule (or budget) strategy while maximizing the odds of the software being ready. To do this, you first must understand project schedules - in particular how the interrelated factors of time, resources, scope, and quality affect the schedule. Releasing software when ready implies that the quality is high, and a release by schedule strategy implies that the time is fixed. Adding resources is one option, but this is ineffective in the short term (due to Brook's law), difficult to accomplish quickly, and it does not help when the budget is fixed. This leaves scope as the single factor remaining. The key then is to carefully manage the scope throughout the entire development effort in a variety of ways:

• Prioritize requirements and features into must-haves, important, and nice-to-haves. Work on the highest priority features first.
• Structure and organize features into self-contained units to make it possible to drop features that cannot be finished by the release date.
• Fully complete features before moving on to new features, especially as the release date draws near. This means that the work activities should not be structured by technologies or application layers, but by end-to-end functionality. For example, rather than working on the database persistence layer first for all the features, and then turning to the business logic and user interface, do all three layers for a single feature only.
• Track the progress on each feature according to whether it is ready for release or not. This means that a feature is not done when the developer is done coding, but is only after it has been reviewed, tested, and all the serious defects eliminated. This implies that you do not wait till the end of the project to do all the code reviews and testing. Tracking progress by ready-to-release features allows you to still release working software if you run out of time by dropping all the incomplete features.
• Define a project milestone sufficiently in advance of the release date for making the final decision as to what features will make the release, and which features will be dropped. This allows the time required to remove dropped features from the code base or disable them and to perform 'final' testing on the release candidate.

While the above points can help deal with a fixed release date, I feel it is far from the ideal situation. I believe the best approach is the release when ready strategy. You can still have a target release date, but make it flexible. You still aim for that release date using the points above for managing scope, but making the date flexible allows you to take a more rational and balanced approach. As the release date approaches, you can decide whether to cut features or push out the release date. During final testing, if too many defects are being found, you can decide to spend more time improving the quality of the software and push out the release date.

I generally do not like operating in crunch mode, and I think it should be avoided whenever possible. The time 'saved' while in crunch mode is spent plus more afterwards reacting to and cleaning up the problems that the crunch has introduced. This is especially true for enterprise business applications, which are typically expected to be used and maintained for years. In this context, forcing a crunch mode to make a release a few weeks earlier is a questionable strategy. I have heard many stories of what I consider artificial crunch mode, where the imposed time constraints causing the crunch are arbitrary, frequently imposed by management for apparently no rational reason. Poor project management sometimes leads to crunches due to problems like overly optimistic estimates. Even with the best managers, however, crunch mode can still happen due to changes or events imposed by third parties like senior management, marketing, or the client.

If we cannot entirely eliminate crunch mode, how then can we lessen its negative impact? In my article on understanding project schedules I described the four factors that determine a project schedule: time, resources, scope, and quality. In crunch mode, the time and resources are typically fixed and insufficient for the amount of work to be done (the scope). I believe the main priority is to avoid taking shortcuts which comprise quality, as that is the most expensive to rectify afterwards. The best strategy is to minimize the scope as much as possible. While it is seldom possible to cut entire features, it is often possible to negotiate on specific aspects of each feature. Often slight simplifications in the requirements for a feature can greatly reduce the effort required. A related approach is to accept a certain number of low-impact defects in the application. This is often much less risky than rushing to fix these defects and possibly introducing new problems.

There are many good reasons why developers need to understand project schedules. When the project manager asks you how long it will take to do a task, the process of creating an estimate is essentially like creating a project schedule. As a senior developer, you might have junior developers working under you, and now have to provide estimates for their tasks. Junior or senior, poor decisions made by developers as they design and code the software can significantly increase the time spent on a feature. Developers ignorant of the schedule are more likely to negatively impact the schedule because of this. Often there is pressure to complete the project quicker - perhaps the customer wants the software sooner, or the project manager wants to finish 'early' in order to look good. The result can be an unrealistic or impossible project schedule imposed on the developers. The consequences are increased stress, overtime, and missed milestones. Understanding project schedules can help you negotiate a more reasonable schedule.

Project schedules depend on four inter-related factors: time, resources, scope and quality. Time is how long it will take to get the work done. Resources are the people that actually get the work done - the developers, testers, analysts, etc. Scope is the amount of work that needs to be done. Quality represents all aspects of quality concerning the software and the project, the most obvious of which is the defect rate.

These factors are inter-dependent: you cannot change one without affecting the others. For example, what if your project is scheduled to take ten weeks, and you are suddenly told it must be done in seven? You don't get more people (resources), nor can you eliminate some features (scope) or reduce the quality. Since you cannot change any of the other factors, you cannot change the amount of time required to complete the project. Sometimes people think that the project schedule is the reality, when it is actually a forecast that tries to predict what the future will be like. If conditions change, then you can update your schedule. But you cannot arbitrarily modify the schedule: this will cause it to diverge from reality and make it useless or even harmful.

In management books, it is common for quality to be left out as a main factor and instead be treated as an aspect of scope, leaving just three main factors of time, resources and scope. (See for example Rapid Development by Steve McConnell, page 126.) This is a reasonable choice that produces a simpler model. However, I prefer to have quality be a separate factor on its own. When project time lines are arbitrarily shrunk and the project finishes earlier, it is often because the quality of the software has been sacrificed in order to meet the aggressive deadline. By making quality a fourth factor of equal standing with the others, the trade-off between time, resources, or scope and quality becomes more apparent. To me, quality represents more than just the defect rate: it also includes the non-functional, implicit software requirements such as usability, maintainability, and scalability.

Any change to the project schedule typically involves a trade-off between two or more factors. You can reduce the time required to complete the project if you reduce the number of features to be delivered. If you want to implement more features, you can add more resources or increase the time required. If half-way through the project you lose a developer, you'll either need to increase the time required till completion, or reduce the number of features.

I created an applet called the Management Diamond to visually represent the relationship between the four factors of project schedules. This software is available to run or download from my Software page. This software is strictly for educational purposes, and is not meant to be accurate. It uses a constant, linear relationship between the four factors.

In reality, relationships between the factors are not always linear, nor do they stay constant throughout the project. If the quality is poor - many defects or difficult-to-maintain code - instead of saving time you will spend extra time due to the overhead imposed by the poor quality. At the start of a project, adding people will help you get more done in less time. But near the end of a project, Brook's law states the opposite: "Adding manpower to a late software project makes it later". Brook's law comes true when the overhead spent by existing project resources in training the new additions to the team is greater than the contribution provided by the new people. In essence, while you have increased your resources, you have also increased your scope to include some new work - train the new people.

As software developers, we have limited control or influence over the number of people available for the project or the time available to complete the work. Often, even project managers have little control over resources and time. Lowering quality below a certain level hurts rather than helps. But scope - the remaining factor - is one we can play a significant role in determining.

The requirements phase of a project is the best time to control or reduce the scope. As requirements are being gathered, we can provide guidance on the level of effort required for each requirement. We can also suggest changes that reduce the level of effort, often with limited or no impact to users. With this information, the customer can make intelligent decisions about the value of each requirement in relation to the effort required. If resources or time is limited then this is the best point in the project to reduce the total effort required by controlling the scope.

Once construction begins and we are designing and coding individual features, we can still have a major impact on the scope. Often the requirements we are working from are sufficiently vague that we have several options for how to proceed. The more elaborate and complex the solution we choose, the longer it will take. The difference between the time required for the simplest versus the most elaborate solution can be several orders of magnitude. Rapid Development (page 332-333) has an excellent example of this. For a project to create a charting program, there is a requirement to support polymarkers (symbols like squares, circles, etc. that indicate positions on a graph). The requirement does not address what size these polymarkers should be, or whether the user should have control over the size. The simplest solution is to define constants in the code for these sizes, thus providing no ability for them to be changed. Time required: a few minutes. One of the most complex options is to provide a user interface for the user to specify the size of each of the polymarker shapes. Time required: a week or more. This tremendous variance in scope arises from a seemingly trivial aspect of the original requirement - the polymarker sizes. A developer unaware of the impact on the project schedule may by default choose the more complex solution - this is a natural bias for many developers. Combine this with similar decisions on other features, and the project will likely end up far behind its original schedule.

As software developers, our actions impact the project schedule, and we in turn are affected by the constraints imposed by the schedule. Understanding project schedules - the four factors of time, resources, scope, and quality - is therefore a necessity for us as professionals. To learn more about project schedules, I recommend the book Rapid Development by Steve McConnell.