What on earth is a desk check and why would we want one? In Quality Foundations I’m concentrating on how to include quality as early as possible. Often we bounce around “shift left”, but how exactly does it look like in action?
Well, unsurprisingly there’s no one silver bullet that you can do to get you there. It’s a combination of various practices. One of the starting points could be… brace yourselves… removing a QA column (ie. Testing, or Ready For Test) on your team board. Not removing the role, just the separation of the activity. We should think of quality everywhere in the process. If we choose to do so, a practice that can prove to be valuable is a desk check. Desk checks help to create shared accountability on quality.
What’s a desk check?
The origin of the term is unknown to me. I would imagine that it comes from the fact that it literally is an activity of checking that happens when going over to someone’s desk to see how they’re doing. Not staying there the whole day, just trying to get a glimpse and check-in. It can be done remotely as well: gather people to a video call and share the screen. The goal of a desk check is to see if the work is ready, or, as well to check-in if it’s going in the right direction or there are any misunderstandings or bottlenecks.
Another positive effect of desk checks for the team is knowledge sharing. Even if a person hasn’t worked on a story themselves, they get the context on how it was done which helps them learn, grow, and understand the product better. This continues seeding overall accountability and collaborative culture.
Usually desk checks take anywhere from 15 minutes to up to 1 hour and may include various roles who haven’t worked on the work item that the desk check is called for. In this meeting, the team goes through the work implemented, questions it, and suggests improvements. Often it is done when the person/people working on the item think they’re done, but not necessarily. Desk checks could be called at any point while working on a task. For example, when the expertise of someone else could help the implementation.
I have as well seen the teams call an automatic desk check after 2 days of development on a work item. Overall, a desk check takes place while the work is still in development. The developers are present and get feedback immediately if anything is missing.
How to run it?
If we have no “in QA” column (a bit more on that in the section below on testing), yet still need another pair of eyes to make sure we’re on the right path, we could call a desk check before moving the work item to sign-off or done. A pair (if the team approaches pairing) or a person who worked on it, can just announce that they’d like a desk check.
As a QA I am a frequent participant in desk checks, but not always. If there’s an infrastructure-heavy task, I may not be the best person to question or recheck if it’s what we expected. In that case, a person who would bring the most value to the desk check is someone with more experience in that area and who knows what is expected. On the other hand, if it’s a user story that I’m aware of or are interested to learn more about - I would join the desk check. Anyone can facilitate it (ie. Developer, Quality Analyst, Business Analyst, or an Experience Designer), yet we have to keep in mind a certain structure and the goal: to collect any leftover work if it’s there while also sharing the knowledge on the implementation of the story. Also, explaining concepts to someone else is a great way of solidifying learning. If someone who joins the desk check has zero context, it challenges the person who is explaining the work to use simple language. As Albert Einstein has said: “If you can’t explain it to a six-year-old, you don’t understand it yourself.”.
Lists to aid a desk check
Similarly to leading a story kick-off, desk checks can have question lists that help preparation or facilitation. There are two question lists I have seen teams use. One of them was called “dev-done list” - it was the last reminder list for a developer pair before telling the team that the task is ready for a desk check. We need to appreciate people’s time, so these lists serve well in reminding us of some of the tasks we always discuss in desk checks: tests, logs, or documentation. They are made to be updated based on the team’s context.
“Dev-done” list was usually referenced before desk checks to help prepare for it better. I’ve also seen a desk check question list used to facilitate the meeting.
Example of a desk check question list for facilitation
Some issues may be discovered during the desk check. In that case, it’s great that the work item is still in development and they can be tackled, yet the question that the whole team could ask themselves is: how could we prevent it even before the desk check? Maybe it could result in a question that could be included in the story kick-off meeting before the development even begins?
What about testing?
How dare I just drop “remove the QA column” and introduce desk checks? I hear you say. It’s important to note that desk checks in no way are replacing QA practices and activities. If we want to build quality in, we have to have a bunch of activities related to quality way before this column exists. Desk checks are just one of them. They are called “checks” also on purpose: thorough testing is not a part of them.
Testing should be done as a part of development. At any time of task implementation QA could pair with the developer to make sure that the automated checks are providing us with a good feedback mechanism on the product. Also, exploratory testing sessions definitely can take place within the development of the story, too. Testing becomes a shared responsibility, though. It’s not just one role’s activity. Exploratory testing sessions can utilize the information gained during the desk checks and end up providing even more value.
Summary
Desk checks are a practice of involving various team members to provide feedback and share accountability on the quality of the implementation during the development. They are fairly short check-ins if the work we’re doing is as expected. If it’s not - then the developers get feedback quickly and tackle call-outs within development without “throwing it over the fence”.
Desk checks facilitate team collaboration rather than the separation of roles.