Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
4  
Are you practicing TDD, or at least have all of the code adequately covered by unit tests? –  Robert Harvey Nov 4 '13 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 '13 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. –  locster Nov 4 '13 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. –  Steve Evers Nov 4 '13 at 22:07
1  
How are tasks tracked and assigned? How many teams do you have? –  Aaron Kurtzhals Nov 4 '13 at 22:19

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.