What quality means for Developers (please read Testers, Analysts, Dev, Ops…) in an Agile team is definitely an endless talk. I could write tons of lines about it but I can also tell you that having the discussion is an excellent start. Too many teams rely only on the process and not the practices. In Scrum for example we do not prescribe any engineering practices but the most performing teams are implementing a lot of them in order to deliver a high value product on a long term basis. It’s a fact.
So, how do we define quality ?
If you look at Clean Code‘s first pages you will see this : “The total cost of owning a mess”. Please read it, print it, sign it and display it on your wall. In only one page and one chart Uncle Bob sum it all. We have all experienced this in projects once. When we start compromising the code maintenability to be faster in delivering features. Until it’s too late to fix the mess. In agile projects we call this technical debt. Technical debt is a whole, not only the fact that the code is a mess. In general, when you have some the product backlog is also a mess in general. So, quality is finally a sum of good technical choices taken at every step of the software development. As a team it’s your responsibility to envision your architecture, take time to think of every choice but also admit the fact that it will evolve, move, live.
My Basic definition of Quality
- A Working Software continuously delivered to Users
- Good Technical choices implementing a maximum of the quality attributes : extensibility, maintenability, testability, security…
- No tolerance for bugs in production
- Being able to manage the debt
Don’t forget the principles !
Back to basis. Do you remember the agile manifesto? Yes you read it once. Now let’s look at some principles we probably forgot that will help us regarding quality.
Continuous attention to technical excellence
and good design enhances agility.
Simplicity–the art of maximizing the amount
of work not done–is essential.
The best architectures, requirements, and designs
emerge from self-organizing teams.
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
In a following post we’ll go deeper in those principles and see how difficult it can be to implement them.
