Once Upon a Time, in an IT Department Far, Far Away
Project Manager Fred – Herbie, where does Defect #24601 stand?
Developer Herbie – I rejected it and sent it back to Ellen.
Project Manager Fred – Why? What was wrong?
Developer Herbie – It isn’t a Defect! It was built to spec. It says to sort by name in the Requirements. That is what it does. The “Defect” now wants the ability to sort by only Last Name, also. We can’t because the name is one field, not two. It isn’t a Defect!
Business Analyst / Quality Assurance Tester Ellen – The requirements stated that the data needed to be sortable by the different fields. It didn’t ask for the name to be one field. The business needs to sort by first and last name in order to be usable. It is a “Defect” that needs fixed, or I can’t pass the User Story.
Developer Herbie – This is the first I’ve heard of this “New” requirement. I’m tired of getting stuck with all kinds of “Defects” that aren’t “Defects”. Why are we constantly changing requirements?
Business Analyst / Quality Assurance Tester Ellen – I don’t know what to tell you. If you didn’t understand the requirements, you should have asked. Your screen is unusable without the fixing the “Defect”.
Developer Herbie – You mean without the requirement change.
Project Manager Fred – Either way, let’s get it fixed.
To Defect or not to Defect?
OK, if you’ve ever worked in software development, this scenario probably doesn’t seem far off from something you’ve experienced. One of the major recurring issues in software development is the divide between the Business and Development. So, should this situation be a “Defect” or not?
But, before you answer. . . . Are we really asking the right question?
The Defect is in the Eye of the Beholder
Herbie - In this example, the resistance to calling the change a defect is a symptom of the larger problem. It is obvious that Herbie feels that having a defect given to him is a “negative”, something that was pointing out what he did “wrong”. On top of that, Herbie doesn’t think he did anything wrong. It was never in the spec. It isn’t a defect.
Ellen - Ellen wrote the requirements, working with the business stakeholders. She also tested the User Story. It was obvious to her that without being able to sort by first and last name, it wasn’t usable by the business. It needs to be fixed. It is clearly a defect.
Fred - Fred needs the screen done by Tuesday and needs the business stakeholders to be happy. He doesn’t care what it is called, but needs it changed.
Don’t Cure the Symptom
The fight over whether the change is a “defect” is the symptom. The problem is communication and interaction. This story is my favorite story that illustrates this issue. In the late 90s, I was on a large project team that was having major communication issues and finger pointing between the developers and the business. The project manager had an all hands meeting and put that story up on the projector.
The best business analyst in the world can’t write requirements that include every parcel of data the developer needs. Furthermore, even if they did, the business would still want to change things after it is built (because they often don’t know what they want). Likewise, the developer is always going to have questions, no matter how good the requirements were written. So, what to do?
The answer is . . . . Communication.
Communication, Process, and Methodology are the Answer
In the Agile process, much more so than the Waterfall process, communication is prioritized over documentation. The closer and more frequent communication between the Business Analyst and the Developer, the better the process is. This communication can take many forms, depending on the organization, geography, and processes. On smaller scale projects when teams are co-located, informal communication throughout the development iteration works well. Any time the Developer has a question, the BA/QA can answer it. Also, the Developer can show the screen/interface/etc. while they are developing it, to get early feedback from the BA/QA.
However, teams aren’t always co-located and individuals are too busy to be available all the time. In these cases, the list of questions by the Developer and/or the list of changes/feedback from the BA pile up. Hmm, what mechanism would allow these changes to not get lost and enable the project to scale, while still providing communication early and often. . . . . . . How about Defects?
I am an advocate for using Defects for anything and everything that needs changed, apart from the original User Story, itself. Break the stereotype that a Defect is a “negative thing” and the senseless, time wasting arguments about whether something is a change, an enhancement, or a defect and whose fault it is . . . . 90% of the time, it doesn’t matter. A Defect is a tool. A Defect is just another communication method that is lightweight, to the point, leaves a paper trail, and has a process for “fixing” and “testing”. Communication early and often through the development cycle, as advocated in the Agile Methodology, is the key solution to this issue and writing Defects can be another powerful form of that communication.
