What to do with a development team that is starving? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 3 years ago.

Improve this question

It sucks being on the critical path as normal developer, especially if you're late. When you're the senior developer, that the team is looking to for leadership, it's even worse.

When work for most of the team is stalled waiting on some critical piece what should the rest of the team do? We have limited access to the critical piece so others will simply be waiting no matter what we do. When the others are looking for advice on what to do what's a good answer?

Answer 1

Improve unit tests, functional tests, documentation, tools, etc. There's a plethora of things that can be done in down-time while waiting for the critical path to catch up.

Answer 2

While I like the answer about improving tests, documentation, etc., and it is a good one you can also look at:

• Assisting the critical path component, would it go quicker with team/buddy programming?
• Restructuring the critical component into several sub-components that everybody can work on.
• Dummy out the critical component with something, possibly rough, that does basically the same job but possibly not fast enough for production.
• Establish an API for the critical component, fix that more or less in stone, and help to get the basic functionality for that component implemented, (subject to changes in implementation but not API).
• See if you can take early, known problematic, versions of the critical component to work on the remainder of the system where the functionality is "good enough for now".

It is also a good idea to start the "lessons learnt" phase now by recording that such critical components need to be started earlier in the development process, possibly before the rest of the team is assembled.

Answer 3

You need a backup plan for your late deliverable

If a critical piece is already late, there's no guarantee it won't slip even more. What then? You just wait forever? That is not the kind of answer you want to have to tell to upper management.

Build a simulator

One way to manage the risk is to start work on a simulator (harness, shim, stub, whatever you want to call it) to take the place of the missing critical piece.

Does it have a defined interface? Implement it.

Does it have detailed documentation? Imitate it as best as you can.

Is it just someone's idea? See if you can get a prototype.

Then, when they slip schedule again....

That way, when they slip schedule again, you have an ace in your back pocket to close the gap. Not only will your team be unblocked (they can integrate with the simulator), but you will gain a valuable software asset.

If they slip schedule even more, use the time to write automated integration tests (against your simulator, for now). That way, when they deliver the real thing, you can just run your tests and detect any behavioral differences between the mockup and the deliverable. This will let you zero in on spots that you have to revise. As a bonus, you will quickly get an idea of how much they cut corners as their time ran out.

Answer 4

If the critical component has a known interface and if there is no hope of getting it done in a short time, why not build a test double (for example a mock)?

This would allow the team to carry on coding, although the test results would be slightly less meaningful.

Answer 5

Apart from the obvious "do all those things you did not get around to doing thus far", it sounds like you and your team lack the peace of mind to do anything unrelated to the late project. Which is understandable but not helpful.

So the real problem may be to be relaxed about it. I am not saying indifferent. Be concious of your responsibility, of what you can do to help and if that leaves you with time on your hands, enjoy it. You cannot nor have to be on your toes all the time. If you are a leader, I would say this should be your message. Transfering your nervousness to the team will not make a more productive team when it matters.

Answer 6

You don't say what methodology you're using which makes it tricky to advise exactly.

Where I work if there is a blocker, it is every hand to the pump doing whatever they can to expedite the development.

Consider if there might be a wider problem with you as the lead taking on too much. Yes, people will be looking to you for technical leadership but that doesn't mean some of your more able team members can't share the workload if they're mentored.

Aside from this, is there any other non-critical work they can get ahead on? Also, is there any work they've completed that could be further polished (refactored, removing technical debt, documentation, adding tests etc).

If there really isn't anything, give them something - go thru logs, builds, documents, test plans, designs, diagrams, write agendas, arrange meetings, hold brown bag sessions, share knowledge etc. There is always something to do. If people are willingly just sat around doing nothing on the company coin that should be escalated as they're clearly not team players.