Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

The setting: Multiple development teams, lots of dependencies and constraints.

If one team is blocked on developing some code, getting service calls, or moving to a QA environment, what are ways for teams to creatively look for work-arounds to their issues?

share|improve this question

closed as too broad by MichaelT, durron597, Snowman, GlenH7, Dan Pichelman Jul 21 '15 at 15:17

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

Sounds like a deadlock. Reboot. – Michael K Feb 14 '11 at 15:24
Could you be more specific please? – c_maker Feb 14 '11 at 15:33
Suggestions for ways that a team can continue to develop and move forward while blocked by outside circumstances. What would/should a development team look for? – Agile Scout Feb 14 '11 at 15:35
up vote 10 down vote accepted

For a short block, (3 days), accept it and do something else - read ahead, i.e. investigate tools and techniques that will be needed later - pay off some technical debt, i.e. do code reviews, look through //TODOs.

  • Investigate to make sure you understand what the real block is right now. It might not be what you think. Don't delegate this. Look into it yourself.
  • Particularly if your company has a culture of blame shifting, it may be that the "we're held up by them" is a euphemism for "the schedule is too tight".

If the block is going to be long, you may need to move someone to another team, or 'donate work' to another team. Someone may need to work outside their normal job description.

Learn from it. The problem originated in planning when a way to sufficiently decouple different activities was not found.

share|improve this answer
+1 for "Learn from it" – DevSolo Feb 14 '11 at 16:12
+1: "The answer to your problem may not be the answer to your question" – IAbstract Jun 9 '11 at 0:31

OK, here is my 2 cents worth. First, can the block be resolved with some discussion of the other affected parties? Sometimes just talking to people will work wonders. Sometimes people aren't aware they are causing a work stopage for someone else. Sometimes, you need to go higher in the chain of command to get someone to understand that your work is higher priority and needs to happen first or the task they need to do for you needs to move higher in their priority list.

Next, what else can you do until the circumstances clear. Well what tasks are not on the critical path for that particular change? If I can't put this change on QA right now can I work on getting this other task done instead and then loading both to QA together? In many way the most important part of this when you are blocked is to look for what isn't on the critical path of the blocked task. Just because I can't move an SSIS package to QA right now doesn't mean I can't work on an SSRS report. Can you get code reviews within your team done in the meantime or write unit tests for the next chunk of work (or unit tests to cover existing code if you don't already have a full suite of tests)? Do you have a dev who is behind on some other tasks and could use some help in the short term? Can you do a little pair programming in that case?

What can you do to help resolve the blockage. Can your developers help out the others by doing code reviews? Are there small tasks for the blocking team that you can take over to get the blockage resolved more quickly?

Sometimes an unavoidable delay is a great time to institute new process changes that you want to do, but haven't had time for due to deadline pressures. So re-organize your source control if you need to or set it up if you don't have it, start writing tests to get started on TDD, set up a knowledgebase wiki and start writing articles for it, etc. Assign each stalled developer a topic to research and provide a training session on. Create some in-house tools you have been wanting or research the various bug trackers out there and test drive a few to decide which one to use. Install a new project management system. Refactor existing code. Etc.

Are there tasks you are supposed to do for the project, but nobody really likes doing such as updating documentation? This is a good time for this.

Finally, why are these circumstances happening? Did you do a poor job coordination with others? Start working right now on improving that so that you have fewer of these down times in the future.

share|improve this answer
Oh! I like the suggestion of updating documentation. Good one! – Agile Scout Feb 14 '11 at 17:00
??? updating documentation? ... who would do that??? +1 – IAbstract Jun 9 '11 at 0:32

Work around to do what? If the block is that management doesn't know which features should be implemented or bugs to fix first, this does put new work on hold for the most part as the team may well choose something that management may cry, "I'm not paying for you to do that!"

Would resolving any technical debt, refactoring, and doing some code analysis make sense here? That's where I'd try to go but do be aware of the possible pains one could run into here.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.