Csdrhrt

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

We are uncovering better ways of developing software by doing it and
helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools


• Working software over comprehensive documentation


• Customer collaboration over contract negotiation


• Responding to change over following a plan

That is, while there is value in the items on the right, we value the
items on the left more. Agile Manifesto

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.

This feels like just a different phrasing, but I find that it sometimes helps. When I look at the Agile Manifesto, I reading as the things on the right serving the things on the left.

For example, there are release approval processes. The intent of most release approval processes is to bring all interested parties to the table so that there can be transparency on what is being released and people can raise concerns in the moment. This is a process supporting better interactions between individuals.

Over time the process may drift from the needs of the individuals and no longer align. Now people show up to the call but maybe don't really listen. There's a lot of work that goes into making a release request from years of built up rules, but the whole process has become a rubber stamp. Now the balance has switched. Individuals are in service to a process that is no longer effective and interactions suffer for it.

So, applying the Agile Manifesto, we'd want to look at this process and ask ourselves how we turn it back around, either getting rid of a process that has outlived its usefulness or revamping it so that it once again serves the individuals and their interactions.

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 more important than 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 be 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.