Ignoring quality can make agile development slow.
While agile development is common in many organisations, it is something that can be easily misunderstood. Individuals may nod and say they both know what agile development is, but may have very different perceptions of it.
The very common misunderstanding is, that developers “can now ignore quality and just throw it out there”. Of course, it depends on the functionality and situation, but often times sloppy quality in development can just slow the speed down.
Let’s say that there are two teams doing software development:
The first team uses method 1 and delivers as much features as possible in one week with more bugs
The second team uses method 2 and delivers a little less features with better quality.
Now let’s compare the outcome on weekly basis.
Week 1
Week 1 – everything seems to be fine
During the first week method 1 produces more features, but also more bugs. Despite the amount of bugs, there is more to test for the real users. This seems be faster way to test what sticks, compared to method 2.
Week 2
Week 2 — the bugs are starting to pile up
On week 2, the method 1 still produces more features and more bugs. Despite the bugs, more features are shipped. Everything still ok, right?
Week 3
Week 3 — bug fixing starts to take more time from method 1
On week 3, only one new feature is shipped with method 1, because part of the bugs has to be fixed. On the other hand, the method 2 is catching up, because there is better overall quality and fewer bug fixes. Also, the first method has produced so many bugs, that there are plenty of them left for the next week.
While the numbers are imaginary, you get the idea. Agile does not necessarily mean sloppy development and poor quality. It is far more important to decide, what to develop on any given week and do that with good quality. While doing sloppy design and development you may also create a company culture, where poor-quality work is accepted in the name of agile. That is hard to fix later.
Of course, some of the features are dropped, because they are not needed – that’s the whole idea of agile. But you will also have a lot of features that you will need anyway — consider sign up or user profile or such.
Poor quality creates a lot of unnecessary noise
When a feature is shipped and it does not work as intended, people in your own organisation will report it and wonder why it is that way. This creates a lot of unnecessary communication and reporting — and spending time to something that could have been easily solved by one person in the first place.
Three persons spending their working time with a bug that could have been solved in no time by one person.
Customers, business analysts, designers and other developers get involved and wonder, if the bug gets fixed and when.
Suggestion: work smartly, deliver quality
**I suggest that a better way of doing agile is to focus on quality, decision-making process and deadlines. **Although some feature might be “almost done” in one week, the real timeframe for completion might be up to six weeks because of the bugs. Many times it would be more straightforward to budget a little bit more time to that particular feature and ship it without bugs.