Leading Lean SD

For a development team which spans across countries(eg. a developer in India and another developer in US), developers use CVS,SVN etc. to synchronise the code. And at times this creates confusion if not properly communicated among the team. Does 'Leading Lean SD' talks about such scenarios ? Any techniques or protocols or methodologies ?

Hi,

In agile project management and lean development, how far the leader should be involved in the details? and what is the point at which the delegation started to be abdication?

Regards,
Mohamed

How does communication happen across geographic boundaries? Probably there is not enough about this in the book, but here's a thought:

Open Source teams usually do not have this problem. So how do they communicate effectively? First of all, all communication is text-based (not verbal) and it works because people are working on a opt-in basis. This tells me that while long distance communication will always pose a problem, it is not the driving problem. The overwhelming problem is that there is no opt-in by team members. An interesting thing that an iteration does is to create a team commitment to a deadline - a mutual commitment across all team members. (No partial credit - if someone doesn't get their part done, then the whole thing is late. So better help that person out.)

I think that a team first and foremost needs to make a mutual commitment to a common goal - they aren't told what to do, the agree mutually on what they will do together. Given the opt-in of all team members, the communication will follow. Lacking that, I doubt if any process will adequately substitute.

Tauri Valor wrote:For a development team which spans across countries(eg. a developer in India and another developer in US), developers use CVS,SVN etc. to synchronise the code.

Are both teams on the same page with the philosophy of the repository? For example, "all code in the repository must compile and pass the build/unit tests." I'm curious what kind of problems you are encountering and whether it is specific to remote developers or just communication issues.

JavaRanch is completely distributed, but it is a small project. My project at work has committers from 3 sites and we haven't had extra commit difficulties with the addition of multiple sites.

I think git or Mercurial and other distributed configuration management tool will be a great help in geographical distributed teams.

Mohamed El-Refaey wrote:I think git

I think agreed on processes are more important than the choice of repository. With git, it is possible to develop two disparate branches. If this isn't intended, it can cause larger problems. Nothing against git in my comment - just that processes need to be discussed. Tools aren't magic cure-alls.

Jeanne Boyarsky wrote:
I think agreed on processes are more important than the choice of repository. With git, it is possible to develop two disparate branches. If this isn't intended, it can cause larger problems. Nothing against git in my comment - just that processes need to be discussed. Tools aren't magic cure-alls.

definitely this is right, but thinking in tools and concrete implementation along with thinking about the process is a plus and don't make it is just a 'process' and that is it.

Nevertheless, it is better to have a process first and select suitable tools in the last step. If you start with the tools you are too specific and get mislead by the processes a tool is based on.

----

Mary's opt-in though is what I also find in Scrum and its Sprint planning. A commitment as a team is a pretty good idea.

Actually, it depends ... as tools sometimes is developed based upon concepts and specifications in mind, that is why it is created ...from these concepts it will help identify process artifacts ...