When it comes to software development, there is a lot that goes into this one principle that is critical to agility. Let’s take a quick look at a fictitious scenario that reflects all too many actual experiences.
You are a development manager for a company that is launching a new product, and everyone is excited to be starting fresh. However, this fresh start doesn’t mean that unlimited funds are available. It has been made clear by the executive steering committee that a marketable product must be produced within one year.
And after some initial wrangling a high-level feature set is targeted. Even though it is understood that the likelihood of everything making into the first release is small, there is a quiet expectation that most of the feature set will make into the first release. This concerns you, but you are comforted by the fact that you have a team of young, energetic, eager-to-please developers and testers who are up for the challenge.
They come out of the gate fast. New features are developed rapidly and it looks like you are in for clear sailing. And it is, for a while. Unfortunately, during the latter half of the project the team begins to struggle. It seems that every day testers are finding more and more defects. Your brief situational analysis:
- The developers can’t keep pace – defects are being reported faster than they can be fixed.
- Addressing all of these defects is taking time away getting the remaining feature set finalized.
- You don’t understand the root cause of the defects, but the following concerns flash through your mind: Have these defects been there all the time, undiscovered until now? Is the team getting tired and perhaps a little sloppy? Are there greater issues with the underlying design of the software itself, causing what should be unrelated areas to break when new functionality is added? A combination of all of these?
- While you would like to dig into these issues and take corrective action that will benefit you and your team in the long-term, you have another consideration. The business wants what they want.
You are taking a political hit because some of the desired features were dropped from the release, despite the expectation being set at the outset that this would most likely occur. Adding to your woes is that while the quality of the product is deemed good, it isn’t considered great. Everyone knows – but doesn’t talk about – the downgrading of some defects at the end of the cycle so that the deadline could be met with the quality goal of “no critical defects” in the product.
In addition, your team has told you that they really need to clean up some of the code because they brute-forced the coding of the final features in order to meet the deadline, plus they now realize that some of the early foundational work could be improved as well. Your hope is that there will be time to address to these issues later, if the product proves to be a success.
And shortly after its release, the product turns into a success – good news! The bad news is that there is a demand for new features and an ever-increasing volume of defects being reported by customers that need to be fixed. Revenue growth becomes intoxicating and being “responsive” to the customer is equated to fixing their defects and shipping new versions to meet contractual demands. (e.g., “I’ll buy this product if you add x…”)