Agile Learning Labs

Scrum-a-licious Morning

I just had the pleasure of leading a half-day Agile/Scrum workshop for one of my clients. The goal was to do some education and get some ideas generated as to how this company might adopt agile practices. The group was smart, curious, and very engaged.

Several years ago I read the book about how this company was founded, and how it grew to be a major software company. It was neat to walk around the offices, knowing how it all began.

Talk about a great way to spend the morning. :-)

Cheers,

Chris

The Great Agile Spec Showdown!

Agile evangelists claim that extensive written requirements and specifications can be dispensed with in favor of lighter-weight 'stories'. It sounds easier, certainly, but can it really be as good? Won't all of the important details get lost? Join the Engineering Managers Support Group as we stage a participatory showdown between traditional and agile specs. May the best specs win! Of course, we will also feature our usual round-table discussion of your pressing engineering and leadership issues.

This month, our new host is ILOG, makers of market leading business rules management systems. They are providing us with meeting space and pizza!

We also are proud to announce that JetBrains, makers of IntelliJ, ReSharper, and TeamCity will be raffling off a copy of any one of these products.

6:30 - 7:00
Networking and food

7:00 - 8:00
The Great Spec Showdown

8:00 - 9:00
Round-table discussion of your engineering management issues
Bring your questions and get ideas and feedback from your fellow engineering managers.

Our Sponsors:
The Technical Management Institute
ILOG
JetBrains

Get all the details here.

Cheers,

Chris

What Makes Distributed Agile Teams Succeed - At Agile2008

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,

Chris