Archive for August 24th, 2009

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