Sfrgttk

I am struggling to understand what the authors of the agile manifesto mean by "processes and tools" in the first agile principle.

Could you provide an example where such entities pose a problem at the expense of "individuals and interaction"?

I worked in a project in the past which was the lively example of this value... but the other way round: Tools and processes over individuals and iterations.

So, one way to understand this core value is to exactly look at it by applying a kind of Reductio ad absurdum and answer this question:

How does a project that values processes and tools over individuals
and iterations looks like?

A few tips:

• There's a single person that, by talking to only a couple of people, defines the process the 100+ people team needs to follow


• People are enforced to follow the process. Even if the process says that you should never use acceptance criteria (*I know you guys were already using, but some are not, so I want everyone to work equally*)


• Tickets are closed because they were not properly tagged / managed / updated


• The senior management is dragged into several hour discussions about how to tag a specific work as a task or a story


• People invest 5 minutes to understand a requirement and 55 minutes to make it fit into "as a user, I want to, so that" format


• Once a requirement is written by business, it's then handed over to the senior analyst, and then to the functional analyst, and then written in Jira. No questions can be raised. Or they can, but won't be answered


• (derived from above) zero communication between people implementation a functionality and the people expected to use such functionality


• Teams are enforced to follow a unique communication path


• People are more focused on ensuring the burndown propers burn down regarless of the amount of business value delivered


• People brags about the incredibly high (and constantly increasing!) velocity... with items being delivered to end users every quarter

The list could go on and on, but I believe the idea is clear:

• Processes and tools is important, but ensuring there's proper, open, candid communication between everyone* in the team is more important.


• Worth to also notice that forcing people to fit into a working model for the sake of following a model is also an agile anti-pattern. Agile is about experiment. Scrum is not for every team. And you can definitely work with Scrum framework (daily stand ups, retros, etc.), without being agile. And that's very dangerous.

* Everyone: From the developer that joined a few weeks back to the end user, going through the product owner, program manager or any other senior role.

Some examples of where processes and tools can be problematic:

• Giving a team a long requirements specification but then not being available to answer any questions they may have on it.


• Having people spend a considerable amount of their time completing forms on a tool, even though the information gathered is rarely used.


• A team urgently needs help from a specialist, but they can't get it straight away as they have to follow a long-winded process.

And some examples of where individuals and interactions are effective:

• A Product Owner explains a difficult and complicated requirement to a team and answers all their questions on it.


• A team asks another team for help and they quickly respond.


• An external customer visits a team and gives them a detailed description of how they use their product.

The first principle (value) in the Agile Manifesto is

Individuals and interactions over processes and tools.

This manifesto explains that the communication between the team members are most important that the tools and techniques we use to deliver software.

Valuing people more than processes or tools makes sense, as it is the people who respond to the needs of the mission and execute a task successfully. If the process or the tools drive the task, the team could not be responsive to change and would less likely to meet the mission’s goals. By communicating to the team what they are doing and why, you show respect for the people you work with and you will find that the morale of the team will vastly improve. This builds a unification of understanding and greater team cohesiveness.

Valuing people more highly than processes or tools is easy to understand because it is the people who 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.