Project work ranges from definable work to high-uncertainty work. Definable work projects are characterized by clear procedures that have proved successful on similar projects in the past. The production of a car, electrical appliance, or home after the design is complete are examples of definable work. The production domain and processes involved are usually well understood and there are typically low levels of execution uncertainty and risk.
New design, problem-solving, and not-done-before work is exploratory. It requires subject matter experts to collaborate and solve problems to create a solution. Examples of people encountering high-uncertainty work include software systems engineers, product designers, doctors, teachers, lawyers, and many problem-solving engineers. As more definable work is automated, project teams are undertaking more high-uncertainty work projects that require the techniques described in this practice guide.
The traditional Project Management (waterfall, also known as plan-driven) approach is linear where all the phases of a process occur in a sequence. The approach depends on predictable tools and predictable experience. Each and every project follows the same life cycle which includes the stages such as feasibility, plan, design, build, test, production, support, as shown in the figure below.
The entire project is planned upfront without any scope for changing requirements, such as PMI’s PMBOK, and PRINCE2 are all rigid and highly controlled. They outline distinct stages for project planning from start to finish and assume that you have all the requirements and information you need upfront.
Agile is considered to be the more modern type of software development strategy, as it was designed primarily to counter some shortfalls of the more predictive waterfall methodology. It is a software development model that encourages the continuous iteration of development and testing in the entire software development lifecycle of the project.
When a traditional system focuses on upfront planning where factors like cost, scope, and time are given importance, the agile approach gives prominence to teamwork, customer collaboration, and flexibility. As requirements specifications change, the agile team can remain mobile and able to respond to those changes. However, that doesn’t necessarily mean that the adaptive planning strategy is always better than a predictive planning strategy. Let’s compare these two project development strategies in further detail.
Waterfall project management is a more predictive planning strategy that utilizes specific steps and milestones to control the process. A predictive planning strategy may fail when confronted by significant project specification changes or customer modifications, but it will also be more likely to generate the anticipated result. Agile methodologies can be more susceptible to project evolution and scope creep, whereas waterfall strategies will create a more consistent final product.
Waterfall approach is a sequential process that is broken into a number of stages. The development team needs to complete one phase before proceeding to the next development phase. Typically, there are 5 phases in the waterfall development process which are listed below:
High-uncertainty projects have high rates of change, complexity, and risk. These characteristics can present problems for traditional predictive approaches that aim to determine the bulk of the requirements upfront and control changes through a change request process. Instead, agile approaches were created to explore feasibility in short cycles and quickly adapt based on evaluation and feedback.
Agile rejects these traditional project management methodologies as cumbersome, restrictive, and unsuitable for the new era of speed. Agile project management is iterative and aims at constantly incorporating user feedback and continuous releases with every iteration of the software development project as shown in the Figure above. Every task output is a product you’re selling to stakeholders. Team and work structures are designed around creating things that are directly useful to the customer or client.
The following table summarizes many of the differences between Scrum and traditional project management models.
| Categories | Traditional | Agile |
| Development Model | Traditional | Iterative |
| Focus | Process | People |
| Management | Controlling | Facilitating |
| Customer involvement | Requirements gathering and delivery phases | On-site and constantly involved |
| Developers | Work individually within teams | Collaborative or in pairs |
| Technology | Any | Mostly Object-Oriented |
| Product Features | All included | Most important first |
| Testing | End of the development cycle | Iterative and/or Drives code |
| Documentation | Through | Only when needed |
Traditionally change should be avoided on software projects because of the high perceived cost late in the game, while agile software development understands that changes are inevitable and that investing in detailed plans is not practical. This is clearly expressed in one of the four values from the Agile manifesto:
“Responding to change over following a plan”
Agile challenges this notion and believes the cost of change can be relatively flat as shown in the Figure below:
According to the 2011 CHAOS Manifesto from the Standish Group, Agile projects are three times more successful than Waterfall projects. The graph below shows the specific results reported from a study conducted based on projects executed from 2002 to 2012:
