Agile 2005 - Day One Recap

  • Article

My first day at Agile 2005 was a good one!  I attended the morning keynote delivered by Brian Marick and Bob Martin in the morning.  The afternoon tutorial that I attended was Agile Project Management: Reliable Innovation, delivered by Jim Highsmith.  This post will highlight a few of my personal takeaways from the day.

Agile Project Management

A theme in both the morning keynote and the afternoon tutorial was the role of project management in agile projects.  Just like we've seen in our project, others are seeing the importance of the role of project management as agile methods are scaled up.  The conference seems to be a bit of a coming out party for the Agile Project Leadership Network and the Declaration of Interdependence (DOI).  The following DOI statements were developed by a group of agile project managers in a meeting earlier this year:

  • We increase return on investment by making continuous flow of value our focus
  • We deliver reliable results by engaging customers in frequent interactions and shared ownership
  • We expect uncertainty and manage for it  through iterations, anticipation and adaptation
  • We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference
  • We boost performance through group accountability for results and shared responsibility for team effectiveness
  • We improve effectiveness and reliability through situationally specific strategies, processes and practices

These statements, along with the people behind them, will help drive a shift in traditional project management approaches in the future.

Keynote

The keynote title was "Where were we?  Where are we? Where are we going?".  A few key takeaways for me were:

  • The 'flow of value' (see bullet one of the DOI) is a key component of agile methodologies.  We want to deliver value to the customer throughout a release, not just at the end.
  • In progress metrics are critical for measuring customer value, especially finding a way to measure project velocity in customer valued units.
  • While the agile consultants have been promoting agile 'brands' (XP, Scrum, Crystal, etc), the industry has been picking the best components of various agile techniques and integrating them into their process.  We should expect to see a convergence of agile approaches, a core body of agile knowledge, and a decrease in the importance of the brands.

Highsmith Tutorial on Agile Project Management

This tutorial was broken into two primary parts.  Part one was a review of our understanding of agile project management.  Part two focused on the key enterprise issues associated with agile development.  While there were definitely some valuable nuggets in the session, I was hoping for more new information out of the enterprise issues section.  I think the reality is that Microsoft and a few other large companies have to deal with this issue at a scale that not many other companies have to face.  Here are the highlights / takeaways for me:

  • Regarding the topic of innovation, being able to respond to change late in the cycle is a huge competitive benefit. 
  • To innovate, you need the time to step back and reflect.  An innovation suggestion was to take Friday afternoons off from project work.  Use the time for learning, thinking, and exploration.
  • Focusing on improving quality tends to benefit cost, schedule, and staff size as well as defects.
  • Scope creep has long been considered a negative in project management.  Highsmith proposed that we don't want scope creep, we want scope gallop!  The fact of the matter is that you learn a tremendous amount over the course of the project. You want to take advantage of this learning to make the product better.
  • A useful analogy for predicting the course of a software project is predicting the path of a hurricane.  In the early stages, weathermen have a general idea of where the hurricane is going and the scope of it.  As time goes forward, they have much better knowledge and you are able to pin point the time, location, and scope of the event.  The same is true for software projects.  That doesn't mean we don't try to predict it and get better over time; we just need to realize that we're making estimates with a high amount of uncertainty.
  • Formality doesn't mean discipline, nor does discipline mean formality.  Many agile methods are both highly disciplined and informal.
  • Engineering practices should not be classified as either agile or not agile.  The underlying principles are what make a practice agile.  A personal example is the way we do code reviews on our team.  Code reviews are not generally considered agile, but we do them with a low ceremony approach with a high focus on improving code quality. 
  • Highsmith reviewed the impact that project uncertainty and complexity factors have on the agile 'fit' of the project.  The higher the uncertainty, the greater need for agility.  The higher the complexity, the more structure that is required.  This is essentially the same information that I referenced in Agile AND Plan Driven, although Highsmith also leveraged some very good material from an article that Todd Little of Landmark Graphics wrote for IEEE Software, May/June 2005 titled "Context-Adaptive Agility:  Managing Complexity and Uncertainty". 
  • To manage complexity, you need a strong focus on architecture and integration activities.  These are both areas that we could invest more in for our project.  You also need to manage internal dependencies - something that we are getting better at.

The only disappointment for the day was the rain that came about the time we were going to head to the Rockies game.  Instead, I went out to dinner with a group of Redmondites.  AND I had the time to write this summary for the day!  Sorry that it got a bit long, but it was a productive day.