I recently saw a post on LinkedIn and with it there was a communication between business and developers. The conversation went like this:
Business: “How long will the project take?”
Creator: “About 6 weeks”
Business: “We don’t have that time…I need it in TWO weeks”
Creator: “OK, we will do our best in that time”
And here is a cool video it was also referencing:
Truth is, as a software development team, we can accomplish almost anything in a short amount of time. So much of the timeline comes down to the desired quality of the product and functionality we are working on. If we release too early, we lose out on a lot of functionality and quality. But if we release too late, we could diminish the overall quality of the work we have completed.
As a QA Analyst, I find that I could continue testing new functionality over and over again, reaching deep into the scenarios that we have created, and possibly reporting more and more bugs as I test. The more time that I spend on new functionality, the more bugs I find, the more quality my team and I produce?
The Quality Bell Curve
This concept got me thinking about the possibility of a quality bell curve, where the project timeline matches the normal distribution of the curve. As the project begins to when the project is released are the two ends of the curve, and the middle describes the most advantageous quality enhancements our team could make.
For all intensive purposes, I understand that is not how the bell curve works, as with the curve, the middle is where you’d like to be, but I’m merely using this as a visual representation of a timeline from left to right. Although, it is possible that we could correlate the actual bell curve to the production of our products, where the middle area is the best quality, but maybe for another time. Back to the timeline approach.
If we interpret this as a timeline from left to right, then we can apply different moments in time to the appropriate areas of the curve. And remember, with bell curves, the left and right ends don’t ever actually touch the line, which we will call 0% quality.
Story time. We have a project timeline of six weeks from today when we’ll release to production, and we just sit down for the first meeting.
Let’s call the left most point the initial business meeting. This is where the idea begins and the initial conversation happens. The quality of the project begins to build, but at this point, fairly slowly. No work has begun on the project, but only plans for how to build out the idea.
Soon after, the UX designers have begun building out actual mocks (chicken scratch or high res) that assist in the meetings, and thus our quality of the project has increased, but not a lot yet, as there is no functionality built out.
Now we get the project into the hands of the development team, who, for example, is able to develop the entire project in two weeks time. The QA team and all other participants (usability testing, dba structuring, etc) has all had their active parts in the development process and the functionality is complete and tested. At this point, we would be near the top of the bell curve, if not standing on the peak. Everything is complete, tested and verified, and ready for production. However, the release is scheduled for another 3 weeks out. This is where the quality could begin to decrease.
As the time increases between new functionality being tested, and the release date, the quality has a chance to decrease. Perhaps it’s because the market shifts and the demands are no longer as high. Or maybe it is due to the decrease of knowledge and support for this functionality, so the release may come with some additional hiccups. Whatever the reason, I think it’s important to recognize the value of the project timeline and ensuring that we are able to release at the most valuable time.
I’ll keep this part brief. I was thinking of a bunch of different curves that could also describe the development process as a timeline.
The Learning Curve
The learning curve is another possible reflection of the development process timeline, where as the work has not started, there is no value or quality added. Once the project begins, a ton of quality and value is added very early on, but as time continues and you plateau, the increase of quality is difficult, as testing just becomes ensuring quality vs increasing quality.
The 45 “Curve”
Another possible example is when the work begins to when it’s released, there is a constant increase of quality and value added to the project. I don’t necessarily agree with this approach as often times there is slow points to the work and this does not account for those times.
The Story Line Curve
My last, and most colorful curve comes from elementary school, where as the story continues, the quality begins to grow. It hits that optimum time to release where quality is at an all time high, yet the release date is scheduled for a while out still, so quality can begin to diminish slightly. However, with this curve, there is a maximum decrease in quality over time, because it is still new functionality nonetheless.
I could be swayed to this one also, but the reason I lean on the bell curve is because the timeline of a project is not precise, in that the timeline could be years for a given project, and therefore quality will truly begin to sink for the new features. The story line curve doesn’t account for the extended timeline in it’s representation.
Well that’s it, curves as it relates to quality of product development. What could I possibly think of next?