Difference Between Traditional and Agile Project Management

You have probably heard quite a bit of discussion about how Traditional Project Management differs so much from Agile Project Management. However, many Agile Project Management  concepts have been around for quite a while and several of them are found in Traditional Project Management, as well as in the A Guide to the Project Management Body of Knowledge (PMBOK® Guide). These include the Plan-Do-Check-Act Cycle, Progressive Elaboration, Rolling Wave Planning, Decomposition and Continuous Improvement. Although both Traditional Project Management and Agile Project Management are similar because they both share these five concepts in common, it is ‘how’ they are implemented that is different.

Plan-Do-Check-Act (PDCA)

Our first concept is the Plan-Do-Check-Act (PDCA) Cycle that was popularized by William Edwards Deming in the 1940s. This is a method used for managing projects and developing products that involves executing each of the four parts of the cycle iteratively throughout a project. Although both Traditional and Agile Project Management use the PDCA Cycle, Agile repeats this cycle in smaller more rapid increments than Traditional, often every two weeks. This allows the Agile project team more opportunities to adapt to changing priorities and requirements that the customer determines have the highest value at any particular time during Agile project execution. 'Plan' establishes the objectives and processes necessary to deliver results according to the specifications. Agile ‘Plan’ tasks include iteration planning and definition of acceptance tests. 'Do' implements the processes created to deliver the expected results. Agile ‘Do’ tasks involve day-to-day iteration execution. 'Check' monitors and evaluates the processes and results against the planned objectives and reports the outcome. Agile ‘Check’ tasks involve verification of results using acceptance tests. 'Act' applies actions to the outcome and modifies the processes to improve them before the next iteration. Agile ‘Act’ tasks involve holding retrospectives and performing planning for subsequent iterations.

Progressive Elaboration

Project Management. In the Traditional sense, Progressive Elaboration involves an iterative process of increasing the level of detail in a project management plan as greater amounts of information and more accurate estimates become available throughout the project life cycle. Progressive Elaboration for Agile project teams is a bit different because activities are not extensively planned at the project outset. Requirements are progressively elaborated from the ’Mile-High’ Level to the ‘1-Foot’ Level at varying times throughout the project and the Agile development  team focuses specifically on known project aspects. Throughout an Agile project, the team performs only those activities necessary to provide customer value, as specifically defined by the customer at any given time. Using Progressive Elaboration in this way on Agile projects forms the foundation for developing incrementally during the remainder of the project, with incremental product component deliveries at the end of each development iteration, and full feature product functionality at the end of each planned release. The main benefit of Progressive Elaboration in Agile project management is that the project team maximizes the amount of time spent on the development of high-priority features (or ‘must haves’) and minimizes the amount of time spent on low-priority features (or ‘nice to haves’).

Rolling Wave Planning

Another common approach used in both Traditional and Agile Project Management is that of Rolling Wave Planning. This is an iterative planning technique in which the work to be accomplished in the near term is planned in detail, while the work in the future is planned at a higher level. In Traditional Project Management this approach is used when insufficient detail of project requirements is available. On an Agile project it ensures that the process of planning is being conducted in waves, as the project requirements become clearer and the project complexities unfold. Agile by its very nature is adaptive and allows for adaptive planning without having to know the specific requirements of the entire project up front because these requirements and the priority of these requirements is ever-changing on an Agile project. High-level plans are created for the distant horizon at the project level, medium-level plans are created for the medium horizon at the release level, and low-level detailed plans are created for the near-horizon, which includes the next 2-3 iterations. On Agile projects, the level of requirements decomposition and the amount of time and effort spent creating more detailed estimates for these requirements will be dependent on the customer’s view of the importance and current value of the requirements at any given time during the project.

Decomposition

Both Traditional and Agile Project Management involve fulfilling customer requirements and include activities to fully understand these requirements so that the customer receives not just what they want but more importantly what they need. This is where the concept of Decomposition comes into play. This is an indispensable tool for all successful project teams, and is used in conjunction with the concepts of both Rolling Wave Planning and Progressive Elaboration. Decomposition is a technique used for breaking larger sets of customer requirements into smaller and smaller pieces until they can be understood and implemented by the development team. In Traditional Project Management the tool used for decomposing project requirements is the Work Breakdown Structure (WBS). The WBS is a hierarchical decomposition of the total scope of work to be performed by the project team to accomplish the project objectives and create the required deliverables. It is broken down into components that represent successive levels of detailed requirements to the lowest level, which is called a work package. Agile Project Management uses the same concept of Decomposition but slightly differently. In Agile, high-level requirements are first broken down into Features, which represent fully functional products or product components that are delivered at the end of each release. These Features are then broken down into Epic User Stories that are still fairly high-level and represent the major work for each Feature in the overall product being developed. Epic User Stories are then decomposed into successive levels of more Detailed User Stories down to the lowest detailed level of requirements on an Agile Project, which are Tasks. Tasks represent specific activities that need to be performed in order to deliver each Detailed User Story and are assigned specific resources and specific hourly estimates for the completion of these Tasks.

Continuous Improvement

Our last common concept, Continuous Improvement, has been a major component of both  Traditional and Agile Project Management best practices for quite some time. It refers to the fact that every project team member should constantly be thinking about ways to not only improve the quality of the product being delivered but also the processes that are being used by the project team throughout the project. The Plan-Do-Check Act Cycle, Total Quality Management (TQM) and the discipline of Six Sigma are all Continuous Improvement tools used in Traditional Project Management to improve product quality. Lessons Learned are used on Traditional proejcts to improve project processes. Agile Project Management also employs formal Continuous Improvement initiatives such as Just-In-Time, Kaizen and Value Stream Mapping. In addition, Agile principles and best practices by their very nature automatically include continuous improvement activities. Examples of this in terms of product quality include having the customer write the acceptance criteria for each user story, the use of Continuous Integration, and constant customer feedback during iteration reviews at the iteration level, as well as product demonstrations at the release level. Examples of this in terms of process reviews is the use of a Daily Standup Meeting where current roadblocks are reviewed and resolved, the use of a Process Improvement Log, and the review of issues in the Process Improvement Log at the end of each iteration during the Iteration Retrospective Meeting. Agile also takes Continuous Improvement one step further by incorporating people improvements through the use of self-organizing teams, cross-functional training and regular team-building activities.