Anyone ever come up with a set of quality principles with a team? Any one know any activities to help provoke discussion around this area?
For background thereās a section here with a few dev teams all working around the same set of tech. They want to move towards having some testing/code quality, but thereās no cohesiveness yet, and they (and I) think some quality principles will help them decide what testing to do. Interestingly, itās research/open source stuff rather than a product, so thereās no PO/PM/BA role, so itās a dev team self organising, which is a situation Iāve never been in before!
Theyāre pretty good at considering testability, doing good PR reviews and are in the right place mindset wise, just need a direction to move down.
Sorry I need to ask to catch up here: whatās a quality principle, and what do you want it to do?
Iāve come up with working checklists and whatnot, based on what the team tended to get wrong or what tended to go unstated. I created a list, showed it to individuals in the team who asked me to add stuff (Dan B asked me to add Security, which was an embarrassing omission on my part). That got iterated on every time we created a problem (we annoyed another team once, so added an item to consider what damage we might be doing to them with our changes). That turned into something called CLAPDRIFTDUST which came up at a TestBash talk at some point I think.
Then I had to make it stick, so I introduced a sticker system so that stories got one kind of sticker if we agreed not to talk about it (very simple chores) and another if we kicked it off properly with the checklist. That way anything without a sticker was very easy to see.
No, thatās an understandable question. The section want to come up with a set of things that they do to ensure code quality that they all agree to accross teams. Itās a way to figure out, make explicit, and then rationalise what strategies are currently used.
The more Iāve thought about this, the more I think what they actually need is:
a session where we bring together everything that each team does towards code/product quality
1a) what works
1b) what doesnāt
1c) where each team feels they are missing something/are uncomfortable with the code quality and why
Figure out what they want to take as an official team strategy/checklist, and what works but only for that specific team
if they want to enshrine them in a formalised system/checklist, then we can find the proper way to do it from there.
Sounds like a good idea! I like the idea of taking whatās useful from all teams and seeing if you already have the tool from one for the job of another.
You may know all of this, but Iāll say it here in case you donāt or someone else with the same question is reading:
I find that enabling process improvement is mostly about taking away the hard jobs and letting them find the way that they want to improve things. The difficulty, in my experience, is moving from ideas (which are plentiful across the land) and towards actions that improve things (which float, lonely and unseen, beneath the ocean of opinion). For that you generally need someone to be responsible for that action. Otherwise you get one of those meetings where everyone agrees what is a good idea and itās all written down and then everyone goes back to the status quo.
Getting people to come to a consensus of ideas and build a checklist has always been the easy part, for me. Getting them to actually change is a social contract best managed or assigned responsibility in some way. For my checklist I had to point out that stories had moved without stickers a few times before it became clear that the old ways werenāt okay any more.
I predict that the meeting will bring up some non-relevant concerns to which there may be another solution or be associated with other problems. Everyone wants to be listened to, so there should be an inclusive way to accept those ideas or issues without wasting time on them. They could go in a āto discussā pile or a vote to discuss only the most important items could render them last to talk about - a method of exclusion controlled by the team, ideally, to prevent the illusion of autocracy.
You may find, obviously, that a checklist isnāt the improvement you need. For me the list was a way of introducing an idea small enough that my team would shift to, and it was the sticker system that helped our communication and cultural ideas about tester integration. Maybe code is suffering because testers arenāt in design discussions. Itāll be something about feedback loops.
A way to iterate on a list or other device is useful. It may need maintenance - adding more items, removing redundant items, making the enforcement transparent, and discussing the perceived improvements and unforeseen costs.
How Gem, weāve just launched an initiative across our web platform doing just this. Itās possibly a little over kill for your needs but Iām happy to share what weāve done. Drop me a message or find me on Twitter.
Weāll be talking about it publicly soon but until then I need to be a little careful
I did this pretty recently it started as a vision statement but became too long. I work with a group of about 13 so I could just email the group and get all their thoughts. I edited down one contributors notes and over time took more and more feedback spread across a couple weeks. After a lot of editing we shared it with our leadership and will be sharing it with the whole software development group. An alternative could be working through a charter activity to gather everyoneās feedback at once and then create something from that.
