Agile vs Fragile: What the Agile Manifesto means for processes and documentation

Part 14 in a series of 17. To start at the beginning, first read Agile vs Fragile: A Disciplined Approach or an Excuse for Chaos.

If you were to survey a group of very frustrated testers about why they have problems with their Agile teams, you would find that in almost all cases they get frustrated trying to get any documentation that helps them identify what to test.  Every time they request even minimal documentation, the development team pushes back and says that documentation isn’t needed because Agile eliminates the need to document. After all, Agile promotes “Individuals and interactions over processes and tools”.  They will tell the tester to just talk to the developer about what they are building and it will become obvious what the testers should be testing.

This push back on process and documentation is typical of un-enlightened Fragile teams. They mistake the principles of Agile teams as a unfettered mandate to eliminate all vestiges of process and documentation.  What they fail to realize is that Agile isn’t anti-documentation or even anti-process.  I think Jim Highsmith of the Agile Alliance very adequately states the purpose of documentation and process in the success of Agile teams.

“The Agile movement is not anti-methodology; in fact, many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment” Jim Highsmith, for the Agile Alliance

So what is Jim telling us? First, Agile isn’t against process. It is against non-value-added process that doesn’t help the team be more efficient or effective.  Process for the sake of process is stifling and will always limit the ability of a team to harness the creative genius of the team.  It is so easy to over engineer the process structure.  I know. I have often done it in my own career.  You become so rigid in your process that you attempt to address every potential failure point with process.  If you are building the Space Shuttle, this may be appropriate, but for a social media site this just may be overkill.  The key is to find the balance between process and freewheeling innovation.  If you are too stringent, you limit creativity and productivity.  If you allow too much freedom, you enable chaos, instability, and put the business at risk.  The problem in most Fragile teams is that they have no process, which almost ensures their ultimate failure.

The second thing Jim is telling us is that Agile isn’t against documentation.  It is against documentation that doesn’t serve a purpose in the delivery of the solution.  I began my testing career in Aerospace, and as such, I gained a great appreciation process and documentation.  It was obvious; you can’t build and launch a rocket into space, without a lot of documentation.  Without proper engineering drawings, it is impossible to manufacture and assemble the vehicle. Without proper software documentation, it would be inconceivable that you could accurately verify and validate that the vehicle will perform under all of the environmental constraints on the vehicle.  No one would argue that documentation is essential to the success of rocket science.  I know, I know, many of you are thinking, “relax, this isn’t rocket science”.  And while you are technically correct, you are fundamentally flawed in your argument.  While, yes you can easily see that your application doesn’t run the risk of failing in space where you can’t make corrections or recover from a failure, but what you fail to realize that your application is every bit as mission critical for your business.  If your applications don’t transform your business or make it profitable, then why even create them?  But, if as I suspect, your business runs on your applications, then the business can’t afford to have them fail.  The life of your business depends on them.  In this case, isn’t it important to have just the level of documentation that is necessary to ensure that you can accurately, quickly and successfully deliver the solution?  Fragile teams mistakenly believe that verbal communication is adequate to ensure that everyone is on the same page.  They believe because they had a conversation with a developer or with a tester that the recipient actually understood what they meant.  This is a farce.  If I asked each of you to draw a bug, each of you would draw completely different concepts.  Some a grasshopper, or a ladybug, or a spider (technically not a bug); and still others, would draw a Volkswagen automobile (sometimes referred to as a VW Bug); and maybe even a listening device for a phone like a wiretap.  This is because each of us is the sum total of our experience.  We each look at the world with a set of filters that are created from our backgrounds, our ethnic heritage, our education, our life experiences, and our prejudices.  We each apply that filter to what we see, read and hear.  If we have a conversation and we say we understand what is being conveyed, all we are saying is that we understand what we interpreted the message to be using our filter.  The only thing I can guarantee is that we absolutely interpreted it differently.  Documentation is a vehicle for ensuring that the interpretation gap is reduced.  Don’t create documents that are for history purposes, but are active documents that help the team reach success.

Agile processes and documentation should be limited to the minimum level needed to deliver quality in the fasted possible time frame.  In the next installment of the blog we will look the role of testing in the Agile framework.  In the meantime…Keep on testing!