09 Feb A Comparison of Agile and How to Run Successful Projects (Ten Steps)
PM360 Consulting is a company which specialises in Project, Programme & Portfolio Management (P3) solutions and this is widely recognised as one of the pre-eminent business skills of the 21st century, because of the complex and constantly changing competitive business environment that demands a professional and reliable approach to change and delivery solutions. We have a product set – a series of templates, tools, techniques, knowledge and expertise – which has been developed over the last thirty years. “How to Run Successful Projects” – Ten Steps®) method is based on 30 years of research on the best practices of successful projects as against the poor practices of failed projects.
A Comparison of Agile and How to Run Successful Projects (Ten Steps)
The Agile methodologies for planning, managing, and executing projects have been utilized for approximately 20 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 method “How to Run a Successful Project” as it has been taught by PM360 Consulting for the past 20-plus years.
THE FOUR VALUES OF THE AGILE MANIFESTO
1.We value Individuals and Interactions over Processes and Tools
PM360 Consulting 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
PM360 Consulting 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
PM360 Consulting 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
PM360 Consulting 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
- 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.
PM360 Consulting has always taught that customers appreciate tangible demonstrations/proof of both current progress and projected future success.
- 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, PM360 Consulting 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.
- 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.
PM360 Consulting 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.
- 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 principles of the PM360 Consulting process.
- 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.
- 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 PM360 Consulting 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.
- Working software is the primary measure of progress. Delivering functional software to the customer is the ultimate factor that measures progress.
PM360 Consulting would restate this slightly to say, “Completing deliverables per plan” is the best way to measure progress.
- 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.
PM360 Consulting 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.
- Attention to technical detail and design enhances agility. The right skills and good design ensure 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.
- 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 PM360 Consulting classes.
- 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.
PM360 Consulting 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.
- Regular reflections on how to become more effective. Self-improvement, process improvement, advancing skills, and techniques help team members to work more efficiently.
PM360 Consulting is supportive of a “Lessons Learned” process to be utilized throughout the life of a single project, and then leveraged across future projects.
Article written by Padraig Friel PM360 Consulting 9th February 2022