What are the priority quality practices?

Question

I have recently joined a small software development team that has 1 product with multiple external customers. There is no specific project management methodology or framework being used, so development is rather ad-hoc. From what I understand, there is an ongoing challenge in that there has been a pattern of each release exposing bugs that were not caught during development and the release must then be rolled back to fix the bugs before reissuing the release again. As a result, the team distrusts its own releases, and delays its releases to avoid this pain.

Currently, there is no dedicated QA or Testing person, but I think that is not necessarily a critical problem as while it would be ideal to have a primary tester, Agile teams should strive to be cross-functional. However the developers have been testing and approving their own code (I know...)

I want to create a prioritised list of quality practices that should be implemented to improve this situation. In priority order, what are the most important quality practices to address, can you give a prioritised list of what you would address first.

The most immediate thing on my mind is to:

1. Stop Developers from approving the testing of their own code.
2. Introduce Lean-Agile Scrum practices (I am a scrum master), particularly a Definition of Done (DoD) to include quality criteria, Sprint Reviews to demo and inspect completed code, and Retrospectives to plan quality improvements.
3. Start introducing TDD and practices from Working Effectively with Legacy Code by Michael Feathers.

What would you implement as a priority?

Answer 1

I'll try to raise various points in a few separate departments in the order I'd address them. Depending on what resources and support you have the effort vs benefit situation might dictate a different order.

Specifications

You need clear, complete current and correct specifications. It doesn't matter too much how many people are involved in getting business speak requirements turned into developer speak specification. Imporant is:

1. It get's done
2. It get's done properly
3. The responsibilities are clear
4. You have a single channel (if you have N devs all talking to M clients, stop)

Things that can help here:

• A product owner (mainly because of point 4 above)
• A definition of ready (to help with points 1 & 2)

Tests

You need reliable, repeatable and rigorous tests. I've worked as a tester in an environment that focused exclusively on manual testing. It's just not sustainable. As your feature set grows the testing needs grow exponentially. If you don't automate at least some of it you're screwed.

Things that help here:

1. Have a dedicated tester. I know it's chic to talk about how devs should be able to test their own code. And it's certainly useful. But I've been a dev responsible for my own testing, I've been a dev with an assigned tester and I've been a tester assigned to a dev. There's something extremely liberating in being able to test someone else's code. Similarly having a good tester on your side is a lot more fun than juggling hatsyourself. We do separation of concerns in our code for a reason. So if you have a choice between pushing devs to test more and getting a dedicated tester this is not even a contest...
2. Automated tests. As I've said above, if you're working on anything more than a one shot project you're only punishing yourself if you don't do this. Doesn't matter if you embrace TDD or do it waterfall-style after development. Your testers should have to find every bug exactly once. If there is only one situation where you write a test, this is it.
3. Automated builds. As a prerequisite for continuous testing and as a way to save time. I've seen a 30 step manual build process in the .NET world. Don't do that
4. Continuous Testing. The tighter your feedback loop the faster you can fix bugs
5. Definition of Done. This doesn't do much on its own for quality. But it is helpful to raise awareness of what level of quality you are operating at and create a better mutual understanding what it means when each person says "this is done"

Organisation

• Early user feedback. No matter how diligent your tester and product owner are, some things will fall through the cracks.
• Shorter iterations / less scope per iteration. The smaller your increment the less interactions you have to test at once. This can help make testing feel less of a chore.

Answer 2

Ask the development team to suggest steps to improve quality

Your idea of introducing Retrospectives is good. As the Scrum Master you should be doing that (and Sprint Reviews) anyway. In the Retrospective, nudge the team to talk about quality issues. I am sure they are as much frustrated about poor quality as you are. They will also have ideas about what should be done to fix it. Extract those suggestions and help implement them. This approach has the following benefits:

• You have recently joined while the dev team has been there longer. They will know more about the root cause of the quality problems and what should be done to fix them. As the new person you do bring a fresh perspective. But use that to guide the discussion to avoid finger pointing and towards productive lines.

• If you work with the dev team and help implement their ideas there will be better buy-in for the ideas and less resistance to change.

• As the Scrum Master you want to be a servant-leader rather than imposing your ideas on the team.