How to get what you need without interrupting the team
he article "The Art of interrupting Software Engineers", has recently hit the frontpage on Hacker News. The article makes the following point:
[...] I followed my mentor’s advice and started to check-in at least every half day with each pair of engineers I was working with.
While it might be OK to disturb a team two times a day (three, if you add the daily standup), depending on your team, process and culture, I think that in many cases, we ask the developers way too often for updates. This post adresses the issue from a non-dev perspective and answers the question: How do you get the input you need without interrupting the development team?
Status updates make you feel in control
As a teenager, I was leading a local youth group. Once per year during summer, the kids and I would go on a 1-2 week hike, and every year I was faced with parent's need for daily updates: Is my son eating enough? Is he sick? Did he sleep? Since I did not want to spend the better part of each day finding a phone booth (this was before cell phones) and calling up half a dozen pairs of parents, I have set up the following rule: In case of an emergency, I would call them immediately, but if they don't hear anything, all is well.
This has worked very well over many years, and even today it continues to work (the kids are generally not allowed to take a cell phone with them).
Understandably,the parents want to feel in control over the well-being of their kids. If the kid is not sleeping enough, they could give advise, and if the kid is sick, they could come pick it up. So in essence, it all boiled down to the parents trusting me to care for their kids - having kids on my own today, I can fully understand that!
Similarily, people ask for status updates in development projects because they care. Project Managers want to make their projects a success, Product Managers or Product Owners want their next release to be successful, Customer Relations Managers have customers breathing down their necks and so on.
Before you ask, figure out what you need to know
There are many reasons why someone in a non-developer position might want to interrupt the engieers. In most cases, it boils down to one of the following:
- You want to know if your deadline will be held
- You want to make sure the team is neither stuck nor over-engineering
- Someone is pushing you for updates, so you need something new to tell them
- You want to know if your scope will be held
In the following sections, I will explain how most of these things do not warrant interrupting the developers, and what to do instead.
Use tools and KPIs to control your deadline
If you are concerned about your deadline, use existing KPIs and tools to review them. If you are working with Kanban, use the Cycle Time. If you work with Scrum, use the Velocity. For example, if you have a two-week-sprint and your feature is already planned, then you will get it within these two weeks. If your team has a spill-over to following sprints of around 20%, and your feature is at the bottom, then you will get it next sprint - and so on.
If you don't have that kind of KPI readily available, introduce it. It will make managing projects or products so much easier.
Trust the team on pulling you in
It's understandable that you are worried about the team getting stuck, or the team losing themselves in gold-plating. But remember: Software Engineers are usually highly trained professionals, and should be treated like any other professional out there. If your team in general has a problem with over-engineering, then that is an issue to tackle. Similarily, if the team has a hard time realizing that they are stuck and your help, you should solve the root problem instead of treating the symptoms. Otherwise, trust the team to pull you in if things are unclear. Make yourself available and make it clear how and when to reach you, and trust the engineers to ask you when they need help, not the other way round.
Don't pass on the pressure
Depending on your business, you probably have stakeholders - customers, managers higher up the chain and so on - pushing you for updates all the time. Turning around and pushing the development team in turn is the obvious, albeit lazy solution. Remember, as a product or project manager, it is your job to handle the stakeholders, not the engineer's - not even by proxy. Instead of pushing your engineers, you need to stand your ground and tell them that they will be updated as soon as something important changes - not earlier. Remember, Engineers are not getting faster by being asked all the time - they are getting slower!
Use existing feedback cycles to control scope
It is not uncommon for misunderstandings to happen during development, so that the final product looks different to what you had in mind. And unlike the other cases, the developers might not even notice that they are not on track, so you can't trust them to pull you in on that matter. Many agile processes have built-in feedback mechanisms to update you on the scope - you might hear about the current scope during the daily standup, or demo - but that might not be enough. In this case, you should find a convention that works for you and the team, so that you get the feedback you need with minimal interference.
Here are two approaches I have seen working:
- Add a "Review" step to your process, where the developer shows what he has to you, so you can check if the scope is met. In the context of Scrum, this can replace the demo.
- For individual features, you can be upfront about it: "This feature has a few edge cases that are hard to get right, so please involve me as soon as you get to the specifics". Then trust the team to pull you in if needed.
Bottom line
There are many reasons why you might need a status update from the team - but in most cases, you should consult your KPIs or tools first instead of interrupting the team. If you don't have those in place, invest in getting them. For everything else, find a convention that works for the engineers and you alike.