| This story sounds like an artificial lead-in to an "Agile saves the day" follow-up post, but there are other things going on here. There is a lack of ability by the lead to guide the team to sanity. Here's what I see needs to be done: * Stop using agile if you don't have buy in from the owners. Agile is much more dangerous than traditional methods if you do not have the right buy-in from the owners--and that buy-in is not easy to get. Without buy-in, you've just given them the ability to minutely control the expected output without the expense of researching and designing a base set of functionality up-front. It's "free" for them to change their mind--so they will, at your expense. * Tell the lead to stop being a robot. Alice is given a task that is blocked by an old bug. Instead of just assigning a more suitable task to Alice, she is told to bring in another developer to help her work through it. Why stick with this task? The world isn't binary, so break up your task and assignments into something that fits the talent you have. Yes, developers are not fungible completely, but there should be tasks that anyone should be able to slip in and do. It's the lead's role to be able to decide which tasks are assignable to someone new with reduced risk. Maybe start them out on just identifying the cause for Bug XXX--not actually fixing the code. Or have them confirm and document repro steps for the bugs that are coming in every day. You don't have to always give developers development tasks, especially their first week. * Tell the lead to start taking care of the team. The story mentions developers who got pulled into meetings, preventing them from doing their job. As a lead, you should be providing some interference and getting in the way of these type of requests. * Tell the lead to stop over complicating things. Why are there so many bugs? Part of this is that the employees are overworked. I suspect that part of it is also that the framework and processes are over-complicated. A custom build of a tool that completely breaks everything? That's a process smell. The lead needs to figure out why its so easy to introduce bugs in their system. "The requirements are all necessary" phrase also fall into the implementation as well. Think YAGNI and KISS. As for the loss of productivity by "Alice": every new developer adds growing pains to a team, but that definitely should not persist. It's a short-sighted view that one week of lost productivity will erase any long-term benefits of an additional employee. But, you need to plan training time for a new employee into your schedule. Also, since it doesn't sound like you have it already, have the new employee document the steps for the next new employee. That will help reduce the growing pain costs over time. |