Arthur left the end-of-sprint demo looking unhappy; the developers failed to deliver for the fifth consecutive sprint. Arthur’s frustration was palpable. Each time, they had promised things would be different, doubling down on their planning efforts, and each time, Arthur had relayed the same confidence to the client. He even attended their last planning session, looking for comfort in the fact that things really would be different. Today made him furious. Their failure risked the programme and made him seem incompetent in front of the client.
Arthur told me his developers were very good, but the client insisted on dropping their own staff into one of the teams. Arthur insisted the developers should be sourced entirely from consultancy staff, for no other reason than calibre, but this was brushed aside ‘for the good of the engagement’. Which didn’t change the fact that he had a tight schedule and a deadline-driven client. In a rare moment of vulnerability, Arthur told me his last engagement ‘hadn’t gone too well’ and he couldn’t afford a repeat.
I felt for Arthur and told him I would help. I found that backend developers had been dropped into a frontend team with an unfamiliar tech stack, resulting in poor estimates and overlooked critical tasks, a deliberate attempt to retrain some of the client’s permanent staff. Over time, I reduced the amount of frontend work assigned to the team and added two senior frontend developers to mentor the less able. Arthur was unhappy about training client staff on consultancy time but made the concession. The programme was delivered on time, and Arthur was there for the duration.
If your developers are struggling, perhaps they need better guidance?
Our Software Requirements can help with that.