Here’s a question that I believe generates some of the controversy around agile software development techniques versus waterfall techniques. If your team delivers fewer software features and functions but the software is higher in quality, are your user base and your company better off?
Agile teams often claim to deliver better quality software. I agree with that sentiment as long as the team follows core agile principles, in particular, “Customer collaboration over contract negotiation”. My experience with both agile and waterfall teams supports the quality claim. All software development teams have a strong tendency to over-commit. Agile teams figure this out fairly early in the development cycle and make adjustments. Waterfall teams figure it out much later and tend to sacrifice quality to stay on track.
Despite these tendencies, don’t rush to judgment in answering the question. Every major software company has rushed products to market knowing that the products weren’t ready. Here are a few examples:
- Apple: MobileMe and iOS Maps
- Google (and its hardware partners): Releasing “Beta” products and leaving them in beta status indefinitely
- Microsoft: Windows Vista
- RIMM: Blackberry Storm and PlayBook
Despite the problems faced by these and many other rushed products, there are good reasons for getting to market fast.
- Obtain first mover advantage
- Generate cash to continue product development efforts
- Respond to customer demand for new capabilities
- Respond to competitive threats
- Establish a position in a new market
The original question generates follow-up questions such as “How do you define quality?” and “What do I have to give up to get better quality?”. The questions are simple but the answers never are.
Agile teams are not immune.
Agile development teams also get sucked into rush-to-market tempests. The pressure to deliver something — anything — can reach stratospheric levels. When it does, quality often gets sacrificed. Unfortunately, customers, investors and the trade press share some of the responsibility for pressuring companies to release products too soon. You can have it fast but something else has to be compromised. That something is often quality.
For me, quality trumps features. I’d rather have a small and reliable feature set than a large and flaky feature set. The project team will eventually run out of time. The software will have to ship — ready or not. That’s why it’s so critically important to prioritize features and deliver quality results in each iteration.
Do you agree?