Skip to main content

Author: Heather Mylan Mains

Is Agile the Plastic Bag of Methodology?

As a child of the 70’s, I remember the shift from paper to plastic bags. In my memory, the shift happened because of the destructive process to create paper bags and plastic was a better choice.

It was more cost effective for businesses, they took less space to store, cost less, and you could carry more with them. They were a better value for everyone. The cumbersome, tree-destroying, expensive paper bags were no longer viable options. Stores would offer both for some time, but the default was plastic. Since that time, plastic bags have caused more concern than the paper. Now we know they are destructive to our oceans and animals, they don’t compost well, create lumps of trash, and are difficult to recycle. There is a shift in thinking on plastic bags happening now. I was recently in Hawaii and shopped at a Target store. I was surprised to find no plastic OR paper bags; I had to buy a fabric bag for 99 cents! At Subway in the Minneapolis airport last month, they paper wrapped my sandwich, no plastic! These experiences got me thinking about shifts in thinking. I see parallels in the adoption of Agile in organizations to the plastic to paper shift.

In consulting, I am often parachuted into the middle of projects. I see stressed resources doing more with less, confusion about what a system does, and a lack of process or system documentation. Since agile, even less documentation is available. The thinking that the cumbersome BRD, literally paper-intense, is no longer needed and is replaced with a lighter story card that costs less and offers more value is like the paper/plastic thinking. The adoption that a user story is only the start of a conversation and eliminates the need for more documentation than the story itself is dangerous. Some user stories are so sparse it’s impossible to understand what is needed or what is completed. However, the team knows through their conversation, and the working software is delivered. End of conversation, signed, sealed and delivered, right? Nope, it’s just a new beginning.

The idea of light documentation is appealing to me. I agree that many project documents are too much documentation. Teams can be very effective working closely together with a shared understanding and not need the BRD heavyweight document. Consider that teams are more fluid today than ever. People are changing teams, jobs and companies more rapidly than in the past. Agile teams that are working well and understanding the detail that isn’t documented aren’t staying together for years and years to manage the changes that always happen in organizations. The same is true of business resources. The Bureau of Labor Statistics published median employee tenure of 4.2 years in January 2016 down from 4.6 years in January 2014. Given this change in resources, months or years after the software is delivered, requirements are not clear in the documentation. Meaning is missing, and the resources that implemented the solution have changed. That’s not a new problem for organizations, however this thought that documentation is not needed compounds the problem.

Before I outrage any readers, I offer this as a thought provoking idea, not a definitive statement of fact. Is agile the plastic bag of methodology? Thinking that Agile has no documentation or only a story reminds me exactly of the plastic bag phenomenon. It’s lighter, less expensive and we can get more value in not using the cumbersome paper bags (BRDs!). Agile as a mindset is different that the adoption of agile, or fragile/ wagile/chunky waterfall or whatever iterative hybrid is being practiced.

I know agile is a mindset more than a methodology or SCRUM process or tool. However, some practitioners seem to have forgotten this. I have heard this phrase more than once, “We’re agile, we use JIRA and everything.” It makes me scratch my head and belly laugh simultaneously. Using JIRA isn’t agile! They don’t get it, and something isn’t connecting. JIRA isn’t a requirements tool, it’s intended to manage work, and that’s great. However, for the analysis process, I need to create visuals and models and describe current state and future state. I need the context of where we are and where we need to go. This is important documentation, and it won’t be in JIRA in a single story! Where is the analysis documentation kept? Is this being skipped and discussed then moving straight to the story? I know some teams are deep in the ‘all in plastic’ thought process. “Let’s not write it down after we talk about it. We’re agile!” Other teams are still struggling with finding the right mix and are in the ‘triple paper bag safe’ thought process, holding on to the project initiation documents and requirements BRDs in triplicate while writing stories in a tool.

Somewhere in the spirit of the manifesto line ‘we have come to value working software over comprehensive documentation,’ there is a disconnected practice for some teams. There is documentation needed because someone will need to know what the system needed to do, what it does, and how it is working, without looking only at the code. Perhaps I am old-fashioned? Perhaps I should get with the times and see the value in the plastic bag and stop thinking I need some paper occasionally? Perhaps thinking needs to change to find the fabric bag equivalent for requirement documentation?

I envision a shift soon for organizations. There will be a realization that documentation is missing, non-existent and that it’s creating problems for teams. When there are changes needed to systems and processes and the only way to find out what is happening is looking at the code because the documentation isn’t there, the team has moved on, and the business doesn’t know the answer. Let’s think about what can be done to find the happy medium between paper and plastic and a right sized fabric bag!