Ask HN: How do I help an underperforming team get on track
I manage a team of 3 developers (4 in total) and every sprint we either fail to deliver the work we commit to, or deliver work that ultimately fails the QA process. Even though half the team is quite junior (this is their first job) everyone is smart and capable of writing logical, working, and tested code.
Things I've tried: * Reducing the scope of the sprint to something that should be very easy to deliver on (Parkinson's law got us) * Daily 1:1 10 minute meetings with each seemed to be a burden on a everyone and didn't lead to productive conversations. * Creating a rigid structure for the daily standup (Usually a ~5 minute meeting) but people seem to indicate everything is fine until 3-4 days before the end of the sprint.
For a young, scrappy, startup (we're under a year old) I'm struggling to understand if it's an issue of motivation, organization, team, or there are just some fundamental things that need to be fixed.
I would argue that everyone likes working with each other - so "starting over" isn't the first choice for anyone.
74 comments
[ 3.8 ms ] story [ 132 ms ] threadIt might be an unreasonable amount of work to deal with. Is it actually a team decision the amount of work that gets set for the sprint, or is it a senior's best guess?
It's also a very strange & distracting time to be alive, it's reeking havok with my mental health, it must be for other people as well.
The scope isn't your decision, it's the team's decision. They should only be committing to
Do three things:
1) Track the work committed to work completed ratio. You want to goal this towards 90%. It's a great metric because it's not easily game-able and it serves your team's interest.
2) Make sure all tasks are broken down into small chunks (no task should be a >3 day worth of work task). If you have a developer who has 1 ticket for the entire sprint then your tasks are too big and need to be broken down.
3) Get the team to commit early and often. It sounds like right now you might be doing "mini-waterfall" whereas you want something more like Scrum. There should be visible progress on Day 2, even if it is just notes on what they are thinking through to implement.
This may be career suicide, just saying.
How long are these sprints? I wonder shorter sprints would help flag things earlier. Think about "velocity" as a metric to base sprint length on. How much wall clock time does it take to get a spelling fix into the release? Something that should pretty much always pass QA, peer review, etc. How often is your reworking a deliverable after QA fails it? Those two numbers should inform how you set sprint length -- long enough to get through the release process in the happy case, times enough iterations to reach that happy state.
What are the daily standup status reports like? If you want earlier warning signs, I would suggest a three tier approach: Green, Yellow, Red.
Green: deliverable is on track and expected to be completed on time.
Yellow: deliverable is at risk, but a minor amount of additional information, discussion, attention or overtime can put it back on track.
Red: deliverable is unlikely to finish on time and to spec.
The thing you as a manager/project manager want to avoid is a deliverable going directly from green to red, as it means your team is unable to assess or react. It will probably happen with juniors and new teams, but your job is to communicate displeasure at the event, and coach them privately (during weekly 1:1's) how to avoid that going forward.
And yeah, if it's missing the overall goal, then it's clear halfway through that we're missing the goal, so you can correct earlier.
No matter what you work on there _has_ to be a way to show the impact you had unless you had no impact.
This kind of progress is pretty common, in my experience. I've already written about defunctionalising an algebra before (https://www.gresearch.co.uk/article/defunctionalisation/), and that is another example of a task where the work can often divide itself into discrete chunks. You can show your progress to your team, all without the end-user being able to see anything.
To the OP, think spikes: https://en.wikipedia.org/wiki/Spike_(software_development). Very important with a lot of unknowns. Doubly important for new engineers because.. Well, sounds like they are dealing with a lot of unknowns.
What changes need to be made in detail.
If you've got a technical manager who's trying to be the senior engineer, you'll have a conflict of interest in long term quality vs. meeting commitments.
If you have only a dedicated senior engineer you'll have worse relationships with stakeholders and communication out in general.
A senior engineer will help you meet deadlines. A manager will help commit appropriately (to keep same worklife balance).
But you also can't just have two folks on the team because they'd both burn out. So you need these two roles but then you also need another 2-4-6 developers, a mix of senior and junior.
My point is that it's not just about skills but which slot you fit in to make sure everyone is representing all the various aspects that lead to good overall decisions.
And as you say, I'm only even talking about the best case where everyone is competent and reasonable.
Are you telling them to reduce scope or working with them to take some of the work away? Try the latter, ensure they have ownership over the reduction and that the reduction is not prescribed.
>> Daily 1:1 10 minute meetings with each seemed to be a burden on a everyone and didn't lead to productive conversations. * Creating a rigid structure for the daily standup (Usually a ~5 minute meeting) but people seem to indicate everything is fine until 3-4 days before the end of the sprint.
In the standups, you may need to probe to understand what they actually accomplished and whether they are on track to finish the sprint.
Given how hard it is to estimate software dev (for oneself let alone for a team), I think the speed with which your team produces quality code is more an emperical observation reflecting your team composition and dev/QA processes rather than a commitment you make. Especially so when the team is new and young.
> or deliver work that ultimately fails the QA process
How many layers of QA/QC do you have? For example, you can think of 4 layers: 0) spec/ticket/story author 1) code author, 2) code reviewer, 3) pre-release manual integration QA (by testers).
These are very different activities (eg reviewer may not actually run code but could be able to tell by looking at code that something's wrong) with increasing cost of fixing issues at every layer. If you leave most of your QA to the last step you end up with a lot of hours spent fixing bugs while you could have avoided most of the same issues (and more) if, say, devs had clear instructions for testing their code and a solid review process.
Don't insulate the team from the product owner, let them feel the pain of not delivering.
Shorten the sprints down to a week to reduce the feedback loop time.
Stop doing commitment based planning, just work through stories in order and get a feel for your capacity/velocity.
Minimise the work in flight, all work on the same story if you possibly can.
Pair more.
When the PO feels the need to micromanage individual developers so that they “feel the pain”, it’s a disfunctional situation.
The whole point is to stop the original poster trying to micro manage and in doing so preventing the team from self organising.
You've completely misunderstood.
You may also want to try and identify the weakest link(s) in the team and see if are not pulling their weights since in a team of 4, even 1 weak link means 25% impact.
Solution: Find someone who does understand and who is interested in the team's success by giving them equity in the company.
> I would argue that everyone likes working with each other - so "starting over" isn't the first choice for anyone
Where did you get the money to enable this awesome lifestyle of prioritizing people 'liking' stuff all the while you're failing to deliver what you've set out to do? I'd like to get some of it for myself, it sounds really nice.
My bg: Grown engineering teams from 1 person to 20-25 strong and have done this 3 times at various early stage startups. So you know can judge whether this might apply or not.
Depends on people: Are they task oriented / goal oriented ? You can detect based on how they talk about previous projects. Do they say they did x, y, z or do they talk about the big picture of the problem being solved, why they chose what they chose, its features/lack of features etc.
1. Task oriented folks want detailed action items and they don't mind you being super specific. With these folks, have a detailed plan of what to implement, how to implement, break it down into day by day plan. Try to be aggressive w.r.t goals (don't do this, if they are already demotivated), goals that are slightly harder to reach. But ensure that even if they are 60% is done, you will get a workable soln. Ensure that each days tasks are done and checked off and you can track daily progress. Catch up for detailed meetings every 3-4 days. This would be rescheduling of tasks, addition/removal of specific tasks that are no longer valid/requires to be done, re-prioritization/reorganization of tasks etc.
2. Goal oriented folks would want you to give them the vision and overall direction. But watch out for digression that lead to long discussions during such meetings. Tell them what you want to build and why you want to build that, how will the user use it. Then they will figure it out and you can have review meetings. They would not like to you put detailed line by line plans. Ensure you have high alignment during stand-up. Have check ins every 2-3 days to ensure that they are not going in completely wrong directions and you couldn't catch it due to brevity of scrum. But these are usually shorter meetings.
Make them feel like each failure is an opportunity to learn that they need to put to good use for the next deployment.
Build a process that turns your team into an effective team
Start with ditching scrum. Have everyone focus on exactly one user story at a time until it is complete and passes QA. Once it does, go on to the next one. Every time I suggest this, people tell me I'm crazy, but every time I've talked a team into trying this it has increased their throughput.
There are lots of reasons why this works. It reduces time lost to queuing, reduces crosstalk and coherence penalties, tamps down on Parkinsons Law, and many more.
Don’t try to create a process like scheduled meetings. That’s just surface stuff. Unless your people are incompetent there must be some deep problems that need to be uncovered. Most likely there is a problem in communication or understanding. Also solicit feedback about yourself and other managers. This may be painful but is often necessary if you really want a better team.
I think this is all you need really. You can timebox (sprint) or iterate or whatever but have the discussion on (a) the cause of the problem and (b) how to avoid it in the future. (This is ISO9001 in a few words)
Stop committing to so much.
> deliver work that ultimately fails the QA process
Stop committing to so much.
> half the team is quite junior
Stop committing to so much.
I see you tried that, and Parkinson's law got you, but it might be that the team needs several sprints to catch their breath and also change the way they work.
> people seem to indicate everything is fine until 3-4 days before the end of the sprint
Sounds like they are afraid they can't be honest. There's something going on there.
2 days to get ramped up, update tooling, dependencies, database snapshots, docker containers, etc. Do all requirements gathering, investigation, and design work. 2 days for code review, testing, handling bouncebacks. 1 day to deploy and do retro.
Oops. Forgot to allow even one single day to do the actual development part of the work.
If that scenario is true, then the one-week-sprint did its job - it exposed the problems that need to be solved. That's way too heavy of a tooling/process burden.
Are you committing too much volume? Too much complexity?
You say that half the team is quite junior: I have found that junior developers often have a more difficult time judging how long something will take more than they do actually shipping a feature. They haven't been through the weeds like senior developers so they don't have that experience of "okay, well this can go wrong this many ways" yet.
> deliver work that ultimately fails the QA process
Hearing this makes me think that it's a complexity problem, tied in with bad estimates.
It sounds like you're committing to too much complexity and doing that with too much volume. Reduce scope, reduce volume and I think you will see better results.
I will add that juniors must be taught to test. In my experience they always think that they need to ship, especially when the manager is pushing and setting deadline. The job of the developers is to deliver working software (this involves testing), not to ship code ASAP.
You test before shipping. Do not deliver something that's not been tested, if you don't have time to test you don't ship, shipping can always wait.
Makes me wonder if there is a deeper issue with the environment (testing tools? business complexity?). Complexity should be reasonable, we're talking startup from scratch, not 10 years old legacy code? Can they run locally? Do they have test data and a test environment?
Junior developers struggle with estimating time so you are going to have a period where they are learning now to estimate how hard something is. Be open about with the team and your management. Explain to them why it's important that you deliver what you promise (dependability).
The other big gotcha is how much time are you spending working on features versus working on the things which enable those (such as testing, monitoring, clean APIs, refactoring, deleting dead code)? If the bias is too far towards features then you'll collapse under the weight of your own tech debt. I've had situations where I had to tell teams to stop working on features and fix the foundations.