Archive for the ‘Conferences’ Category

• Sponsoring San Diego PMI Chapter Meeting on Oct 28th

  Date: 2009.10.21 | Category: Agile, Agile SD, PMI, Presentations | Response: 0

  This year, the Agile Alliance and PMI formed an Agile Community of Practice.  The community was formed because both sides recognized their is a lot of misunderstanding about each other, yet we often talk about improving the same types of things.  In the sprit of that enterprise, Look Forward Consulting decided to sponsor the October meeting of the PMI Chapter in San Diego and act as an ambassador to the project management community in San Diego.  For those of you unfamiliar with PMI San Diego, their mission (from their website) is:

  “…to serve the professional interests of chapter members by enhancing expertise through project management education, training, and PMI certification preparation; as well as, promoting association and networking within the project management community.”

  In practice, this means helping project managers make connections with other project managers, educate each other on the latest techniques and promote their ideas in their profession.  It sounds an awful lot like what we do at XP San Diego.  This should be an interesting collaboration and I am looking forward to meeting some new people.

• SoCal Code Camp – Nov 21 & Nov 22

  Date: 2009.10.16 | Category: Agile SD, Conferences, Presentations | Response: 0

  I will be presenting three sessions at the LA Code Camp this year.  Surprisingly, I am not going to be giving my Top Ten Refactoring session; I just did not feel in the mood to do it this year.  Have no fear, Llywellyn and Woody Zuill have that topic covered in their excellent Code Excellence for the Average Programmer talk and demonstration.

  The sessions I will be giving are:

  1. Experiencing Agile Through Games: we will be playing as many Agile simulations and games as we can in 75 minutes.
  2. Insights Into Scrum Illuminated by Lean: we do a lot of counter-intuitive things in Scrum, by looking at Lean we can see why they make sense.
  3. Techniques for Improving Distributed Scrum Teams: an encore presentation of my Oct 1st talk at XPSD session about my work in Shanghai this year.

• Agile Open NoCal – Oct 15 & Oct 16

  Date: 2009.10.08 | Category: Conferences | Response: 0

  Wanted to alert folks that I will be attending the Agile Open event being held in Fort Mason, San Francisco next week.  I attended the Agile Open SoCal event in Irvine during September and that was very fun, educational and was a great way to meet a lot of my peers in Southern California.  This event in NoCal will be a good way to network with the folks in the Bay Area.

  Just like in Irvine, the San Francisco event will be run as an Open Space.  If you have not had a chance to attend an Open Space, I highly recommend it.  They are quite interesting, exciting and empowering.  As with many gatherings of people,the most interesting parts happen during the conversations people have with each other.  Open Space is designed to get people who are passionate on a topic in the same room together to talk.  I am sure I will host a lightning talk session and a session to gather Agile games people are using these days.

• My Insights on Distributed Scrum Teams

  Date: 2009.09.28 | Category: Agile SD, Presentations, Scrum, ScrumMaster | Response: 0

  Come to XPSD on October 1st where I will share my ideas and experiences gained while in Shanghai.  I am not sure if I will turn my presentation into a post, but I will give away my key point now: you will have much more impact improving the performance of your Scrum teams by providing soft skill training to the ScrumMasters rather than training on hard skills, i.e. estimation, Planning Poker, Scrum mechanics, etc.

• Dog Psychics for Your Agile Team

  Date: 2009.09.21 | Category: Agile, Communication, Conferences, Transitions | Response: 0

  I was having a really interesting conversation with Susan Elliot Sim at Agile Open SoCal.  I was asking her why is it so difficult to get peer-reviewed articles published on Agile.  She responded by telling me this story, with the instruction to identify the emotions you feel when hearing\reading the story:

  “Suppose I told you I was going to tell you that in order to understand what is wrong with your dog – he’s been limping and you think something is wrong with his leg – we are going to take him to a dog psychic in Nevada and this dog psychic is extremely good, highly recommended and gets great results and you take your dog there.

  You ask the dog psychic, ‘Can you ask the dog if his leg hurts?’.

  The dog psychic talks to your dog and turns to you to say – channeling your dog, ‘Well…thank you for asking about my leg, but that is not what’s bothering me.  It’s my back.  It hurts a lot when I jump up and down off the bed, especially on cold mornings, so could you please get me a ramp to make that easier?’

  ‘Also, I really like it when you come home to play with me during the day and I remember that time we went to the park and chased the birds in the pond, so let’s do more of that.’

  ‘Oh, and I really don’t like that dog food we have been eating all these years.  Yes, I know that I eat it all up and I probably shouldn’t have, but I didn’t want to hurt your feelings cause you do so many nice things for me.  However, since we are finally having a conversation after all these years, I thought you should know.’

  And you respond to your dog, ‘Oh my God!  I never knew you felt this way about so many things.  When we get home, I am going to make all these changes.  I am so glad I spoke with this dog psychic!’”

  So how did you feel after hearing this story?  It is a bit farfetched isn’t it?

  According to Susan, this is experience is very similar to what academic researchers think about Agile – it is nothing more than dog psychics.  That you really have to believe in dog psychics in order to get any value out of them.  In addition, the people who believe dog psychics sound a bit evangelical in talking about how great dog psychics are and yet there is no (scientific) evidence on the mechanics of dog psychics.  I thought this anecdote is a really good concept to keep in mind when we encounter skeptical people; sometimes we just sound loony.

• Agile 2009: My Greatest Coaching Mistakes 2000-2009

  Date: 2009.08.25 | Category: Agile, Coaching, Communication, Conferences | Response: 0

  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.

• Agile 2009: Debugging Pair Programming & Impact of Gender

  Date: 2009.08.25 | Category: Agile, Collaboration, Conferences, Extreme Programming, Pair Programming | Response: 0

  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.

• Agile 2009: Distributed Agile Development

  Date: 2009.08.24 | Category: Agile, Coaching, Collaboration, Conferences, Team | Response: 0

  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.

• Agile 2009: Advances in Release Planning

  Date: 2009.08.24 | Category: Agile, Conferences, Planning | Response: 0

  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.”

• Agile 2009: Touchdown in Chicago

  Date: 2009.08.23 | Category: Conferences, Personal, Travel | Response: 0

  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.