The Midday Technical Q&A Meeting
Increase team productivity, save the team lead’s time and make the whole team learn together with the technical Q&A meeting.
Most of the teams we work with utilize the scrum framework. It’s supposed to be agile, easy to turn to client’s needs and has quick output, as every sprint brings something new to the product.
Ideally, you’d have user stories with spikes, created tasks — all well described, and the sprint should be planned according to the user story estimates.
However, in a startup environment, sometimes you don’t have these riches. Something needs to be done immediately, bugs happen that disrupt the sprint, clients have many support tickets, sometimes even the whole product changes direction and so on.
One problem we experienced working in such environment was that the team lead was always getting questions in the chat. Why is my pull request policy failing? Why the project won’t build on my machine? Why this query won’t return the results I expect? Should I create a radio button or a dropdown?
It was often the case that the junior developers would get stuck on something during the day, and could not move forward. This renders their day wasted. One option to save the day was to just take a new task or a user story until they can say they are blocked next morning on the scrum meeting. But it could happen that they start too many tasks. Another thing they can do is just message the team lead to help them. But most of the juniors developed a habit of “ask first-think later". This filled the team lead’s chat with relevant and irrelevant questions until all they did was answer them and had no time to review, plan, spike or develop.
The goal for juniors on the beginning is to find their way around the project, learn some patterns and the way they are applied and it is not a problem if they spend more time investigating, trying things out or lurking around the codebase. But they don’t see it that way. Usually they are energetic and want to fix things fast. Hence the endless chats with the lead or other developers.
Enter the technical Q&A meeting — something we’ve come up to remedy the situation. This is a short meeting in the middle of the day, which all members of the development team attend.
If someone is blocked, they can ask how to unblock. If someone needs hints or directions on how to proceed — they will get them. Usually the questions are answered by pointing to code where similar thing is already done, or a link to a blog that can give some direction or a hint.
There should be no lengthy discussions or technical decisions done here. If there is need for one — schedule a meeting at a later time so stakeholders can come prepared.
The goal of this meeting is obvious. Let the developers know that they can spend at least a few hours investigating their issue without bothering anyone, knowing that in a couple of hours they can ask. This also gives an alibi to the team lead. If they still get questions, they can say “let’s see that on the meeting later".
These 15 minutes in the middle of the day won’t defocus much, as no one really works focused for 8 hours. Developers will get used to having focus periods before and after the Q&A, and cool off for a bit for the meeting. But the meeting will do wonders for the productivity and feel good factor for the developers that are stuck, as they will get unblocked quickly.
Conclusion
You don’t need this meeting if the user stories are perfectly described, there are spikes and well described tasks. You probably won’t need this meeting if you have an experienced team that knows the codebase and the business domain of the project well.
But you rarely have this, especially in a startup. You need to move fast, no time for spike or proper planning, user story can be incomplete, the client can change their mind mid-sprint… juniors can easily get confused and would need this little help or direction to move forward and become productive.
