“Individuals and Interactions over Processes and Tools”
This is the agile value that I most see people misunderstanding.
I recently came across a post from a Facebook group that demonstrates might perception. It is not my intention to expose the people involved, so I won’t make public the name of the group.
I will start by presenting some facts, and then I will analyze them.
FACTS
A guy who developed a tool to help write better user stories asked for people’s opinions, and some answers were really “interesting.”
“if the Team understands it…and becomes a shared objective…it is a quality US… Agile is a journey”
“Definition of Ready, I would say.”
“What about the team as a tool to validate the quality?”
“why would you do something silly like that? ran of out micromanaging tools and do not have something useful to do?”
And the top TWO:
“Automatic tool? HAHAHAHAHAHA you completely miss the point of working in Agile”
“If you mean software tool, simple answer, NO.”
ANALYSIS
From now on, I will present my viewpoint of why these opinions are biased and incorrect, based on the aforementioned Agile value.
I see two main trends of thought or arguments, with the first one being worse than the second.
First, the assumption that having a tool to help to execute agile processes is wrong.
Second, the assumption is that the agile team is the only source of knowledge because “agile is a journey.” So, they must fail and learn.
OK. Now, let’s start dissecting each one of them.
Let’s start with the first “argument.”
Myth #1: Having a tool to help to execute agile processes is wrong.
This one is a very silly one. The Manifesto says that
“Individuals and Interactions” are MORE VALUABLE than “Processes and Tools.”
Not that you must not use “Processes and Tools.”
Not using any process is a process. So, by definition, you will always execute processes. Period.
About the tools, it is very silly to imagine executing agile processes, having short-term delivery dates and a potentially highly volatile environment, and not using tools. Agile people use tools all the time: IDEs, Static code analysis, test automation frameworks, and so on.
Given this, what is the problem with having a tool to help people write user stories? For instance, is it “not agile” to have a tool to help you to identify Non-Functional Requirements? Or, is it “not agile” to automatically analyze the user stories in terms of the INVEST criteria (or some other heuristic)? Why would it not be “agile”?
I will elaborate more on my arguments in what follows while discussing the second argument.
Myth #2: The agile team is the only source of knowledge.
When people argue that it is enough to use the “Definition of Ready” and “whatever the team agrees,” in other words, they are saying that “the team has the knowledge or must acquire it through their personal experience”.
IMO, they are somewhat implicitly referring to the agile value of “Individuals and Interactions” and the 11th agile principle about agile teams being self-managed.
The assumption that, apparently, they make is that “since the team is self-managed, they know what is best for them.”
About this assumption, I have some points:
1) of course, upper management or any external agent must not tell the people how they should do their work. If some external agent forces the team to use any process or tool, this is wrong, according to the agile mindset. If there are organizational patterns or external conformity rules, such as being ISO 9001 certified, then the organization negotiates with the team on how to apply them. But, it is not my goal here to discuss these situations much.
2) I don’t think I have to point to evidence here that not all agile teams are composed only of experts who know the most efficient way of getting work done. So, in general, the assumption that “the team knows” is false. It might be the case for some teams, but not for all.
3) let’s talk about tools. Many agile teams use static code analysis tools to identify technical debt such as SonarQube. Let’s take the case of a static code analysis tool for identifying code smells, such as Blob (or God Class) or Functional Decomposition.
How does it work?
Based on metrics, algorithms infer if there are code smells based on rules. Simple like this. How are the metrics defined? How are the “rules” defined?
There are only three possible answers: humans, data, or both.
In other words, when you use a static code analysis tool, you are REUSING knowledge (from people or data) to help you be more productive and produce better-quality software.
4) Ask agile software developers (or any developer) if they use Stack Overflow, YouTube, books, or any other type of media to help them solve programming problems. Ask agile managers if they read books, participate in online forums, or whatever kind of media to help them solve management problems. OF COURSE, they do. Again, if you use Stack Overflow, YouTube, read a book, or whatever, you are REUSING knowledge from other people to help you perform better in whatever task you are about to perform.
So, when I see a comment such as “Yes if the Team understands it…and becomes a shared objective…it is the quality US… Agile is a journey,” the only thing that pops into my mind is:
Why would you want to mess up with something if you can learn from the experience of others?!
Before concluding, I just want to refer to the first five words of the Agile Manifesto:
“We are uncovering better ways…” Agile Manifesto
IMO, this means that the agile mindset is an open-minded one. It is about embracing change in product requirements, team dynamics, processes, and tools! Read Agile principle #12.
For instance, for the user story tool, it is not like I believe in “automating user story writing”, but I believe that such a tool can be seen as an extra opinion, an extra source of knowledge that has the potential to help the team to perform better.
I recognize that there is a risk that the given tool might be totally useless. And I think that it is OK if it ends up being useless. It is not a simple problem to solve. How many startups, research, and relationships are successful? Only a few! I believe that it is the nature of trying to solve complex problems.
But we will never know if it is useful if we don’t give it a try.
To summarize, my point is: don’t be a software person who does not believe that software can help you to perform better by “blaming” the Agile Manifesto. Open your mind to having tools to help you perform better. It is a reality for health, industry, education, and all domains I can think of, including software development, in all its dimensions!
It is possible to use such tools without violating the agile mindset.
Learn More
You can learn more about effectively applying Scrum by taking my Complete Agile Scrum Master Certification course at Udemy.
