Kanban teams are supposed to “make policies explicit.” I’ve asked at conferences, in forums, and on Twitter, “How do you make policies explicit?” I’ve never gotten an answer. I suspect many teams don’t have a good way of capturing and communicating policies.
Most policies come out of retrospectives. They address problems the team identifies. If you have a retrospective every two weeks, and in each one you make two or three improvements to your process, that’s a lot of changes. I’ve seen many teams forget good practices that used to work or keep doing something that doesn’t work long after everyone’s forgotten why they started in the first place. How do you remember which ones worked? How to decide which to keep, which to scrap, and which to tweak?
I’m a big fan of Big Visible Charts. I’ve covered my walls with information radiators. I’m also passionate about software quality. I’d like to share a QA process tool I created to make retrospectives more effective. It makes policies explicit and ensures that we remember to focus on what I think of as the “four dimensions of software quality.”
Most people think that software quality means no bugs. Ask most teams about quality practices and they describe finding and fixing bugs. Granted, the world would be better if we could find and fix the many bugs that live in our favorite software. But this is a tragically incomplete view of software quality.
The four dimensions of software quality that I’ve identified are these:
1) Well-structured, clean code with good test coverage which follows standard conventions and coding practices with clear style guidelines
This allows new people to join the team or for a product to be handed off to a new team. It makes it easy to add new features or to refactor code without breaking existing functionality.
2) An architecture that allows for efficient and appropriate scalability.
Not every web application is going to have to support millions of users. But just in case, the architecture should be such that migrating to cloud hosting or a distributed delivery model shouldn’t involve massive refactoring.
3) Quality software is delightful to use.
Features shouldn’t just work; they should work in a way that is intuitive and pleasant.
4) And finally, the features work.
Without awkward workarounds or … bugs. That doesn’t only mean that nothing is broken. It also means that the development team understood the problem and created an appropriate solution.
We don’t want to end up with a product that looks great, but doesn’t work, or works great, but doesn’t scale.
What you might notice is that in no place in this article have I referred to software testers or QA engineers. Software quality is the responsibility of everyone on a software team, and team quality practices reflect that. In my experience, all of the issues that arise in retrospectives directly impact one of the four aspects of quality. For example, poor communication with the product owner leads to improperly implemented features. Any change in policy that improves communication, makes the product better.
Using the chart
I’ve created a large wall chart to collect practices with four quadrants for each of the four dimensions of software quality.
If the team sits together in a room, you can print this chart onto A0 paper and post it on the wall. As ideas for process improvements come up in a retrospective, add them to the appropriate grid on a Post-it Note. These practices should be detailed enough to be consistently followed. Instead of “hallway testing” we might write “When a programmer has finished work on a feature, she asks someone who’s not busy to use the feature without guidance or prompting in an Internet Explorer environment before marking the feature as ready for a code review.” Making the rule specific in regards to who does what and when makes it less likely to be ignored or sloppily implemented. Start the next retrospective by reviewing the new policies. If they prove to be good ideas, we write them directly on the poster. If they didn’t work, the team can tweak them or scrap them and try something else.
Eventually you end up with a chart showing what policies the team has adopted to address each aspect of quality, as well as the experiments that the team is currently trying. If there’s an area of quality that’s not being addressed, you can see it clearly. If you have many teams, they can visit and see how other teams are addressing problems they may have and learn from each other.
But maybe your team isn’t co-located?
You can use an “Experiments” Kanbanery board to track your experiments and make your policies accessible. Use a different task type for each of the four types of quality, so you can tell from the rainbow of colors on your board that you’ve got all your bases covered.
The first column is for proposed experiments. The second is for experiments in progress, and the third is for Policies. If the Policy column gets too full, use four different columns so that you have a list of policies for each dimension of quality.
Failed experiments can be archived. Annotate them with comments about why they didn’t work, so you also have a collection of data about what didn’t work for the team and why.
You can also share the board with other teams. Or make it public so anyone can learn from your experiences and be inspired by your experiments.
How do you test the ideas that come up in retrospectives? How do you make policies explicit? Please share your ideas in the comments.
Click here to download the chart.