Stopped in today to J.B. Rainsberger’s interesting discussion about his big misses in the last nine or so years.  He used an interesting format of people sitting in a circle instead of sitting around conference room tables.  Here is a list of the interesting ideas I jotted down while listening to the conversation.

• Practices like pair programming, timeboxes, iterations, user stories, release planning, etc. are neither good nor bad.  They are either appropriate for the environment or not.
• One resistant person is more than enough to bring down an Agile team.  It is better to have people who have a similar style work together and form your Agile team around them.
• If you are going to do something a stakeholder does not expect – like deliver early or spend time fixing broken tests – be sure to give them advance warning.  In low trust environments, this can be a good first step in building trust.
• If the response of someone is not what you expected, you need to spend time understanding the significance of what you said and how it was interpreted by the listener.  Consider the worst possible interpretation of your actions to reduce the number of communication surprises.
• Use smaller user stories when a Team is beginning with Agile to build a sense of accomplishment with the Team.  As they become more experienced and skilled, use bigger stories.
• Training is about increasing your capability and improving your skills.  Coaching is about reducing interference and improving the signal-to-noise ratio.
• Coaching is about giving people a new way of working together.  All the Agile tools and practices are worthless if people cannot talk with each other.

Mat Wayne ran an interesting session about overcoming resistance to pair programming organized around personas.  On each table there was a description of a different persona and some ideas on why that persona might resist pair programming.  Our job was to discuss in groups why the persona was resisting pair programming and some ideas on how to overcome the resistance.

I tried to make the case that gender differences was an important consideration in resistance to pair programming.  In a room full of (mostly) men, it was hard to be taken seriously, especially after the few women in the room were pretty vocal opposing my viewpoint.  However, I think the people in that room\conference self-selected to be interesting in pair programming.  The sample was biased toward ignoring the impact of gender on pair programming.  Remember, the purpose of the session was to help people who do not want to do pair programming to become more interested in it.

After talking with some friends, I think there are more gender dynamics at play when men and women work together programming and some of these might explain why women are not interested in (pair) programming.

• Pair programming requires two people to work in close proximity.  Some women might not feel comfortable sitting less than two feet from a male co-worker for most of the day or not be interested in the unwanted attention from men.
• Male programmers have a really strong geek hierarchy thing going on.  The more uber-geek you are, the more status you have and the bigger your voice on the Team.
• Get more than three men together and you begin to create a “locker room culture” that is a normal part of male bonding.  This is often characterized by seemingly harsh, personal put downs of your ideas by your peers.

I don’t think any one of these things is a definitive cause, but I do believe they add up and discourage women from participating on programming teams.  As coaches, we need to be mindful of gender and provide a safe environment.  It is not that women need extra help, just men need to be reminded to act like adults.

After searching and searching for this ballroom (this conference center is a bit of a maze), I finally found this session being held by some folks from Microsoft, Ade Miller.  They were talking mostly about their observations of working with teams in South America, but did talk about working with Teams in Asia.  This session was attractive to me because I was looking to see what other experiences people were having with distributed Teams and if my recent recommendations were on the right track.

Here is a list of ideas I jotted down while listening:

• Get good tooling to minimize the difference being in the Team Room and out of the Team Room.
• Select tools that are adaptive to the Team’s processes and ways of working together.
• Plan to travel; use the lower rate of the offsite people to offset the travel costs.
• Always have one guy from overseas in the main office.
• There will always be people difficult to synch up with due to time zone differences, so nominate a representative in the Team Room to advocate for them.
• Avoid component-based architecture and thinking to prevent local optimizations.
• Make sure every Team has a coach to remind them of the underlying principles and values of Agile.
• Have a list of books that people should read when onboarding.

As it turns out, I was mostly in the ballpark.

Stopped by to see Jim Highsmith’s session to pick up a few good ideas.  Not surprisingly, there was a good deal of focus on release planning, some focus on value and discussing features along a continuum.  In many traditionally managed products, there is an emphasis on the up-front planning, or as he termed it “wish-based planning”.  During this inception stage, management spends a lot of time trying to answer the following questions with a high degree of precision:

1. What are the main dependencies in this product?
2. What sort of risks do we expect?  How do we mitigate them?
3. Do we have enough resources?  How will they be distributed?
4. What sort of value will this product provide?
5. How much will it cost us?
6. When will the product be delivered?

Of course, Agile products want to answer these questions as well and we often figure this out during release planning.  We want to know early on if the product is feasible and does it align with out goals and strategic objectives.  Where Agile teams differ is we recognize the release plan is only a guide and is flexible.  Another key difference is that an Agile team will estimate on the user story level, not at the task level.  We perform the task estimation Just-In-Time.  The creation of the release plan is really a conversation meant to answer all these questions.  Finally, while most products benefit from a release plan, there are cases of highly experimental work where an iteration-by-iteration approach is valuable.

Another useful concept discussed at the session was the continuum of completeness for features.  Instead of assuming all features have the same level of completeness, have conversations about what needs to be delivered using this model:

    simplest -> basic -> nominal -> extensive

With this framework in mind, we now can have discussion around trade-offs and partial delivery.  Why develop an extensive solution when the market leaders are only providing nominal?  Is that are market differentiator or just engineering gold-plating?  Or maybe we can only afford a basic implementation?  At least we can make these decisions at the product level instead of the engineers making these decisions for us.

Finally, Jim made a big point about understanding the value for a feature.  From his experience, even a fuzzy number around the value for a feature is acceptable if detailed data is unavailable..  In his words:

“If the product group does not have the time to calculate the value, then the programmers do not have time to estimate the cost.”

I’m in town for the Agile 2009!  This is my first big Agile conference and I am looking forward to all the sessions and meeting up with some colleagues.  Of course, with any big conference there are just too many sessions to attend.

Yesterday, I had lunch with an former co-worker and she could not remember the estimating technique I showed her group last year.  I promised her I would add a link to Planning Poker on my website so she could find in the future.

Mike Cohn first wrote about Planning Poker in his book, Agile Estimating & Planning (a VERY good book everybody who is doing anything Agile should read).  Mike’s great insight was to take a well-tested, accurate estimating technique and make it into a game.

Just wanted to let people know that I will be the speaker at the XPSD meeting in September.  I will be talking about my experiences coaching Scrum teams in China and my insights on what essential skills a ScrumMaster needs to be successful.

Update: this was postponed until Oct 1st due to my knee surgery.  The topic will be the same – CEN 09/03/2009