Agile Learning Labs

This week on InfoQ - Information radiators: Is low-tech really better?

In this week's InfoQ article, Chris covers the debate over high tech vs.low tech toolsets (what Alistair Cockburn refers to as information radiators) for managing agile projects: eg, which is the lesser evil, killing a tree and taping its carcass to the wall one notecard at a time, or clicking through an annoying heirarchical menu every time you want to see your data?

The focus of the article is a discussion thread on the Xtreme Programming Yahoo Group, where topic is being contested with a great deal of heat.

There is a natural tendency among technologists to prefer technological solutions, but many of the debaters claim that experience has shown the low tech solutions to be best. Ron Jeffries says:

Display important project information not in some formal way, not on the web, not in PowerPoint, but in charts on the wall that no one can miss....A web site doesn't push information at us; we have to go look. A slide show always comes with a meeting and a lecture. A wall chart is there when we are, in our face, always visible.

This makes intuitive sense to me. I think there's something important about making the whole visible at a glance. Imagine how hard it would be to read a novel if there were one word printed per page--we read words in context, not in isolation. I think we experience projects much the same way, and it's important to always have a view of the gestalt.

The Agile Tools blog has an archival post that features pictures of several examples (as pictured) of both virtual and physical task boards. It's interesting to look at them and see which ones make you want to be on that project.

Story-Focused Standups

A widely accepted agile practice is the daily standup meeting, in which each team member shares:

• What they have done since the previous standup
• What they expect to achieve by the next
• Anything that is getting in their way

Mike Cohn recently examined variations that shed additional light on the progress being made toward completing each user story. I wrote about it for InfoQ, and you can find the story here.

Cheers,

Chris

Lean Vs. Agile? No!

In a recent blog post, Martin Fowler explains how the question "Should I use Lean software development instead of Agile?" is based on a false premise. Agile and lean are so deeply interwoven that if you are doing agile you are doing lean, and vice-versa. It inspired me to write this article for InfoQ.

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

What Makes Agile Projects Succeed at Dr. Dobb’s

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,

Chris

Agile Coach Camp on InfoQ

Greetings,

InfoQ just published this article, which I wrote about AgileCoachCamp.

Cheers,

Chris

The Power of Self-Organizing Teams

Greetings,

A lot of attention has been focused on the power of self-organizing agile teams. This power is the foundation upon which Scrum, the most widely adopted agile methodology, is built. Is it hype or is there something there? This month, the Bay Area Engineering Managers Suport Group will experience how a group can self-organize into a team, and how such a team can evolve ever-better ways of working together. Come out and join the fun, now in Santa Clara.

6:30 - 7:00
Networking and food
Judy and Angie will be greeting people. If you need assistance finding us you can call them at 408.733.2374.

7:00 - 8:00
The Power of a Self-Organizing Team

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
Albin Engineering Services

Get all the details here.

Cheers,

Chris

Intro to Extreme Programming

Photo courtesy of akindemir

This past Wednesday, I presented a 45-minute introduction to Extreme Programming (XP) to the Project Management and Program Management Special Interest Group, who meet every week Cupertino. The group was lively and full of questions. I especially enjoyed the chance to discuss XP, as that is where I got my start doing agile software development, back around the turn of the century.

Contrary to popular belief, Extreme Programming (XP) is not writing code while kiteboarding. Extreme Programming is an agile software development methodology created by Kent Beck in the mid nineties, while he was the leader of a large software project at Chrysler. The true genius of XP was selecting a set of 'best practices' that compliment each other and form the foundation for extreme productivity, extreme adaptability, extreme quality, and extreme satisfaction for every stakeholder in the software project.

Here are the slides, and here are some links:
A Gentle Introduction to Extreme Programming
Wikipedia on XP
The original home of XP on the Portland Pattern Repository
A set of XP links, including tools

XP for Project and Program Management SIG

Greetings,

Tomorrow morning I'll be giving an 'Intro to Extreme Programming' talk for the Project Management and Program Management Special Interest Group in Cupertino. The event is open to the public, and group asks for a $2 donation from each participant. We will be giving away a copy of "Planning Extreme Programming" by Kent Beck and Martin Fowler.

When:
July 9
7:30 AM - 8:00 AM Informal Networking
8:00 AM - 9:00 AM Presentation

Where:
UCSC Extension
10420 Bub Road
Cupertino, CA 95014
(408) 861-3700

Cheers,

Chris