When team members are busy in fixing bugs what can/should their dev manager do?

Question

We have a release cycle about three to four weeks for a new release then a bug fix sprint to make the product stable, then new features sprint to kick off another round of release cycle.

What should I, as their developer manager, do during the bug fix sprint when my team members are busy in fixing bugs ?

I have tried several things but I am not sure which one(s) is the best.

1. Joining bug fix with my team, but mainly pick the toughest ones.
2. Mostly doing code reviews and only do bug fix when necessary, e.g. bugs with the same (or similar) root cause keeps surfacing so I decide maybe I should step in.
3. Not fixing bug directly but focus on analyzing and summarizing bugs and their causes
4. Investigate new technology/methodology, see if we can introduce them in the next release cycle.
5. Combining

Note: although I use the term "sprint" I hope that won't sidetrack my question to another discussion about scrum/agile (we have many questions about them already). The way we do scrum/agile is small release and continuous improvement (new feature and bug fix both as improvement)

About my duties as their dev manager, in a nutshell, they report to me and I am responsible for our deliveries as if anything (seriously) wrong with our product I am the first to be called.

I am not in anyway suggesting I am not clear about my job responsibilities as one comment suggested. As a small company we can't afford to have two totally separated roles , people manager and tech architect. From what I know it is not that uncommon.

Answer 1

What the developers are doing has little impact on what you, as a manager and a leader, should be doing. It doesn't matter if the developers are fixing bugs, building new features, or something else. Although they are originally geared for manufacturing and formed the basis for lean, they are generally consistent with Lean Software Development and Agile Software Development, so I would turn to W. Edwards Deming's 14 principles for suggestions on a manager's responsibility in an organization:

• Create a safe environment. Google's Project Aristotle reaffirmed this need. One of the most important factors for a successful team is the ability to take risks and fail without reprisal. A team needs to be able to, within reason, make mistakes and learn from them.
• Create an environment where quality is built into the product. Make sure that quality is owned by all members of the team and they have the time and knowledge to avoid reckless technical debt.
• When you do identify low quality work, whether that's defects or technical debt, advocate for making it a priority to resolve. If you control the work prioritization and order, prioritize it. If a product manager or someone else is ultimately responsible for ordering the work, make sure they understand the impact of low quality on the teams responsible for building and maintaining the product.
• Tear down silos that exist between parts of the organization. If the developers have trouble talking to support, sales, marketing, legal, or any other department that they need to finish work, figure out how to develop a collaborative relationship between your developers and the people with knowledge and insight that can help them make better decisions and build a better product.
• Make sure that the team has time and space for retrospectives. When the team identifies changes, help the team enact those changes. I'd recommend Esther Derby and Diana Larsen's Agile Retrospectives: Making Good Teams Great (and a second edition is coming out in March 2024). This is the only practice explicitly called out in the Manifesto for Agile Software Development and can be a useful source of feedback for management. However, teams need to see the value of performing a retrospective, so it's crucial to show progress being made to resolve problems brought up by the team.
• Observe the work yourself. Or manage by walking around. The team may not be aware of the existence of better practices or practices that they are using that are less than optimal. You may not be involved in the day-to-day work, but you should be aware of it and ready to offer your knowledge, experience, and assistance.
• Make training available to your employees. If you don't have a training budget, try to get one. Even if you don't have a training budget now, set aside time for skills development. If people on the team want to take relevant courses or training, try to support them with time off during the workday. Work with the team to build this into their scheduling and planning activities and see the importance of learning and self-improvement.

With the exception of helping directly with bug fixes and picking the toughest one, it seems like you are doing a lot of the right stuff. If you do help with bug fixes, I'd encourage the opposite approach: take the boring, menial work that may not be on the critical path or necessary for success and let the team focus on the challenging technical work or the work that cannot slip. When managers take on work in the critical path, they are in a position where they may need to neglect their managerial duties at the detriment of the team.

Answer 2

What should I, as their developer manager, do during the bug fix sprint when my team members are busy in fixing bugs ?

Taken literally, you ask here what you should do differently, in your role of people manager, when your subordinates are fixing bugs versus developing new things. That is a wholly uninteresting question, because what you do as people manager is completely independent of what your subordinates do.

Later on in the question, you mention that you are also the tech architect for the team. From the perspective of that role, the question is way more interesting.

One thing an architect should do is oversee that their architectural vision and direction are being followed by the team. That activity would be the same for feature sprints and bug-fix sprints.

Next to that, you should be working a little bit ahead of the team, so that you can be prepared for the questions that will come. During a bug-fix sprint, you can already look into the features of the new release cycle to understand how they would affect your architecture and what questions you could expect from the team.

Another thing to do during the bug-fix sprint it to check the bugs that have been analyzed for commonalities in what caused those bugs. That can help you uncover weaknesses in the architecture and/or work processes that you might want to address before (or during) the next release cycle.

If, after doing the above, there is still time left, and if hands-on development is part of your duties, you can think about helping the team by picking up some bugs. As your other duties might cause interruptions, it would be better to pick the boring ones.

Answer 3

If you are a dev manager and you find down-time to even have this conversation, then well done, take a breath and relax for a moment.

If your backlog is up to date, and there are no outstanding reports, assessments or reviews to complete, and the backlog has a lot of future items that are well documented or defined to choose from for the next few sprints... Then I would take this moment either to prepare a proper retrospective of the last quarter or last few major release cycles or alternatively look to the future and prepare a business case for the next big hairy audacious goal.

Investigate new technology/methodology, see if we can introduce them in the next release cycle.

This might be the only time that you get to prepare for what is next, but your investigation only needs to go as far as describing the potential viability of V-Next. It is not your place to boldly go there and come back with results, that is a dev job.

A Dev Manager needs to understand code and the code process, but not get involved with it. You are now a facilitator of developers, there to assist them make decisions, to be the catalyst that keeps the sprint moving forward without getting your hands dirty. It is not your job to have all the answers, you are there to help your developers find the answers.

Do not feel tempted to get involved with the bug fixes!!! Even though you have the skills and capacity today, your role specifically is one where you need to be prepared to be interrupted.

Probably the worst thing you can do is take on a really hard bug. By all means analyse issues that are outstanding and help break them down into manageable tasks but if you get involved in the code work, now the rhythm of sprint is tied to your ability to fix what no one else has so far been able to. If you get distracted in the middle of a large refactor effort, and leave the job half done, you may find that other devs will fix some related issues instead of waiting for you, the merge effort at the end, if you get there could be more significant than had you simply tasked someone to re-code the affected feature from scratch in the first place.

The Dev Manager role is where agile is employed in it's rawest form, do not take on commitments outside of your direct responsibility. You cannot manage the team and be a part of it, we are not the kings of old riding at the front of the army leading the charge, we are however the scouts, leagues ahead of the front, scoping out the next offensive and plotting the course.

Answer 4

So from your comments on other answers I think maybe your job title is causing confusion. From your description of responsibilities I would call it a Senior/Lead Dev/Architect role, rather than use the word "manager"

In this role yes I think I would expect you to be "helping out" with actual work instead of just having lunch "meetings" with the other managers. ;)

You say :

"I am responsible for our deliveries as if anything (seriously) wrong with our product I am the first to be called."

If you are doing a bug fix sprint I think your number 1 task is to figure out why you have that many bugs and how to make sure you don't get any more going forward.

If you just accept that "we will always have bugs" you will always have bugs, so while the devs fix the bugs, you have to figure out why you got those bugs, how they managed to get through testing, how you could have caught them earlier, how you can verify they have been fixed etc etc.

I expect this to manifest as specifying extra stuff to do over and above the simplest and quickest bug fix, add more tests! Add more logging! Make sure that works for the general case! Load test that fix! Make a report on uptime for that service! etc etc

Of course you probably have a whole other bunch of stuff to do which might take priority depending on your workload, but, Yeah a whole sprint just to do bugs? sounds like you are not on top of that. Make a report on how many bugs are found over time and set goals to get that number down. Convince other managers to see the benefit of putting effort into getting "zero defect" releases. Slow is smooth and smooth is fast!