During today’s webinar about ALM, I took great pains to talk about what constitutes a real strategy for software innovation, and what an imitation strategy looks like. Many of the questions we receive at Cutter, such as, “What scaled Agile approach should we pursue?” are impossible to answer without a strategy to guide these sorts of decisions. Before talking about scaled Agile, or whatever the topic du jour is, we first must backtrack into a discussion of the strategic imperatives behind these questions — assuming anyone knows what those imperatives are.
One of the hardest aspects to understand about strategy, either for ALM or anything else, is that it’s not written on stone tablets. Strategy is made to be adjusted. In fact, if you can’t adjust it, it will fail.
Therefore, we have to abandon a simplistic view of strategy that looks something like this:
Instead, we must look at strategy as a constantly-evolving interaction among different elements. What are we trying to achieve? What role do you expect different groups to play? What constraints limit their options? We translate these elements into a mission statement, which gives the people participating in this effort a set of simple directives about what they need to accomplish, and why. Today, we’re adding mobile apps to our portfolio. Here’s why, and the part your team will play…
Over time, as we collect new information, we’ll adjust the strategy. The picture of the future state we hope to achieve may change. Perhaps we don’t have enough technical know-how to build apps as quickly as we thought. Therefore, let’s talk about whether the objectives are achievable…
Not everyone who hears strategy discussed in these terms is necessarily comfortable with it. For them, adjustments to strategy constitute a “failure.” The proper response, therefore, is to resist adjustment. Lots of tough talk about re-dedicating ourselves to the strategy, giving 110%, and similar mummery often follows.
I realized, after finishing the webinar, that some software professionals have a similar level of indigestion about changes to the backlog. I’m using the term generically, not just in reference to the to-do list for Agile teams. If someone proposes a change to the backlog, the same tough talk ensues. In the case of Agile teams, the resistance to adjustment happens more often, and more dramatically. We collect new information, or re-consider our approach. We then split stories, re-estimate them, switch around their priority, drop some, and add some. That process is not a failure, though some have seen it that way.
This similarity in patterns of resistance is no accident. A backlog is just a component of strategy. Based on the value we intend to the deliver to the customer, the initial backlog is our first guess at how we plan on delivering it. As we learn more about the customer, our capabilities as a team, and the relative merits of different design choices, we adjust the plan.
Unfortunately, this is not how we depict the product backlog. Post-It notes on the wall don’t convey the fact that they’re just fragments of a strategy that will undergo adjustment. We may run out of time. We may discover a different technical approach with huge benefits, but the price tag of having to re-implement elements that we already have built. The customer’s goals may change.
Still, the Post-It notes stare back at us. We spent all this time crafting the stories, and including the customer to some degree in that process. And now we’re changing all that?
But change it we must. If, from the beginning, we paint a picture like the one above, in which the backlog is merely the current plan for executing our piece of a larger strategy, it might be easier to discuss these changes with the customer. If, as an organization, we embrace the principle that all strategies are subject to constant adjustment, or else they’re not worth a damn, we’ll make even greater strides as software innovators.
[If you missed the Webinar, you can watch it on demand.]