Over the past year I’ve been spending some time in the sub-reddit r/ProductManagement and with my background of 10 years in Software Development and 3 years in Product Management, I’m happy to write where I can contribute. In this series, I’ll republish some of the responses I’ve written and maybe expand on them.
How do you deal with a lazy and temperamental dev who is inconsistent and is not fired only because of his historical knowledge?
No pls, do not tell me to talk to the person 1×1. This has been tried and failed by even his Mgr. His Mgr was recently fired and now his two up is dealing with him and knows all about his flaws. Yet his Mgr said to me that it shouldn’t matter what his individual performance is as long as the TEAM delivers. And don’t focus on his performance and rather focus on the team.
I call bullshit. It all starts with individual accountability.
A developer as you describe him has also a toxic influence on the team. If his attitude and behavior are accepted by management, it sets an example for the rest of the team — either they follow it, or they explicitly refuse it and get demotivated. When I was still a developer, my bosses were always careful to remove these people quickly, because in a performing and committed team that with high expectations and pride in their own work, people like this are a risk and detrimental to everyone’s experience. The team may try, support, console and carry him for a while if he is not up to speed, but this will not go on forever.
This argument of not letting go of him because of his historical knowledge actually shows you what needs to happen: you have to break the silo. Encourage pair programming. Have people work on his projects and have him in the navigator seat. Build a culture of sharing knowledge and use this to reduce the reliance the company has on him.
Finally, act when the risk of keeping him outweighs any benefits. When other team members leave because of him, it’s red alert.
Cowboy tech lead forcing engineers to do refactoring during implementation that end up being carried over. What to do?
I always say make sure at grooming we call those out so we point appropriately as opposed to during implementation then we catch refactoring and then end up making the story more complicated.
The devs who are contractors that disliked tech lead pushing for refactoring in existing feature stories voiced concern there’s no documentation or traceability of these refactoring.
So ideally, your team would create consensus during Sprint Grooming on the depth of the changes agreed upon in the sprint. Of course during the sprint you learn new things and it may make sense to re-evaluate. The developer concerned with the change should call out the potential earlier — e.g. during standup and invite a short discussion about risks, opportunities and scope of the proposed refactor. As a group it should be decided, whether to go through with it or not. They could organize a group coding session and refactor the core together. Another way could be to time-box the change and say “pursue the refactor for 4 hours, see how far you get, then leave it”.
I’m not quite clear on your setup. Your team has a Tech Lead (inhouse) and external contractors for implementation? Do you have a scrum master in the team? Is the role of the tech lead in your case the one person deciding and everyone has to do what they say? Is this being challenged sometimes? If that’s the case this is one thing where you could work together with the scrum master to influence the culture of the team to be less hierarchical and more collaborative. Especially if you can enable the scrum master to “protect” the scope of the sprint and overrule the Tech Lead.
Concluding, finding the right spot in sprints for refactoring is hard. You don’t want to risk the sprint, but refactoring tasks alone bring little value, without providing analysis and context how the refactor improves performance or adaptability, etc. The most important is building the environment to have conversations around this collaboratively without one person just starting/ordering refactors. If refactors come up that risk the sprint, it should at least be preceded by a discussion to get you onboard.
Edit: one more word on “Tech Lead” position: usually the Tech Lead is the one with the technical “vision” and oversight on the implementation. It does not mean that the implementation has to follow their every word. I get how having external contractors builds its own dynamic around this, because they will always be a bit on the defensive and point to the Tech Lead when asked why they build something the way they build it.
Convert grooming estimations to points from hours
Recently our front end and backend estimations have seemed a bit fluffed hours-wise. While I don’t find it to be a huge issue, I was wondering if you have suggestions on how we could possibly start converting over to using points instead of hours to plan a two-week sprint. My main blocker is knowing how many points to think about in terms of two weeks. I understand as we push through sprints the point estimation will become easier as there is more precedent from previous ones.
Assuming a 1–2–3–5–8–13 Story point scale, we introduced it this way in the dev team:
First we talked about what the numbers should represent to us. Not hours, but an abstract combination of effort and risk. So 1 — low effort, low risk — 5 — some effort, little risk 13 — lots of effort, many risks, etc.
Then we all got around a table where we had a scale with the points from 1–13 and cards with the stories of the last sprint. We finished those, we knew their efforts and so we asked the team to order these cards along the points scale. We’d find that with some cards you’d get into a discussion why something should have more or less points. This already previews the kind of discussions you are going to have in future Sprint Groomings. For now the important thing is to develop within your team a feeling for the point scale. Having the team develop an understanding for the scale is most important. The scale is relative, it may change over time, that’s OK.
Note, while another team may use the same scale, they may assign effort/risk differently and what one team understands as a 5 may be mapped to an 8 in another team. This is part of the old story, that story points should not be used for performance calculation. Within the team, the points and even more the discussion around them is valuable to discover hidden risks and to plan efforts. For example, if you see many stories are always rated as 8 or 13, it shows the stories are too big or involve many unknowns. Story Points can also be used as a rough number for estimating the velocity and volume to put into a sprint.
Outside of the development team you may find forces asking for a more “robust” metric to estimate work effort. Especially companies outsourcing their agile development team rely on Story Points as a metric to assess whether the hired team delivers the agreed amount of work. This requires the Story Points scale to be clearly defined and also needs a mechanism to readjust if you see Story Point scales change.
Good luck, with your team.