The Agile methodologies for planning, managing, and executing projects have been utilized for approximately 18 years, although certain components now lumped under the Agile heading have been in use for a far longer period of time.
The Agile Manifesto (defining “Agile”) was developed in early 2001 by a 16- to 20-member group of software developers, and was a pushback against what they saw as flawed planning/controlling/execution sequences that they grouped together and referred to as the “waterfall” process. (The term, “waterfall,” simply referred to the look of Gantt charts, which, when activities were sorted by early start and/or early finish dates, showed graphically as a cascading list of tasks over time—resembling a waterfall).
Upon closer review of the various justifications for leaving “waterfall” and turning to “Agile,” most had their roots either in the improper use of standard project management methodologies, or in poor management/leadership practices in general. Both of these “reasons” for poor performance are a function of incomplete or missing training for those in technical leadership positions, not failures of the processes themselves. Unfortunately, Agile implementations suffer from the same problems today.
The Agile Manifesto comprised four Value statements and 12 Guiding Principles as shown below. Comments in italics beneath each Value or Principle indicate either their compliance or conflict with the Project Success Methodology (PSM) as it has been taught by PSI for the past 34-plus years.
THE FOUR VALUES OF THE AGILE MANIFESTO
1. We value Individuals and Interactions over Processes and Tools
PSM has always focused on a) an individual team member’s definition of the processes they follow, and b) how their activities interact with other team members’ activities.
2. We value Working Software over Comprehensive Documentation
PSM has always valued completed deliverables over documentation, although documentation may, in fact, be a key deliverable in some cases.
3. We value Customer Collaboration over Contract Negotiation
PSM has always focused on careful and complete discussions of scope and objectives between the team members and the customer, and the concise documentation of such discussions’ results.
4. We value Responding to Change over Following a Plan
PSM has always positively addressed the concept of expecting change, and the need for subsequent revising of plans to evaluate and assess the effects of such changes. NOT having a plan because of change is a bad management decision.
THE TWELVE AGILE MANIFESTO PRINCIPLES
1. Customer satisfaction through early and continuous software delivery. Customers are happier when they receive working software at regular intervals, rather than waiting extended periods of time between releases.
PSM has always taught that customers appreciate tangible demonstrations/proof of both current progress and projected future success.
2. Accommodate changing requirements throughout the development process. The ability to avoid delays when a requirement or feature request changes.
As stated in the “Values” responses above, PSM has always positively addressed the concept of expecting change, and the need for subsequent revising of plans to evaluate and assess the effects of such changes.
Note that the statement “avoid delays when a requirement or feature changes” is not at all strictly a function of the planning methodology, but primarily a matter of the technical skills and personal motivation levels possessed by the teams’ members.
3. Frequent delivery of working software. Scrum accommodates this principle since the team operates in software sprints or iterations that ensure regular delivery of working software.
PSM emphasizes completion of deliverables and sub-deliverables on time throughout the life of the program. Tracking performance on “Activities” on a regular basis ensures that all activities are being performed properly.
4. Collaboration between the business stakeholders and developers throughout the project. Better decisions are made when the business and technical team are aligned.
Collaboration and communication with the customer are key tenets of the PSM process.
5. Support, trust, and motivate the people involved. Motivated teams are more likely to deliver their best work than unhappy teams.
This is correct, but as a function of general leadership and management skills, not just Project Management methodologies.
6. Enable face-to-face interactions. Communication is more successful when development teams are co-located.
Face-to-face meetings during both planning and control are key tenets of the PSM process. Co-location is excellent, but even when team members are geographically separated, they should be brought together for planning, and meet virtually (Skype, Zoom, WebEx, etc.) on a regular and frequent basis to communicate and control the project.
7. Working software is the primary measure of progress. Delivering functional software to the customer is the ultimate factor that measures progress.
PSM would restate this slightly to say, “Completing deliverables per plan” is the best way to measure progress.
8. Agile processes to support a consistent development pace. Teams establish a repeatable and maintainable speed at which they can deliver working software, and they repeat it with each release.
PSM does not drive for a “repeatable and maintainable” speed; the emphasis is on completing activities per a schedule that meets commitments made to customers. The issues of repeatability and maintainability are issues that each functional area manager must resolve.
9. Attention to technical detail and design enhances agility. The right skills and good design ensures the team can maintain the pace, constantly improve the product, and sustain change.
This is correct, but as a function of technical leadership and management skills, not just Project Management methodologies.
10. Simplicity. Develop just enough to get the job done for right now.
This is correct, but as a function of general and technical leadership and management skills, not just Project Management methodologies. “The enemy of good enough is better” often is quoted in our PSM classes.
11. Self-organizing teams encourage great architectures, requirements, and designs. Skilled and motivated team members have decision-making power, take ownership, communicate regularly with other team members, and share ideas that deliver quality products.
PSM would say that properly managed teams are more effective than self-organizing teams. Self-organized teams always end up with a de-facto leader anyways, just one with no formal training or authority, which can be ineffective or dangerous or both.
12. Regular reflections on how to become more effective. Self-improvement, process improvement, advancing skills, and techniques help team members to work more efficiently.
PSM is supportive of a “Lessons Learned” process to be utilized throughout the life of a single project, and then leveraged across future projects.
Clint Padgett is president and CEO of PSI, a 36-year-old training and consulting company that works with Fortune 500 companies in team and project training—management by commitment. PSI’s experience comes from its use and implementation of its proprietary methodology, Project Success Method (PSM), which was “Agile before Agile existed.” PSI has trained tens of thousands of mangers around the globe in the use of PSM at companies such as Coca-Cola, Caterpillar, Celanese, W.R. Grace, CBRE, Duke Energy, Southern Company, Honeywell, Ingersoll Rand, CNN, and has been involved in every Olympics and FIFA World Cup since 1992. Padgett is a graduate of The Georgia Institute of Technology with a Bachelor of Electrical Engineering. He also holds a Master’s Degree in Business Administration from Duke University. His professional associations include the Project Management Institute, the Institute of Electrical and Electronic Engineers, and the Product Development & Management Association. In partnership with Forbes, Padgett released a new book, “How Teams Triumph” in April 2019. For more information, visit: www.projectsuccess.com