Agile software development teams have to assure that the products that they develop have sufficient quality. Management often also expect that they increase their velocity to be able to deliver more functionality faster to their customer. Several authors explored the relationship between quality and velocity and suggested ways to improve both quality and velocity.
Bob Galen wrote about the importance of software quality in respect to becoming faster in the blog post read my lips – agile isn’t fast:
Agile is a “Quality Play” that if you play the game with integrity, commitment, and balance, can become an awesome “Speed Play”. But it’s (speed) isn’t free…
If you don’t play it well, your agile adoption might even be slower than your previous approaches!
Teams have to commit to getting the work done in an iteration, which implies meeting all criteria in their definition of done:
Too many agile teams allow rework – bug repairs, completing test automation, refactoring, or poor designs escape the sprint to later. Even most of the agile tools allow for splitting stories to capture the work that was done in the sprint vs. the deferred work. I think this sends the wrong message to the teams. That skewing work beyond the sprint is acceptable.
Read my lips – it’s not, get everything Done-Done-Done!
Organization should not strive to become faster, but should focus on quality as Bob explains:
So the next time you hear someone talking about the speed implications of agile and letting their youthful enthusiasm get the best of them, please stop them. Try to explain that it isn’t a “speed play”, but instead amplify that it’s a “quality play that might be able to go fast”.
Tim Ottinger wrote about 14 Weird Observations About Agile Team Velocity. One of his observations is about the relationship between quality and velocity:
Although people often short quality to get things done sooner in the short term, velocity in all sprints is reduced if the quality of the code the team encounters is low.
In his blog post velocity is not a goal or target Stephen Haunts describes what can happen to quality when managers are setting targets for the velocity of teams:
(…) in order to deliver more points to meet the target, the team will sacrifice on system quality, which slows down the team in the long run and introduces technical debt. You are better off focusing on the quality of the system that you are building and the processes (continuous delivery and integration etc.) and the people building the system.
Software developers have to balance between velocity and quality as Blake Haswell explains in what is code quality:
There’s often a lot of external pressure to lean more towards the velocity side, however if you don’t pay enough attention to quality your velocity will grind to a halt and your project will come toppling down. Given that a project’s code quality determines how easily it can be adapted to changing requirements, the sustainable thing to do is to spend some portion of your time tending to your project’s code quality.
Blake provides a list of qualitative attributes that can be used to discuss code quality:
- Comprehensible. Code should be easy to reason about at all levels. Ideally, software should be so simple that there are obviously no deficiencies.
- Testable. Code should be written so that it is easily testable.
- Correct. Code should meet functional and non-functional requirements.
- Efficient. Code should make efficient use of system resources (memory, CPU, network connection, etc.).
In the blog post the symptoms of low internal software quality Hugo Baraúna explains how software can “deteriorate” due to changes, resulting in lower quality and reduced velocity:
Imagine you’re leading the tech or product team of a startup; you’re the CTO. You already launched your product’s first version, and it was a success. Your business model was validated, and now you’re in a growth stage. That’s awesome! But it has its costs, and it brings a new set of challenges.
The first version of your product is working, but the codebase is not in the shape you’ll need from now on. Maybe your team’s velocity is not as good as it used be. Your team keeps complaining about the code quality. The CEO and the product director want new features, and your current projections will not meet the business needs.
He provides a list of symptoms indicating lower quality that help you to decide if a rewrite or refactor is needed:
- Everything is hard
- Slow velocity
- Slow test suite
- Bugs that don’t go away
- Your team is demotivated
- Knowledge silo
- New developer ramp-up time is taking too long
How do you balance quality and velocity?