Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
As a Scrum Master / Agile Coach, what is the correct approach for dealing with Engineers in a team who take longer than the rest of the team to complete their tasks.
Since we are using Kanban we aim for between 5 and 7 days average cycle time i.e. when they pick up a ticket to when they push it to done it should be between 5 and 7 working days.
Thus far I have simply made this information available to them with dashboards.
Firstly, look at whether you can split your stories any more.
Secondly, why aren't the engineers on your team cooperating. The way your describing your system sounds like a you've set a minimum work in progress limit of one story per developer. Of course your cycle time is high (cycle time = wip / throughput after all). Instead cooperate on things to reduce work in progress.
I can tell you suspect that some of your engineers are better than others. I think the thing I've already suggested, encouraging cooperation on tasks, will go some way towards bringing the skills of the weaker engineers up. There are a lot of other people management factors however. I won't list all of them, but do people get the tools they need, the training they want, slack time to improve their skills, time to go to conferences etc etc? Are you involving your best developers as key decision makers in the hiring process? People have written books about this sort of thing, so I'll stop there.
First of all, faster isn't always better. One of the engineers I've worked with finished his stories extremely fast, way faster than the rest of the team. But he'd often use quick and dirty shortcuts, and the testers explicitly gave any user stories from this engineer extra attention. He produced different bugs than the rest of the engineers, more difficult to find, but often with a lot of impact.
If there's enough trust in the team, discuss the differences in speed with the whole team and ask them what factors they see that can explain the differences. Some possibilities include personal factors (motivation, drive, perfectionism), skills and knowledge, amount of distraction (soloists vs the people who are always helping others instead of doing their own tasks), or different views on quality/scope/definition of done.
Try to pair the faster engineers with the slower ones (and in general, encourage cooperation) -- both of them can learn from working together.
If you want to bring your cycle Time down, then it's time to apply The Theory of Constraints. Look for where the work is piling up, then work to remove the bottleneck.
Of course, the work has to be visible enough first. A simple todo-doing-done board isn't going to cut it. You need to model the actual workflow in order to spot the bottleneck. Backlog-Ready-In Progress-Review-QA-Ready to Deploy-Done is a likely workflow. If things are piling up in QA, have some devs help. If things need reviewed faster, figure out how to make that happen. Do deployments take hours? Automate them. Etc.
As mentioned by others, the other lever you have to pull is the WIP limit. Reduce your WIP limit and the avg. Cycle Time should fall.
Most importantly, the team must leave enough slack in the schedule so that they can improve. It doesn't help to identify a bottleneck if no one feels they have time to address it.
We had the same issues: the team I took over as Scrum Master was considered slow by the POs, other devs and so on.
When looking into it, these are the problems identified (and solutions we implemented):
The above worked very well. We increased our velocity with at least 30% in only 4 sprints. But I am aware that the increase might come from the fact that we didn't estimate stories properly to begin with so we continue working and monitoring.
TL;DR it all starts in planning, how you split and estimate stories. Start from there.
