Agile development’s iterative philosophy sounds great: deliver working software in short periods of time (weeks), allowing the users and/or stakeholders to review the work and suggest changes. These changes get prioritized and incorporated into the team’s product backlog. If the changes are important enough, they get worked on in the next sprint (iteration).
So you iterate. The problem is, iterating is a rework strategy. If you are iterating, you are increasing the number of increments required to deliver the forecasted feature set.
As a new product manager, I’m in the process of recommending a change to one of our products under development. I found what everyone agrees to be a serious limitation, one that is going to cost us several weeks of rework to correct. A change like this introduces a certain amount of organizational anxiety, and it certainly torpedoes the timing of other go-to-market planning already in progress. People are grateful that I uncovered this issue, but no one likes making the payment.
How do you avoid this problem?
Keep it small, keep it themed. The product that we have under development will have future releases. We’re introducing something new, and early on it was easy to see all of the things that we could provide. And like most software projects, it was equally easy to underestimate what it would take to deliver a subset of those features, let alone what we now understand to be a series of releases.
By thinking too broadly too soon, we actually coupled functionality together that should have remained separate and distinct. As a result, we are now faced with the prospect of reworking our foundation; but if we are going to deliver the right product to the market, it is necessary to make this change now. We need to be solid on our delivery that is now encapsulated within a narrowly-focused, specific product theme.
Invest in paying attention. Prior to my assignment, we had a part-time product owner/product manager. This is an organizational fault, creating a problem of “continuous partial attention” that became amplified because this is not only a new product for us, it involves expertise that we had to build because the core capabilities of the product lie outside of our industry knowledge and experience. We needed full-time care and attention (and then some, based on my dance card), not part-time involvement.
Someone needs to be looking at the big picture, how the parts come together, assessing the impact of change on the product as a whole, and communicating. Once I determined that we had a problem, I worked with a variety of individuals across the organization to develop a solid solution, documenting it and communicating it so that everyone could understand it and buy into it.
The goal is to be as crisp as possible about the problem(s) that the feature is targeting before you develop it. It’s a judgment call, but there are times when you want to define as much as possible about the feature before you fully implement it. Build prototypes, communicate how the user interface will look and how the underlying software will behave and discuss it with users or stakeholders, and then implement it.
This leads me to my final point.
Create artifacts. Agile development does not mean “no documentation.” I’ve never been an advocate of writing requirements the size of War and Peace; heavier is not better. However, the act of creating key artifacts forces you to think things through. You should always document enough to capture your thoughts and make sure that they hang together – and that you can share your thoughts effectively with others.
Can you explain the product in few pages? How do the features work together at a high-level? Create artifacts that will be useful in training – they can be revealing. In my case, I found that our product had some constraints that weren’t really necessary, impacting the flexibility that we wanted to plug.