# On Agile Development, Design and Quality

_2016-03-28 · Pekka Hartikainen_

> 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 many 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 a weekly basis.

### Week 1

_Method 1 (more features, less quality): design → development → testing ≈ 5 days, 5 features, 12 bugs. Method 2 (less features, better quality): ≈ 5 days, 3 features, 1 bug._

**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 to be a faster way to test what sticks, compared to **method 2**.

### Week 2

_After two weeks — method 1: 10 days, 10 features, 24 bugs. Method 2: 10 days, 6 features, 2 bugs._

**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 — method 1 spends development on bug fixing: 5 days, 1 feature, 12 bug fixes (total 15 days, 11 features, 12 bugs). Method 2: 15 days, 9 features, 3 bugs._

**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 on something that could have been easily solved by one person in the first place.

_Two people notice a bug, report it to the developer and keep communicating about it before it is fixed._

**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.

https://pekkahartikainen.fi/blog/on-agile-development-design-and-quality