In the rush to complete a project, teams often make hasty decisions, including decisions about which features will be included when the product is released. Rather than making quick decisions, a team should defer a critical decision. Especially if they might learn more throughout the project that will help them make a better decision. In this week's column, Mike Cohn explains the importance of taking advantage of the new knowledge project teams acquire and how this allows them to make better decisions by deferring them.
Almost every project I encounter has made a grand effort of sorting the system's requirements into various piles based on priority. Perhaps there are piles for High, Medium, and Low priorities. Or perhaps requirements are separated into Mandatory, Desirable, and Optional piles. The Dynamic Systems Development Methodology (DSDM) includes something it calls the "MoSCoW Rules," which derives its name from the categories into which its practitioners sort requirements: Must Have, Should Have, Could Have, and Won't Have.
We use these multi-level prioritization schemes because doing so makes us feel better. When we prioritize something as "optional" we don't feel as though we're telling the customer "no." When we say that a product Could Have a particular feature included in it, we probably believe that it might. We convince ourselves of this even though our personal experience reminds us that on most projects we're happy just to deliver the Must Have requirements.
Unfortunately for our customers and project sponsors, many of them still believe us when we say that a project may include the optional features. After all, the feature isn't "out." It's just optional, which means there's a chance it will be included. However, just as my mom put me off as a young child with a non-committal "We'll see," we all know that a feature relegated to the optional pile is extremely unlikely to be released with the product.
The problem with prioritizing this way is that there is only Now and Not Now. Or, in project terms there is only In and Out. In most situations, there is no point in prioritizing work in any more detail than "here is what we'll work on now" and "that is what we won't work on now." To prioritize at a finer level or in more detail is to forego opportunities to adjust plans and priorities based on what we learn during the project. What the team learns in February may affect what should be worked on in July and August. If that's the case, why plan those months in January?
Since every day on a project affords opportunities to acquire new knowledge, the better we can take advantage of that new knowledge, the better our projects will be. Sixty years ago Nobel laureate F. A. von Hayek wrote about the importance of the use of knowledge. He wrote, "If we possess all the relevant information, if we can start out from a given system of preferences, and if we command complete knowledge of available means, the problem which remains is purely one of logic." Hayek was addressing a different planning problem but his argument remains valid.
When undertaking a software project we suffer from each of the problems Hayek identified:
- We do not possess all relevant information. We are often missing critical information about the domain, about the technology we will be using, about how well team members will work together, about specifically what it is that we are building, and so on.
- We cannot start from a given set of preferences. We often know remarkably little about the true preferences of our prospective customers and users.
- We do not have complete knowledge of available means. We do not know how productive each developer will be. We do not know the quality level each will attain. And we do not know to what extent (if any) the team will gel and individuals will transcend their normal levels of performance.
As Hayek says, if not for those problems, the challenge of planning could be reduced to purely one of logic. Because our knowledge is imperfect, knowledge and learning play important roles