aspose file tools*
The moose likes Agile and Other Processes and the fly likes Leading Lean SD Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Leading Lean SD" Watch "Leading Lean SD" New topic
Author

Leading Lean SD

Tauri Valor
Ranch Hand

Joined: Aug 03, 2005
Posts: 166
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 ?


A Moment's insight is sometimes worth a Life's experience.
Mohamed El-Refaey
Ranch Hand

Joined: Dec 08, 2009
Posts: 119
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


Best Regards, Mohamed El-Refaey
www.egyptcloudforum.com
Mary Poppendieck
author
Ranch Hand

Joined: Oct 04, 2006
Posts: 62
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.

Mary Poppendieck
Author of Lean Software Development, Implementing Lean Software Development, and Leading Lean Software Development
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30938
    
158

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.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Mohamed El-Refaey
Ranch Hand

Joined: Dec 08, 2009
Posts: 119
I think git or Mercurial and other distributed configuration management tool will be a great help in geographical distributed teams.
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30938
    
158

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.
Mohamed El-Refaey
Ranch Hand

Joined: Dec 08, 2009
Posts: 119
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.
Rainer Eschen
author
Ranch Hand

Joined: Jan 24, 2009
Posts: 75
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.


ICEfaces book . ICEcube . ICEfusion . Scrum
Mohamed El-Refaey
Ranch Hand

Joined: Dec 08, 2009
Posts: 119
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 ...
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Leading Lean SD