Agile vs Traditional Project Management

First, those making comparisons between Agile and Waterfall usually fail to define what those words mean. Let's start with a Consideration for Using Agile in DoD Acquisition, written in 2010. Section 804 of The National Defense Authorization Act, 2010, states, that software acquisition (including development) includes the definitions of Agile in a domain that developers Software Intensive System of Systems with mandatory Capabilities on the needed date, for the needed cost.

(A) early and continual involvement of the user;

(B) multiple, rapidly executed increments or releases of capability;

(C) early, successive prototyping to support an evolutionary approach; and

(D) a modular, open-systems approach.

Before Making Comparisons Between Agile and Traditional ...

Let's look at the Five Immutable Principles of Project Success, no matter the domain or context

Let's Look at a Recent Comparison and Focus on the Cons

This diagram came from a post from the PMI Project, Program, and Portfolio Management Group. The question posited was ...

?????? ?????????? ???????????????????? ???? ???????????????????? ???????? ?????????????????????? ?????????????? ????????????????????, ???? ?????? ?????????? ?????????????? ???????? ?????????????????????? ?????????????? ?????????????????????

The answer is yes and that was decided in the 1970s with the applications of Iterative and Incremental development processes described in Craig Larman's paper Iterative and Incremental Development: A Brief History

Cons of Waterfall – Which is used in the acquisition of IT systems, embedded systems (flight controls, cybersecurity) , but still is the boogie man of Agile

• Early Feedback is absent – not true in the mandated Iterative and Increment acquisition regulations from FITARA or any other credible project management process. Ask yourself how long are we willing to wait before we find out we're late? Sample progress to plan at ? that distance

• Response to Change is slow – this is the case when the business rhythm of the project fails to be compliant with the iterative and incremental processes. Answer the question: how long am I willing to wait before I find out I'm late? Sample the physical percent complete of the project at Half that duration decision point to provide the information needed to take corrective actions. If we're deciding if progress is being made every Friday afternoon, assess progress to plan on Wednesday after lunch.
• Risk of high cost if a requirement is missing – this may be the case when there are poorly formed requirements. Start with Capabilities Based Planning before defining any requirements. Answer the question: what capabilities do we need to accomplish our mission or fulfill our strategy? Then define what are the technical, operational, cost, and schedule requirements to implement those capabilities?

The foundation of success for any project in any domain, using any process is Don't Do Stupid Thing On Purpose

Cons of Agile

• Difficulty in assessing efforts required at the beginning – when you don't know what Done looks like in units of measure meaningful to the decision-makers, this is the result. And when this is the case, only the passage of time and consumption of money is the measure of progress to plan. Start with what are the needed capabilities? Define the Measures of Effectiveness and Measures of Performance for those Capabilities. Apply agile estimating tools. There are many. Galorath is one. Scopemaster is another. Start with Function Points – COSMIC.
• Difficulty in building a great design - start with a Capabilities Based Plan, which focuses on the planning, engineering, and delivery of strategic business capabilities to the enterprise. It is business-driven and business-led and combines the requisite efforts of all lines of business to achieve the desired capability as defied in TOGAF Version 9.2, section 28.1
• Can easily get off ttacke if goals are unclear - develop the Capabilities Based Plan following the TOGAF guide. Here's the framework for applying Capabilities Based Planning to SW Intensive Systems.
• Requires vigilant backlog and documentation maintenance – yes, keeping the documentation straight is part of any process when spending other people's money.

Bibliography

1. A Closer Look at 804: A Summary of Considerations for DoD Program Managers
2. Software is Never Done: Refactoring the Acquisition Code for Competitive Advance, Defense Innovation Board, 3 May 2019.
3. Defense Agile Acquisition Guide: Tailoring DoD IT Acquisition Program Structures and Processes to Rapidly Deliver Capabilities, Peter Modigliani and Su Chang, MITRE Corporation, 2014.
4. Parallel Worlds: Agile and Waterfall Differences and Similarities, CMU/SEI-2013-TN-021