Comparisons of Agile vs. Traditional Approaches

Can this discussion be condensed down to a set of graphs that illustrate the areas of “applicability” for both Agile and current best practices for project management, or “traditional” project management? Fortunately, the answer is yes, and the following graphs are offered in support of this response. The first graph illustrates the comparison of Agile, traditional, and other project management philosophies and methods when plotting two independent variables:

1. The size of the project team as a proxy for size and complexity of the project
2. The proximity of the team and project/product owner

These variable are independently correlated since the literature currently discussion both Agile project management philosophies and traditional management philosophies do not indicate that by choosing a team size automatically determines the proximity of the team and owner, or vice versa. From this graph, Figure 1, it can be seen that each philosophy and/or methodology has its area of ‘applicability’ as determined by the practitioners of the specific discipline.

What that reader should take away from this quadrant graph is that it shows why the application of traditional project management (the green area) just barely touches the applicability of the Agile methods. This would seem to show why Agile is enjoying such successes in the small team size within close proximity of the project owner while the more traditional project management methods had such a difficult time in providing the environment for success.

The reverse conclusion is that until the Agile philosophies and methods come to grips with distributed or remote located project owners and team sizes in the 25 to 75 range, (current research is under way to attempt such solutions) the Agile methods will do better when paired with projects where these parameters are the project characteristics.

Major Differences between Approaches

What are the major differences between the Agile philosophies and traditional project management? Figure 2, The Area of Applicability based on the Physicality of the Deliverable, or ‘Bits vs. Atoms’ illustrates where these disciplines have their best impact. This can lead to understanding where practitioners can best deploy particular philosophies and their associated methodologies.

The project manager or Scrum Master (each philosophy has differentiated roles and titles) will have to decide if their particular philosophy is the correct choice given the particular characteristics of the deliverables they have agreed to offer to the project owner. Can each particular practitioner be counted to be objective enough to accept the limitations and boundaries of their particular form of project management?

This is one of the questions that each organization must answer before deciding on a particular philosophy opposed to all others. An analogy of myopic perspectives comes down to this quotation by a very observant practitioner of management philosophies:

“If all the dogmatic practitioner has in his toolbox is a hammer, then everything must look like a nail; if not, than he will apply his hammer until it resembles a nail.” 

CJ Stoneman, 1989.

Agreements and Points of Contention

Organizations must first understand the areas that Agile and traditional project management excel in given their particular strengths and weaknesses. Then, they must decide if these two development philosophies can work in conjunction within the framework of the organization’s expertise and human resource talents. It is precisely because Agile and traditional do not overlap in major applicability that they can be made to peacefully co-exist in their appropriate environments. However, if an organization has already become the single philosophy provider, it would be efficient to limit the choice of engagements and projects to those that are within the solution profile of the chosen philosophy.

To believe that Agile or traditional can handle any type of project shows a lack of acceptance that each philosophy has its appropriateness in solving a subset of project issues and problems depending primarily on the type of deliverable being requested of the project. Agile has been shown is best applied to software deliverables where the lack of physicality and variation of requirements is handled via its light-weight approach to project execution. Traditional can best be applied to those projects where the physicality of the project’s deliverables demands a more formal, structured requirement definition and sign-off set of procedures.

Organizations depending on their size, scope of engagements, and desired professional image should be willing to limit their choice of projects to those where their expertise and skills are strongest – in similar fashion to a professional project manager knowing their limitations based on experience and knowledge. For an organization to become ‘co-opted’ or dogmatically blinded as to the appropriate application of each development philosophy, will in the end result in a troubled or misdirected project regardless of the passion of the project team. Remember the hammer analogy and maintain a more complete set of tools, not just a hammer.

Steps an Organization Can Take in Choosing a Project’s Development/Management Approach

1. Know the strengths, skills, and experiences of your project teams:
   1. Ensure properly trained employees in your philosophy choices,
   2. Ensure a mixture of skill sets from beginners to senior practitioners,
2. Review your OPA (Organizational Process Assets), and lessons learned for project expertise
3. Review your marketing profile to ensure it aligns with your philosophy choices
4. Review your engagement or project selection protocols for alignment with philosophy choice
5. Understand that one cannot be everything to everyone – know your limitations

We hope you have enjoyed this Agile series. Please leave any questions in the comments!