More Thoughts on the Agile Manifesto

A post I made a few weeks ago created a disagreement with a Manifesto author.

I'd like to clarify what the Manifesto means in our complex adaptive software intensive system of systems domain from #5 to #13

In early 2001, in Snowbird, Utah, 17 people met to discuss the future of software development. The group's members shared frustration about the current state of affairs, even if they disagreed about how to remedy the situation.

They discussed several topics ...

1. Valuing people more highly than processes or tools is easy to understand because people respond to business needs and drive the development process. If the process or the tools drive development, the team is less responsive to change and less likely to meet customer needs. Communication is an example of the difference between valuing individuals versus process. In the case of individuals, communication is fluid and happens when a need arises. In the case of process, communication is scheduled and requires specific content.
2. Agile does not eliminate documentation but streamlines it in a form that gives the developer what is needed to do the work without getting bogged down in minutiae. Agile documents requirements as user stories, which are sufficient for a software developer to begin the task of building a new function.
3. Negotiation is when the customer and the product manager work out the delivery details, with points where the details may be renegotiated. Collaboration is a different creature entirely. With development models such as Waterfall, customers negotiate the requirements for the product, often in great detail, before any work starts.
4. Traditional software development regarded change as an expense, so it should be avoided. The intention was to develop detailed, elaborate plans with a defined set of features and with everything, generally, having as high a priority as everything else, and with a large number of many dependencies on delivering in a particular order so that the team can work on the next piece of the deliverable.

Putting The Manifesto to Work in Non-De Minimus Domains

1. Individuals and Interactions over Processes and Tools

The first value in the Agile Manifesto is "Individuals and interactions over processes and tools."

Valuing people more highly than processes or tools is easy to understand because people respond to business needs and drive the development process.

If the process or the tools drive development, the team is less responsive to change and less likely to meet customer needs.

Communication is an example of the difference between valuing individuals versus process.

In the case of individuals, communication is fluid and happens when a need arises. In the case of process, communication is scheduled and requires specific content.

2. Working Products over Comprehensive Documentation

Historically, time is spent documenting the product for development and ultimate delivery.

Technical specifications, technical requirements, technical prospectus, interface design documents, test plans, documentation plans, and approvals are required for each.

The list was extensive and was a cause for the long delays in development.

Agile does not eliminate documentation but streamlines it in a form that gives the developer what is needed to do the work without the minutiae until that information is required.

Agile documents requirements as user stories, which are sufficient for a software developer to begin the task of building a new function.

The Agile Manifesto values documentation, but it values working software more.

3. Customer Collaboration over Contract Negotiation

Negotiation is when the customer and the product manager work out the delivery details, with points where the details may be renegotiated.

Collaboration is a different creature entirely.

With the development of traditional models, customers negotiate the requirements for the product, often in detail, before any work starts.

This meant the customer was involved in the process of development before development began and after it was completed, but not during the process.

The Agile Manifesto describes an engaged customer who collaborates throughout the development process.

This makes it far easier for developers to meet the customer's needs.

Agile methods may include the customer at intervals for periodic demos. Still, a project could just as easily have an end-user as a daily part of the team and attend all meetings, ensuring the product meets the customer's business needs.

4. Responding to Change over Following a Plan

Traditional projects regarded change as an expense that was to be avoided.

The intention was to develop detailed, elaborate plans with a defined set of features and with everything, generally, having as high a priority as everything else, and with a large number of many dependencies on delivering in a particular order so that the team can work on the next piece of the puzzle.

The Heart of Agile Projects in any Business or Technical Domain

• Collaborate ? with all participants.
• Deliver ? Value on periodic boundaries.
• Reflect ? on progress, processes, and activities in a closed-loop manner.
• Improve ? through corrective and preventive actions.

These four processes, repeatedly applied on fine-grained boundaries, are the foundation of not only Agile Development and its Project Management but all good project management Principles, Processes, and Practices in any domain.

These are the foundation for answering the question of any approach to developing a software-based solution:

How long we you willing to wait before you find out you are late?

While collaboration is vital to all project work, it is a critical success factor in Agile projects.

This is the case since there are rarely any formal Project Performance Management Process Directives (PPMPD) stating how, when, and why each process step should be applied to the project.

The four actions defined here are also found in good traditional projects

One test of any set of principles to confirm they are not just platitudes is to invert the statement.

• We don't want to not to encourage collaboration.
• We don't focus on delivering anything.
• We never reflect on what we did. We move on and hope nobody notices what a mess we left behind.
• We have no intention of improving anything. We like it the way it is.

Those would be nonsense. In one sense, these four manifesto statements are platitudes of any good project management process.

In another sense, they are reminders of what good management is.

And we all know how hard it is to perform good project management processes.

More Agile Content

• Paradigm pf Managing Agile Development Project
• Agile Project Management and Earned Value Management
• The 12 Principles of the Agile Manifesto and Their Inversion
• Thought for the Day - Manifesto of Agile Development in Federal Acquisition

? "Comprehensive Guide to Agile Manifesto," Kate Eby, July 29, 2016.