I work in a company where multiple teams each work on different parts of a software product in a vaguely agile/scrum manner. Mostly the organisation works well but there have been instances where a team may make a change without realising its impact on other teams.

Where dependence is known communication has been good, and where dependence is suspected then 'broadcast' emails and informal conversations have also worked well. But there exists a sub-set of tasks that fall between the cracks. Broadcast emails are likely not the solution as they would become too numerous such that the email signal/noise ratio would fall.

I'm contemplating a solution that involves a sort of map of the software, which details all of the various parts of the system and loosely tries to place interacting and dependent parts near to each other. Each developer then updates their position on the map (today I'm working on X and Y), and therefore if two or more developers happen to be co-located (or proximate) on the map then we can see this each day and this could form the trigger for further discussion on possible overlap and conflict.

Is such a method out there and in use? If so what is it and does it work? Otherwise, do you think such a scheme has merit?

  • 4
    Are you practicing TDD, or at least have all of the code adequately covered by unit tests? Nov 4, 2013 at 21:37
  • 2
    What is your repository and deployment scenario? Do all teams work on a shared repository that has one build and deployment? Can you split it into multiple repositories each dealing with different features or components that are loosely coupled and just deployed to the same server? I know you're looking for a process solution here, but most teams solve it with architecture (e.g. SOA).
    – Aaronaught
    Nov 4, 2013 at 21:41
  • We do have localised unit tests, at a larger scale the system is fairly brittle to changes such that 'user journey' scripts tend to get broken very quickly by new work. I would also add that using tests to detect overlap requires work to be performed and checked-in to source control, hence effort has been exerted on development prior to the conflict being detected.
    – redcalx
    Nov 4, 2013 at 21:42
  • 1
    This is definitely a solution that could use solving, but imposing more process on developers is going to get lots of pushback. Perhaps inferring position on the map as a function of files touched/checked out in their local working set. Nov 4, 2013 at 22:07
  • 1
    How are tasks tracked and assigned? How many teams do you have? Nov 4, 2013 at 22:19


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.