Agile's Amigo: Process

Stuck in flight delays at the Airport in the last few days, I was sitting at the Gate near the corner of a terminal where I could see through the glass windows the crew that was using the back doors along with the customer service representatives answering the stranded passengers and interacting with the flight crew for boarding preparation. Simultaneously, maintenance crew was inspecting the plane, another group loading the baggage, and yet another group fueling the plane. None of these various groups were visibly communicating among each other at the same time but the whole flow seems so orchestrated. If getting the plane to fly were to be considered as an agile project, then, the tasks associated with checks and balances is so much grounded in process which made me reflect on some comments by a few agile practitioners that there is no value in process documentation.

It is true that Agile Manifesto associates a higher value to “Individuals and interaction” over “processes and tools” and “Working software” over “comprehensive documentation.”  But does Agile truly suggest not having any process to follow or ignore writing any documentation? Let us challenge the agile purists then why is Agile so heavy requiring a process to capture user stories to have some minimum qualifications emphasizing the INVEST principle and backlog entries to follow a DEEP property? Why the developer can’t be left to interpret what should be developed instead of requiring to also understanding how it should be tested?  One may then associate that such silo-ed thinking may lead to failures from waterfall to repeat requiring collaborating using the daily sprint and using the agile dashboards for communication.  In that case, let us reflect further.

1. If projects are successful because of people, then, let us also accept that not all people absorb and consume information at the same pace even in a self-organized team – requiring at least some level of process enforcement such as the same repeated questions used to uproot challenges in a daily sprint. Isn’t this some level of process?
2. Even from a pure engineering and development standpoint, then, why is Agile putting such an emphasis on Refactoring going down to the level of documenting specific smells (Agile terminology indicating a symptom of a problem) collapsing classes to simplify object inheritance design, long parameter list, and even recommendations of how much should be in a specific try/catch block? Isn’t this substantial documentation of processes to be used in agile projects?

Most of the contributors to the agile manifesto came from a strong technical background with a focus on developing IT projects. The logical breakdown of thought process is inherent in the IT discipline. Yet, these practitioners carefully drafted the four manifesto statements where processes, tools, comprehensive documentation, contract negotiation, and following a plan were not considered effective or essential. To those agile practitioners avoiding creating documentation or valuing following a process, let us emphasize that Process is the Agile’s Amigos!