The Agile Manifesto, Part 2: Individuals and Interactions
This is part 2 of my series exploring the Agile ‘Software Development’ Manifesto. For part 1, check here.
In this section, we’ll be looking at the first ‘value’ contained within the Agile Manifesto:
Individuals and interactions over processes and tools
There’s a lot to unpack in these seven words, so buckle up.
In Robert C. Martin’s presentation, The Future of Programming, he describes a shifting industry, moving from older, experienced, disciplined, professional workers who didn’t require much management or process in the 1960s to young, inexperienced, undisciplined, college graduates in 1970 and beyond. It was an industry in tremendous growth, experiencing a doubling of programmers every 5 years from 1970 to 1995. An industry perpetually in a state of inexperience, with half of all developers always having less than 5 years of experience. These developers needed heavy management and process.
By 2001, when the Agile Alliance met in Snowbird, Utah, we get a sense of how this room of software development experts felt about the state of the industry. Jim Highsmith describes in his History of the Agile Manifesto that agile practices would lead to “a developer community freed from the baggage of Dilbertesque corporations”. These organizations are described as having a “‘fixed’ process mindset”, “imposing of irrational demands through imposition of corporate power structures”, creating “make-work and arcane policies”, and “pushing process for process’ sake”. Clearly, there was frustration with the status quo. At the conclusion of their two-day meeting, there was a call for values and culture. A focus on organizational models based on people and collaboration.
As you read through the twelve principles behind the Agile Manifesto, there are several statements that stand out with regards to valuing individuals and interactions (with added emphasis):
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Looking at these statements in aggregate, you see a group of individuals tired of typical controlling, authoritarian Theory X management techniques and hoping for a shift to a more empowering, participative Theory Y management style. And it’s interesting to note that even Douglas McGregor, who first explained Theory X and Theory Y in his 1960 book The Human Side of Enterprise, felt that Theory Y was the superior management model.
An industry dealing with inexperience through processes. A room of experts chafing at organizational rules. Could both sides be right?
Based on the Dreyfus Model, we know that novices work best when given recipes and rules to follow. And experts, with their full understanding of the big picture, work best through intuition. Experts can create rules for novices to follow to help elevate their performance. But as the Dreyfus brothers uncovered in their research, if you require an expert to follow these same rules, you end up reducing the performance of the expert significantly. Clearly undesirable! So, both approaches need to be utilized to get the best results.
Ten years after McGregor’s book, John J. Morse and Jay W. Lorsch published a paper, Beyond Theory Y, re-examining Theory X and Theory Y. They discovered that each management style had situations in which it produced good results but not in others. What worked well in highly repetitive, short-term manufacturing tasks did not work well in unpredictable, long-term research tasks, and vice versa. There was no universal one-size-fits-all best approach to management. This led to a Contingency Theory of management: tailoring the organization to fit the variability in tasks and people.
As Malcolm Gladwell explains in his 2004 TED talk, Choice, Happiness and Spaghetti Sauce:
People in the cooking world were looking for cooking universals. They were looking for one way to treat all of us. And there’s a good reason for them to be obsessed with the idea of universals because all of science from the 19th century and much of the 20th was obsessed with universals. Psychologists, medical scientists, economists were all interested in finding out the rules that governed the way that all of us behaved. But that changed, right? What is the great revolution in science over the last 10 to 15 years? It is the movement from the search for universals to the understanding of variability. Now in medical science, we don’t want to know necessarily just how cancer works. We want to know how your cancer is different from my cancer. Genetics has opened the door to the study of human variability.
There isn’t one perfect approach. There are different approaches that suit different situations perfectly.
But what has happened today? Organizations have settled on a new universality, and they have named it “agile”. It is not the agile described by the Agile Alliance back in 2001. It is a new “fixed” process that all members of an organization must adhere to without consideration for variables. Organizations are following a cargo cult of rituals taken from agile processes, hoping it will lead to success. But rituals are not about successfully completing business tasks. Rituals are about feeling safe, soothing anxieties, connecting with others, and maintaining social order.
Sometimes the process works, and sometimes it doesn’t, and no one knows why.
As Robert C. Martin further describes in his presentation The Future of Programming, businesses embrace agile project management processes, often Scrum, but they don’t understand the necessary technical disciplines. “An efficient business discipline coupled to an undisciplined engineering team will very rapidly make a mess.” Martin Fowler describes in his post, Flaccid Scrum, that businesses adopt Scrum principles and practices, but that progress is slow due to introduced technical debt. “For many people, this situation is exacerbated by Scrum because Scrum is process that’s centered on project management techniques and deliberately omits any technical practices.” The intended use of Scrum is to pair it with appropriate technical disciplines; Scrum won’t make for a successful project on its own. Experts know how to do this but may be blocked. Novices will need guidance.
In the end, I think the Agile Alliance got it right. The various processes and tools serve as a palette of options that can be applied in different situations. Leadership needs to understand these options. And then a very important thing must happen: the correct approaches must be applied to individuals and interactions for the tasks in your organization. It’s not enough to pick the one-blessed universality. Figure out how to get the best performance from novices and from experts, not by treating them the same but by giving them what they need. Consider the variables and use approaches that can enable the best performance for the situation at hand.