October 31, 2019
Agile project management is receiving a lot of buzz these days, but simply switching from traditional project management methods to agile does not guarantee success. Agile project management works best when it’s applied to the right products and in the right environment.
Let’s start with some background to set the context: In 2001 the Manifesto for Agile Software Development was written, and the term “agile” was coined. This philosophy was initially focused on software development, but due to some impressive early wins, it has since been applied to developing non-software products as well. So “agile” broadly is about developing products within an environment that reflects the values and principles set forth in the Agile Manifesto.
The manifesto discusses four values and 12 principles, all of which should be taken into the mix. However, there are two things in particular you should look at before taking the agile plunge in your product development project:
Is the product that you’re developing conducive to agile? A huge challenge with traditional “waterfall” software development was trying to capture a comprehensive set of requirements upfront upon which the software could be designed. Basically, it was discovered that the customers were mostly unable to tell the development team their requirements using traditional techniques like interviewing, focus groups, or surveys.
Agile practitioners address this challenge by taking an iterative approach to development. The team gathers enough requirements to get started, builds working software, shows it to the customer, and has a discussion to gather further requirements and/or changes. Subsequent iterations take place until the fully functional software is delivered.
Software is conducive to iterative development because the code-base can be easily added to or modified, iteration to iteration. However, a kitchen counter, for example, would be quite difficult and costly to modify once installed. With this type of product, therefore, it makes more sense to spend the time upfront to really understand the customer’s requirements and get it right the first time.
Is your development environment conducive to agile? In traditional development, the customer is heavily involved upfront (to provide the requirements), is largely absent in the middle (as the team develops the product), and is heavily involved at the end (to accept the final product).
The primary problem with this model is that unless the requirements are perfect—and we’ve established above that they hardly ever are—the customer will be surprised and/or unhappy with the end product. At this point, making changes becomes a contentious discussion—the customer has been waiting months (maybe more) and now has to weigh the trade-off of an extended timeline against accepting a product that they’re not happy with. On top of that, any changes will likely be expensive since the end product is fully locked down.
Agile project management addresses this problem by keeping the customer engaged throughout the entire development process. After each iteration, there is a demonstration to the customer where they can modify the requirements and suggest changes. Effective project management would timebox these iterations to between two and four weeks, so the customer is never out of the loop for very long. This all sounds good unless the team doesn’t really engage the customer iteration to iteration.
When there is a single customer for the project, this process can be manageable, unless of course the customer is too busy and just isn’t available. However, it can get complicated when there are many potential end users (for example, if you’re developing a salable product like a motorcycle). You can’t get all potential customers involved, so how do you decide who? How many? Do you have the marketing bandwidth and budget to manage a focus group every month? In situations like this, teams tend to rely heavily on marketing to represent all potential customers, but this may not be realistic to do adequately.