Agile Project Management is widely used across lots of companies, especially in the IT sector and a lot have heard how different Traditional Project Management is from Agile.
Well, they still do have quite some things in common. Honestly, the major difference is not in the “what” but how these common things are differently implemented.
What do Traditional and Agile Project Management share?
There are five main concepts that are both valid in Traditional and in Agile Project Management. Such are Plan-Do-Check-Act Cycle, Progressive Elaboration, Rolling Wave Planning, Decomposition and Continuous Improvement.
Plan-Do-Check-Act Cycle
The Plan-Do-Check-Act Cycle (PDCA) is a project management method used to develop a product by iteratively executing all of the four pieces of the cycle. Both Traditional and Agile project management use this method iteratively. The difference is that in Agile Project Management the PDCA pieces are executed more often compared to in Traditional Project Management. Often this is during each sprint, which typically is every two weeks.
Progressive Elaboration
Again a massively used concept both in Traditional and Agile project management. However, in Traditional project management planning is taken way more ahead in time compared to planning in Agile. Hence, Traditional project management involves iterative increase of the level of details in the project plan as greater amount of details, information and more accurate estimates are available. Within the Agile approach Progressive Elaboration differentiates in the way that Agile projects are not extensively planned, not too much ahead. Requirements elaboration start from the very high-level of details iteratively deep-diving into greater details within different time periods and the agile team can focus on what is currently better known compared to the rest. Thus, the Agile Team can focus on what is particularly known to be wanted by the customer at the right time, hence, able to deliver value to the customer. This approach within Agile also allows for the iterative delivery of product increments at the end of each iteration and the delivery of a complete product functionality at the end of a release. Last but not least, a great benefit of Progressive Elaboration in Agile is that the team focuses their time on prioritised items and this increases the team’s productivity.
Rolling Wave Planning
Another often used approach both in Traditional and Agile project management is the so called rolling Wave Planning. The philosophy behind this iterative planning technique is that what has to be built in the short-term is thoroughly planned, whereas the long-term work is outlined on the high-level and detailed once it’s in the upcoming iteration. Compared to Traditional project management this approach is used not for it’s benefits, but only when there is insufficiency in the project information regarding the features, requirements, etc.
Rolling Wave Planning in an Agile project enables planning to be conducted in waves as more details are uncovered. In its roots Agile is flexible and adaptive, hence, it is possible to planadaptively and at the same time save the bother for knowing the specific requirement for the entire product till the end of the project’s life. For instance, in an Agile project what’s usually done is to create a high-level plan for the distant future features, mid-level plan is created to cover all for a release, and low-level plans are created for the short-term items, i.e. for 2-3 iterations at the most.
Decomposition
Traditional and Agile project management aims to understand the client’s needs and requirements, especially what the client really needs, and they both include activities to uncover those requirements so that the team is able to deliver to the customer what they wanted and of course what they needed.
Here comes the Decomposition as a means to an end in both project management approaches. It can also be, and usually is, used in conjunction with Progressive Elaboration and Rolling Wave Planning.
Now you know why Decomposition is an indispensable tool for every successful team.
In this case, the name speaks for itself. Decomposition means that the agile team approaches each requirement by decomposing it, in other words, breaking each requirement into smaller and smaller pieces until those pieces are clearly understood, achievable and possible for the development team to implement.
In Traditional project management, the tool for decomposition is called Work Breakdown Structure (WBS). In its essence, this is a hierarchical approach to decompose the total scope of the work within the project until its end.
In Agile project management decomposition helps break down the high-level requirements into features. These features are the so-called Epic level in Agile. These Epics are described but still fairly high-level, and then further decomposed into smaller chunks under the form of User Stories that are relatively low-level. Finally, User Stories are broken down into Tasks that are the lowest-level in detail and enhance developers do their job.
Continuous Improvement
The last common concept between Traditional and Agile development to be discussed in this article is Continuous Improvement. It has been a very important component in recent times and still tends to be.
Again the name speaks for itself what Continuous Improvement is. This is the approach to constantly and continuously strive for improvement. When I say improvement I mean it not only in the sense of code quality but also regarding process improvements, tools and techniques improvement, overall project deliverables improvement. There are several Continuous Improvement tools used to improve the product quality in Traditional Project Management such as Six Sigma, the Plan-Do-Check-Act Cycle, and Total Quality Management (TQM). When it comes to process improvement Lessons Learned is used in Traditional project management.
Agile project management on its side also employs some formal tools and techniques for product and process improvement such as Value Stream Mapping, Just-In-Time (JIT), and Kaizen. However, what’s more important here is that Agile principles and practices are in their nature, oriented towards both product and process improvement. For example, in an Agile environment key stakeholders are involved, often times the Product Owner is the customer themself, in other cases the customer writes the acceptance criteria for the user stories, the customer provides frequent feedback and participates in the iteration reviews, demos are frequently conducted, and the list goes on.
In conclusion, I want to say that both Traditional and Agile project management have their benefits and specifics so are applicable for different projects at different companies. However, it is inevitable to share some tools and techniques in common. Regardless of the similarities, they also strongly differ in their core philosophy and approach with Agile being more flexible and adaptable bringing value to market in a quick manner, compared to Traditional project management where planning way ahead is required thus less flexible and adaptable to changes.