If you ask the question what is agile in polite company you get a wide range of answers. I know because I have asked that question in polite and less cultured environments. Polite answers focus on ceremonies, people, mindsets, guardrails, or paths. The less than polite are usually a version that people are using the term agile as a form of gaslighting. Pushing aside the last group, at least for now, we are left with two categories of answers. The first focusing on process and the second on people. Both are right because both reflect different real-world contexts and different personal and organizational needs. Perception of “what” is agile, how you define agile, is heavily influenced by what you want from agile; the why of agile. This is true for practitioners as well as organizations which is why specific agile practitioners are more comfortable in some organizations and vice versa. As a consultant, I have seen a wide spectrum of definitions — all tied to the reason the organization is interested in agile.
Agile as a process or as an adjective is considered by some to be an oxymoron; however, the word simply means “a series of actions or steps taken in order to achieve a particular end” (Oxford Languages via Google). Agile techniques, frameworks, and methods are processes or collections of processes. People and organizations that want a process forward form of agile will express needs in terms of :
- Consistency
- Predictability
- Cost control
- Compliance
- Overhead Reduction
Many of these needs are reflections of the classic management mantra of “faster, better, and cheaper.” Organizations with these needs adopt frameworks and methods to provide structure. Jeremy Berriault, consultant and frequent contributor to the SPaMCAST states that where consistency and predictability are goals, consultants and organizations focus on executing the ceremonies in frameworks. Questions often are stated as, “are you doing?” rather than “are you getting value?” The assumption is that doing is highly correlated to value. A healthier process focus is reflected by Mellisa Greller who states that agile provides “guardrails to help teams find their recipe of success to deliver in a more predictable way.”
The second group defines agile in terms of people or a mindset. Freddie Clark III, product owner at Zirtue defines agile as “a mindset of chasing feasible goals with flexible exploration/execution.” His definition combines what people believe with the value of the outcome. At least until AI overlords appear, you need people to get work done. It is almost a truism that work will go more smoothly if you have the right people for the right job. If you have the right people for a specific piece of work. Agile’s focus on self-organization, fast feedback loops, and swarming aims to maximize the chance of getting the right people on a piece of work. Embedding product owners from the business into teams ensure the right work gets to the team. As Susan Parente, President of S3 Technologies, LLC (and frequent contributor to the Software Process and Measurement Cast) states, “Agile is a culture shift for the project team, stakeholders, and/ or organization.” Culture is a reflection behavior that brings the definition back to people. Nicole Derr, Agile Coach at LeanDog, sums the people forward definitions of agile as:
Harnessing the power of true teams and the ingenuity of the people closest to the problems to delight customers and improve business outcomes.
In the end, both sets of definitions are right and usable depending on the context. Allan Kelly, Agile Coach/Guide at Software Strategy, Ltd combines, people, process, and technology (the Golden Triangle) in his definition,
Ultimately agile is organizational learning; it’s about learning rapidly and turning that learning into action to create more effective teams. Learning about customers and problems we seek to address, learning the technology to create our solutions, and learning the processes and practices to do that most effectively.
Any definition of agile has to include nods to people and processes. Even with the right mindset it is impossible to be agile if you are trapped in the wrong process. The same is true for great processes and frameworks — without the right mindset, all bets are off.
This is not our typical Saturday fare, my editor (to whom I am related) ran her first marathon today in Harpers Ferry, West Virginia. The essay today is the first of three. The next installment will explore what drives a process versus a people-centric approach to agile. The third component will wrestle with why the moniker “pragmatic” has become code for half-assed.
We will be back, with Chapter 4 of Project to Product next week.
