We know that many people misunderstand what the Agile approach to software development is all about. Even (sometimes especially) those who purport to be Agilists themselves. Take the first Agile princple: "We value Individuals and Interactions over Processes and Tools." Its very common for those not familiar with Agile methods to wonder "where has my favorite practice/tool/role gone?" Their uncertainty doesn't diminish when the response they get takes the form of "That's not Agile, sorry." This is not what the first Agile principle means at all. It doesn't mean, "we've discovered a new process that puts yours to shame." It means "No Process or tool (even one commonly used by Agile methods) is going to help you succeed if it isn't applied in the context of invidiuals solving problems faced during their interactions."

So to help remind everyone that the Agile movement isn't about trading one set of dogmatic practices for another set -- and thus either exciting or frightening people depending on whether the new set includes their preferences -- I am reprinting here some advice I gave one of my fellow ThoughtWorkers who was faced with one of these questions from a client co-worker.

The question asked was:

"Where do Process Flow type diagrams fit into the picture from a Agile approach?"

My response:

They fit wherever and however they are useful. An Agilist's goal is to solve problems, not to either prescriptively define a process, or to create a framework where each tool in the toolbox is given a slot in the process.

The above question is typical of people who think process and tools before people and interactions (i.e. non-agile) -- they sorta assume the solution before clearly articulating what the problem is -- I have met avowed Agilists who act this way too.

I see diagrams and documents of all types as communication tools. Communication is between people, not between a person and a spot in a process plan. If I have a communication problem, I consider all communication tools (and "tool" means more to me than "software product") and ask myself which of them will help. Anything is fair game. Anything.

Its a common mis-perception that Agilists are opposed to using certain tools or process points, and predisposed to others. If they really grok Agile, practitioners are focusing on people and their interactions, improving how people work together, and using tools that effect this, not trotting out their favorite gadget or practice -- or carving out a role for themselves.

I caution all of us to guard against becoming counter-dogmatic. Just because we have found tools and practices useful in the past does not make them automatic selections for our next engagement. Just because we have found things un-useful in the past does not make them inappropriate later on. We should consider them -- in response to our needs -- but not automatically implement/avoid them "because it worked/didn't work before" -- unless of course, our goal is to become another process bigot like those we challenged when embracing Agile in the first place. ;-)

So the first thing I would do when someone asks me a question like the above is to ask them a question: "Who wants to know more about the process flow?" My next two questions (out loud or in my head) will be: "How does a process diagram help?" and "Would something else work better?"

Then I might be able to answer their question.