Greetings from Agile2008 in Toronto!
To say that I have been overwhelmed by the conference would be an understatement. With 1600+ agile folks here, I am constantly running into old friends, people that I met at previous conferences, and my agile heros. The sheer volume of knowledge and expertise that is being shared is beyond my ability to describe. Wow!
Tuesday, I facilitated a session titled:
What Makes Distributed Agile Teams Succeed (or Fail)?
The session drew about 15 people, almost all who have significant experience on distributed agile teams. As was the case at Agile Coach Camp, the level of experience in the room led to some rich discussions. In 90 minutes, we generated and ranked 25 success/failure factors for distributed agile teams. We used the Group Wisdom Without Groupthink process, which was fitting, as the keynote speaker at the conference was James Surowiecki, author of The Wisdom of Crowds.
Here is the ranked list of success factors for a distributed agile team, as determined by the group.
Tier One - The definition of "done"
This was brought up as the number one thing that derailed projects, or kept them on track. Having a well-defined, well-understood, and well-enforced definition of what it means to be 'done' with a story, can keep a team from getting mired in unexpected work near the end of the development cycle, and prevent the accumulation of technical debt.
Tier Two
Demos early and often
Onsite training
Executable requirements
Pride, ownership, and initiative from team members
Tier Three
Avoid "West vs. The Rest"
Daily standups - Doing whatever is needed to make them work for the team
Remote pair programming
Design for Conway's Law
Everyone is present at iteration planning
Tier Four
Cultural training, including on your own culture
Determination to be remotely visible
Team task selection, just in time instead of 'assigned' at beginning of sprint
Video conferencing
Mixed experience levels on all teams
Awareness of cultural norms
(Hmmm, perhaps this and cultural training could have been combined. Perhaps they could have even been grouped with 'West vs. Rest')
Tier Five
Avoid time-zone blocks
(e.g. the Pune team can't move forward because they need something from the Chicago team)
Some co-location, especially at the beginning of a project
Have the right team (hire people who will fit into the distributed environment)
Time-boxed stand-ups
Attention to iteration length
Daily, time-boxed design discussions
Don't pretend the distance isn't there
Give the 'remote' end of the conference call priotity in all discussions
(The idea is to pause all 'local' conversation whenever the folks on the conference call speak. It sounds simple, but it can have a powerful effect on how included they feel)
The "Buddy Concept", each person has a remote 'buddy'
You may find it interesting to compare these results with those for groups who have considered the question: "What makes agile teams succeed (or fail)?"
Dr. Dobb's Architecture and Design World
Agile Coach Camp
The BayAPLN
The 2008 Chicago Scrum Gathering
P-Camp, a gather of Agile Product Managers
Silicon Valley Code Camp 2007
Agile Open California 2007
Cheers,
Monday evening more that 40 people turned up at a ‘Birds of a Feather’ gathering to consider “What makes agile projects succeed (or Fail)?” as part of Dr. Dobb’s Architecture and Design World in Chicago. In 90 minutes the group generated, discussed, and ranked about 40 different answers to this question, while enjoying some pizza and beverages.
Below, I’m listing all of the ideas as ranked by the group. I’ll elaborate on a few of the ideas that the group focused on. I’ll also provide links to the results from other groups who have considered the same question.
Tier One
* Discipline and leadership
A successful team will take a disciplined approach to implementing agile practices. The group felt that a key to this actually happening was the presence of leadership.
* Good communication
The group felt that this was vital to the success of any project, and that agile methods fostered better communication. Even so, a key differentiator between agile projects that succeeded and those that didn’t, was how easily and honestly information flowed between people on the project.
* The right people
There was a fair amount of discussion about what ‘right’ meant. Ultimately, the group felt that it includes: technical skills, communication skills, interest in doing agile, motivation, and ‘fit’. After the workshop I noticed that there is overlap with the item ‘Team-oriented team members’. If these items had been combined, this would certainly have been the top item.
Tier Two
* Stakeholder buy-in
* Team-oriented team members
* Dedicated resources
Tier Three
* Experienced agile champion on the team
The group talked about the advantages of having an experienced agile practitioner on the team full-time, as well as available to do evangelizing and coaching within the organization.
* Customer participation
* Test Driven Development
* Lack of design (-)
* The right tools
* Good use cases
* Good relationship with customer
* Rapid Prototyping
* Small team size
* Vertical stories
Tier Four
* Planning for refactoring
* Small project size
* Requirements-based testing
* Not needing lots of documentation
* Realizing that agile is no silver bullet
* Open work environment
* Adaptable requirement
* Inexperience (-)
* Data planning
* Flexible customer
* Know your data
* Flexible project size
* Compact stories
* Good product owner
* Appropriate contract
Tier Five
* Avoiding schedule slip-n-slide
* Story completion
* Good interface between agile team and rest of organization
* Short timeline
* Agile stakeholder experience
* Excessive changing requirements (-)
* Embedded architect on the team
You may also be interested in seeing the results from groups that have considered (essentially) the same question:
BayAPLN
Chicago Scrum Gathering
P-Camp 2008
Code Camp 2007
Agile Open California 2007
Cheers,
