Andy Singleton says yes!
Andy says that if you accept that development will be distributed and get on with making it efficient it leads you to question a bunch of common practices.
Don't do interviews.. and Don't do estimation.. were my favorites.
Andy's company Assembla pull together a bunch of open-source and internal tools to set up a tool chain that lets lots of people work on the same project at once, gives visibility to your customers and tracks progress.
Andy also suggests that when a project is just starting up you can pile on loads of people and let it settle into a good team. This goes against my current experiences with development teams. In my experience you need to get 2-4 really smart people to do some vertical stripes through your application to flesh out an architecture. Once that is done.. then you are ready to start scaling the team up. Bringing too many people on early leads to too much code before the architecture is set. This leads to lots of code to refactor as develop and understanding of the domain.
Having said that... the initial architecture decisions you are making tend to be... How should we separate the domain logic from the presentation logic? How should we use Technology X to implement the GUI?
These things seem like such solved problems to me at the moment. I can't understand why they take so long to get in place. For each technology stack there should be something like Rails where you just fill in the bits that are specific to your domain.
Back to Andy... I'd love to hear more about how the first few weeks of his projects go. He claims to be having good success, so I would love to know more :)
I guess I'll start reading his blog.
1 comment:
Hi Nigel,
Good thoughts.
The title 'Can Distributed Agile Work' hits me as provocate although I know that was not your intent. Reads, to me, kinda like:
'... well if you don't work agile can you be agile?'
(You know me)
The first value in the
Agile Manifesto, that defines 'Agile', is:
Individuals and interactions over processes and tools
The inherent consequence of a 'Distributed' team is reduced or compromised communications. This is futher supported by the principles behind the Agile Manefesto:
"The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."
So is this a 'class B or C' Agile approach?
Not to say that distributed teams can work, as people will always trump process, but it aint and Agile approach. Just wrong words, who cares if it works?
You see I interpret his quote:
... if you accept that development will be distributed and get on with making it efficient it leads you to question a bunch of common practices.
As being 'if you accept we have a compromise to an Agile ... how can we make it work?'.
My second thought is in response to your comment:
These things seem like such solved problems to me at the moment. I can't understand why they take so long to get in place.
You know what I'm going to say don't you? It is a matter of 'why are we here'. You assume that everbody is there to deliver working product. But, sadly for you and me, looking busy and being very very late is more likely to delivery you a pay rise and job security that exposing true progress, doing the right thing, and delivering as soon as possible.
See ya
Rob Smyth
Post a Comment