I often attack the Agile Manifesto. I am not a huge fan of it. It named Agile, but it named processes and theories that existed before the Agile Manifesto existed. There are parts I don’t think aged well, and there are parts that could be clearer. Instead of Organizational Agility, I am starting to think Organizational Lean Six Sigma is a better name or even Organizational Complexity Leadership. But Agile is the hot name on the block and I have SEO to consider, so Organizational Agility it is – even though that doesn’t make much sense when you place the Agile Manifesto in the equation with its focus on software development.

What Does the Manifesto Describe

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Notice that it states “continuous delivery” and not incremental delivery. For software, this might mean setting up and using continuous integration practices defined in XP. Maybe Kanban is the best choice with its continuous delivery flow. Increments can more practical for release purposes and for measurement purposes, they may not be practical for everything.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.

This is a Lean practice and it is meant to be adaptive. This is one reason why excessive inventory and/or overproduction is considered waste in Lean. You build too much and suddenly it becomes obsolete, who is left holding all of the obsolete work product? Someone paid for that work to be done and now it has to be discarded.

This is often thought to be solved or addressed by using iterative and incremental development practices, but it doesn’t have to be. It helps to have a delivery system set up so you don’t lose huge amounts of work with a change.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

The closest description you get to iterative and incremental delivery. It doesn’t specifically state it and it doesn’t define a consistent time period. The preference for the shorter timescale seems to, once again, indicate a continuous flow as the preferred choice. I think the intent is more one of creating inspection points for the current state of the product.

Business people and developers must work
together daily throughout the project.

This is meant to be a collaborative measure. Many Agile frameworks include a role such as Business Analyst, Product Owner, or some sort of business representative on the team for the purposes of trying to aid this type of collaboration.

Rather than define daily collaboration, I think a better approach is to meet with them as needed. If that happens to be daily, then daily it should be. Mandating daily isn’t very flexible, and before you know it you have 7 hours of meetings in an 8-hour working day.

I was on a “Scrum” team where I never actually met the Product Owner once. They weren’t actually practicing Scrum, they were just using Scrum names.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

On the surface, this one is hard to disagree with. In reality, I think it is an ambiguous statement. It seems to say that you only should find motivated individuals instead of giving them a reason to want to be motivated. Self-motivated people exist, self-motivated people can also have their motivation crushed. A self-motivated person won’t drive themselves infinitely no matter how they are treated. Motivated individuals rarely magically appear and remain that way without a reason to remain motivated.

I think the second half of this statement should be first, as in “Give the team the environment and support they need and trust them to get the job done; helping to create and maintain motivated individuals.”

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

This is an example of taking “Common Sense” and using it as a rule or guideline. Common sense is rarely common and rarely makes sense. I have written against this over and over again. (The Myth of Body Language and Its Importance in Communication, Hypocritical Situation of Low-Tech Solutions in Agile, Face-2-Face Communication May Not Be Needed, Open Offices Suck, Distributed Agile Teams and the Telecommuting Naysayers, Distributed Teams or Co-located Teams in Agile, Osmotic Communication: Flawed Communication Practices)

Seeing your face is more psychological reassurance than something that provides actual measurable value. In general, face to face might be better when comparing two teams of the exact same people and it won’t include all people. There are people who can function just find talking to you on the phone and not have to see your face.

It limits a lot of your options. You can probably build a better team by going outside of your limited region, and that team can perform better than a face to face team. Many of the claimed advantages of a face to face team are not actually proven, and in fact, some have been disproven.

Most of the entrenched beliefs on this are due to the psychological nature of spending our lives only working with people in face to face environments and not quite used to how distributed teams work best. They work differently than a face to face team and they need to be operated differently – The Watercooler Moments: 8 Tips for Remote Workers

Working software is the primary measure of progress.

This is very philosophically Six Sigma. Make sure what you build is built correctly. Make sure it aligns with your goals to determine the success.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

This is a human-centered approach to management. If you have to constantly implement overtime you are doing something wrong. Do the work you can, don’t work the people to death. Get more employees if it is an issue.

Continuous attention to technical excellence
and good design enhances agility.

This is a Lean and Six Sigma philosophy. If what you are building isn’t as good as it should be, modify the way you are building it. Make sure the processes you are using are the best processes you can use. Make sure what you are building is aimed at the overall goal of quality and business objective.

Simplicity–the art of maximizing the amount
of work not done–is essential.

This is a Lean practice. The goal is to reduce the wasted development and focus on what you need to do to get the most value from your work.

The best architectures, requirements, and designs
emerge from self-organizing teams.

This is a human-centered management practice with origins in complexity theory. In my opinion, this is the most important part.

This touches on several of the other principles. Motivating your teams, giving them more power over their work give, leading them, and improving them. It creates an environment that embraces innovation and non-standard thinking; as long is it is controlled and structured. It can help foster the creation of a true learning environment.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

This is a Six Sigma/DMAIC/Deming Cycle practice – continuous improvement. The entirety of Six Sigma seems to focus on looking at how you do things and how you work to make it better. This is the process improvement portion of Agile. You aren’t actually worried directly about the product/work output here, you are more concerned with ensuring you are using the best methods to create the work output.

Reflection

That is the Agile Manifesto as interpreted by me. It is basically Lean Six Sigma with some human-centered approaches to management with a focus on software development projects. Drop the software development, project management, and the strong requirement for face-to-face communication and it would perform a better model for organizational agility. It would be Agnostic Agile.