One of the things that has been striking to me about the expanding field of business agility theory is how many things it can be applied to. I thought it might be interesting to share business agility theory applied to the major articles in a recent issue of Sloan Management Review. My apologies to the authors if I have distorted their message in any way.
Getting the Best From Corporate Functions
Campbell, Kunisch, and Muller-Stevens suggest that corporate functions “don’t get enough strategic direction from the CEO.” They suggest a four-step approach to fixing this:
1. For each function, define key sources of corporation value-add.
2. Review function strategies annually.
3. Develop a corporate initiatives matrix so function execs can see how their efforts relate to those of other functions and operating units.
4. Break out corporate services so they focus on unit support rather than control.
From an agility point of view, several things about this strike one. First, in an agile world, all corporate functions should be about service rather than control. Or, more exactly, they should view units (not the CEO) as their immediate customer and they should be mindful of the ultimate customer (the business’ actual customers). This is not to say that no “control” goes on; it just says that at the same time, the function and the unit are exchanging information, the unit seeking information to perform better, the function seeking information (and not just “deviance” information) in order to have the overall corporation perform better.
Second, why is the CEO getting in the middle of this in the first place? Hasn’t the CEO got enough to do? Is it really necessary to impose a process where the function is periodically checking back with the CEO to see if the function is doing the right thing? Shouldn’t we be instead encouraging better understanding of the ultimate customer in each function, and how to integrate with other functions and the unit to respond to and if possible anticipate the needs of the customer? I have been watching the field of agile marketing, and they propose an integrating function for marketers that allows functions and units to interact in just this way on a per-product basis. Since marketing typically does have something similar to the CEO’s strategic vision, plus somewhat of a direct line to the ultimate customer, that sounds like a better model to me.
On the plus side, this approach has the merit of at least establishing a closer link to the ultimate customer via the CEO. On balance, in terms of moving towards business agility, this is likely to be a plus. Business agility theory suggests that any other benefits are primarily a side-effect of that increased agility.
Investments Aimed at Revenue Do Better Than Those Focusing on Cost
Mithas, Tafti, Bardhan, and Goh report a study that suggests that IT investments (especially those aimed at new-revenue generation) offer better return than ad or R&D spending -- and that this return superiority is increasing over time. They conclude that corporate should favor IT spend aimed at new revenue over spend focused on costs.
This finding sounds suspiciously like my analysis (based on an Aberdeen worldwide survey) in 2009 of agile software development. Software continues to become integral to new-product differentiation in more and more industries. Based on the returns of switching to agile development in the survey, we should expect increasing agile software development to increase profits and decrease costs in new-product development, and only decrease costs in the other two categories of the business (risk management aka disaster handling, and ongoing operations). Therefore, permanently improving new-product development agility in IT will increase profitability more than operational initiatives (typically aimed at reducing costs) and risk management initiatives (typically for regulatory compliance or to reduce the negative risk of disaster). And, by the way, agility in whatever area tends to reduce the negative risk of disaster and increase the positive risk of unexpected additional earnings or “free” cost reductions.
Note, by the way, that business-process spending, if it connects to new-product development and the ultimate customer, can have a positive impact equal to that of investing in new-product development agility.
The study itself covered the years 1998-2003, well before agile development was present in significant amounts anywhere. My feeling is that what we are seeing is identification of one of the ways agility works: it maximizes the effectiveness of new-product investment that is already paying off in other ways, and therefore, subtly, shifts ever more investment into the “biggest bang for the buck.”
Growing Into New Countries Case by Case
Bingham and Davis find that companies use both direct and indirect approaches to the countries they enter, as well as starting off “soloing” or “seeding” by using local companies for part of the initial entry. They conclude that key determinants of success are the company’s initial skills in each, plus their ability to adapt their approach to a different requirement of the local market. They recommend, among other things, pre-training in the new countries and learning via local companies.
From a business agility point of view, the reaction would be, I suspect, this is news? Something is amiss in a globalizing company’s agility if they are not already incenting to focus on the next country entry, and the next, and changing to meet the needs of each. Instead of swinging the entire corporate superstructure ponderously around when the new target proves difficult, the corporation at every level should be ready to push their antennae out to the ultimate customer the moment the decision is made to move, and to achieve it by the path of least resistance – whether that be soloing or seeding – always remembering to keep a channel open past the local company to the ultimate customer. Business agility theory suggests that, usually, focusing on the change itself, rather than increasing profits or cutting risks with no change, leads to the most profit and the least risk.
Patent Agility
Kappos and Graham argue that common patents should be applied worldwide in order to speed patent issuance. By all means; such standards will simply speed issuance, not decrease patent quality, more or less. But agility theory sounds a cautionary note here: increased speed without increased effectiveness only provides one-quarter of agility’s benefits, at best, and at worst can actually double down investment on an un-agile process.
I would suggest that today’s patent process is over-balanced in the direction of the intermediate customer, the business, rather than the ultimate customer, the business’ customer, and this will simply exacerbate the problem – the problem being that there needs to be a better mechanism to allow patent offices to move in sync with both sets of customer. A half-measure may be to reward “offensive” (moving towards the future) patent applications more than “defensive” ones. A more proactive one might be to vary patent time frames as the balance shifts between the business’ needs and the ultimate consumer’s needs.
Major Change Requires Major Skepticism?
Johnson, Yip, and Hensmans study companies achieving successful major change (forced and unforced) and find that the best at it have a tradition of challenging the status quo “constructively” (a very vague term) and getting around corporate rigidities by establishing informal channels. Their specific recommendations include some odd ones, including non-intuitive promotions to “spread the worldview” of CEO successors and “encouraging tension.”
This is an area where business agility theory has no clear answers as of yet. System dynamics suggests that, no matter how well patched, corporate processes inevitably fail, sooner or later, catastrophically. Agility theory says that the time to failure can be extended by embedding constant incremental improvements in these processes; but it does not say that the time to failure can be extended indefinitely. It might possibly be that less-agile urges towards major change will indeed be better for the business overall by ensuring more frequent avoidance of this type of failure than more-agile urges towards incremental change that simply decrease this type of failure’s frequency.
What we can say, however, is that steps like “ensuring that decision making allows for [constructive] dissent” do very little if anything for business agility. In the agile business, it’s rarely a matter of “dissenting from company policy”; it’s more a matter among choosing among options for change, with the customer being often the ultimate arbiter. The customer doesn’t care whether you, the CEO, set a business policy or not; they want what they want, and your business policy is simply a constantly shifting guideline on how to respond, a guideline that you want your organization itself to evolve, rather than constantly feeding questions back to you.
Turn the Company’s Beliefs Into Strategic Success?
Goddard, Birkinshaw, and Eccles argue that the beliefs of its employees are a key company differentiator, and therefore should be consciously a part of the company’s strategy. They then suggest ways of evolving these “belief strategies” as needed via such tactics as discovering, discarding, marooning, and neutralizing (the details aren’t pertinent to this discussion). In a sense, this article puts the psychology of the company on the analyst’s couch, identifying the company’s early experiences and their manifestation in the company’s subconscious, and suggesting ways to make these conscious and so understand how to move forward from a frozen neurosis.
Business agility theory sounds an extremely cautionary note about this. One of the real dangers of focusing internally rather than on the ultimate consumer is that the neurosis will turn out to be narcissism: the belief that one’s image of the customer – an image reflecting rather one’s self – is the reality of the customer. Raiding other company’s “belief strategies” is a rather poor patch-up for this: other companies typically have the same problem.
This concern is particularly appropriate when you consider that a recent IBM CMO survey showed that the gap between the way the CEO and CMO viewed what the company should be and the actuality of the way its lower-level employees thought it was, was huge. In essence, the employees saw the company acting, in all sorts of ways, counter to what it wanted to send out as the corporate brand.
What agility theory would suggest instead, I would guess, is that businesses (a) reality-test their corporate function’s belief systems against employee and customer perceptions before they do anything about them, and (b) consider how agile the “belief strategies” remaining after this step are. In other words, how do we set up a process so that we are agile enough to reach the point of being in sync with a new belief strategy, and how do we evolve it agilely after that? If the organization does not do something like this, I would guess, a “new belief strategy” may in fact make the company even less agile, by reinforcing corporate narcissism.
New Business Model or More Agile Customer Interaction Process?
Amit and Zott argue that developing a new business model (which they define as a new system of connecting with the customer) has a much better return on investment today than new-product development. They then go through ways of creating the best business model (not pertinent here), and close by suggesting some fascinating questions (excerpted) that the business should ask itself when creating a new business model:
1. “What perceived needs can be satisfied through the business model design?
2. Who should perform each of the activities in the business model, the company, a partner, or the customer?
3. How is value created through the novel business model for each of the participants?”
The reason these questions are fascinating to me is that they create a new process that specifically requires that the business try to put itself into the mind of the customer (or partner) and ask what value they see. That is fundamentally different from imagining that the customer is like yourself; and it is fundamentally more agile. Bravo to the authors for intuitively understanding the power of such an approach.
The other key point they are making, however, is undercut by their suggested use case – electronic publishing. It seems to me as I examine that use case that what they mean by new business model development and what I mean by new-product development are, at the least, extremely difficult to divide into two separate categories. What they would call a new electronic publishing business model, I think, I would call new electronic-publishing product development that includes a new business model. Had one started with the product and evolved agilely to the new business model that it implies, what would be the difference in the end? And that is what agile new-product development could, if enfolded in an agile cross-product business strategy, have done.
How To Never Become a Better Leader
It was as I read this article that the idea that agile is better struck me with particular force. Toegel and Barsoux argue that incipient leaders should “recognize and manage their strongest tendencies.” Don’t be too composed; don’t be too excited. Don’t be too much of an extrovert; don’t be too introverted. Don’t innovate wildly in all directions; don’t be too conventional. Don’t be too tough-minded dealing with others; don’t be too considerate. Don’t be too perfectionistic and detail-oriented in deciding something; don’t just make decisions immediately. Understand when you are leaning too much one way or another, and then correct.
OK, rather than critique the authors point by point, let me just say what I think business agility would recommend, and recommend with great force: teach the leader how to think agile. Whatever the flaw, it has a counteracting force. Too composed? It’s not a question of being composed, it’s a question of being focused on change. It’s not a question of whether you panic on hearing bad news, it’s a question of whether you immediately pass on to a positive plan to not only deal with the unwelcome change, but make hay out of it. Too introspective? Focusing on change means reaching out to the ultimate customer and others to get the next feedback as you move toward change in a very structured format. Your need to be alone will still be satisfied; your increasing interaction with others will be encouraged and rewarded.
Too innovative? But if you innovate too much before you see the customer, most of it is wasted. Too inclined to make decisions quickly? Then you’ll just have to keep undoing them when you get your feedback from the customer – which will make the decision-feedback loop for you shorter as you try to solve the problem by seeing the customer faster.
The final dichotomy is tough vs. tender; and it gives me another opportunity for talking about a technique I learned back at Prime to ensure the very best agile customer interaction. It’s called “reflection” – no, not that reflection. What happens is that when someone says something to you, you reflect back to them first of all your understanding of what they were trying to say – no shortcuts, no imposition of what you wanted them to say, put yourself in their shoes saying it, and preferably with the feelings they had when they were saying it – and only then say something in direct response to what they said. It’s awkward at first, but over time you learn what works and can telescope your response. Just never try to skip a step at first – because you will inevitably put your own spin on what they are saying, as you have been doing all your life.
Now think about either the tough or tender, but in each case agile, leader applying this technique. There’s no point in being brutal, because what really matters is the change you want to accomplish. Instead, you understand the person’s concerns via reflection, and show them how the change is safer for them, and then expect them to get to it, because they like safe change. Likewise, if you are tender, the very best thing for the person is to do safe change along with you, and it’s a very positive message to give. What feelings to hurt? You’re offering them a way to succeed, and showing that they get the best marks by collaborating with you as you both seek out the best, as yet undetermined, safe change.
Have you noticed the agile way is not “don’t do this, don’t do this”? It’s “make this change, it’s going to be the best thing you could hope for.” Best of all, that’s almost certainly true, if they last over the long run, and probably true in the short run.
Project Baron or Agile Federation?
I’m just going to comment on this one briefly. Gann, Salter, Dodgson, and Phillips argue that organizations of several little very agile groups off doing generally the same things must make sure that corporate serves their interests and integrates them effectively according to the degree they are presently tightly or loosely interconnected. My agile thought here is that the “corporate-barony” dichotomy here is artificial. These are relatively agile groups; and the corporate “brand” should be an evolving umbrella, not a straitjacket constraining each barony to integrate effectively with the others. The “inefficiency” when some groups do not share corporate resources with others is far less concerning than the remaining lack of agility because these groups are not tapping each other for additional sources of insight about their customers. Time to develop your own contacts with the whole gamut of customers to figure out just how far short they are failing, and give them feedback. That’s what corporate is really selling in these situations: cross-pollination. Let’s decrease the control emphasis and increase the corporate information – not resource – value prop to the barony.
Lego as a Model of Involving Customers in Product Development
Antorini, Muniz, and Askildsen hold up the Lego Group as a model of how to save the company by getting your enthusiastic customers involved in designing the extensions they want, and feeding them back into your new product development. From an agile point of view, what’s not to like? Just one thing. It appears from the description that this is reactive agility. Customer comes up with an idea, the company decides if it’s good, if so flows the part that applies into new-product development. Again, just one problem: how does the company get ahead of the customer?
Because, remember, new-product development at Lego is still not like agile software development. It’s more like “hybrid” open-source plus internal development. My studies suggest that because the areas it can improve are limited and it’s not proactively agile, this approach typically returns about one-half or less of the benefits of the average agile development organization.
So how would Lego become more agile? By making its new-product development more agile. The remark by one exec is a dead giveaway: we “hold a dialog with the customer.” It’s clear that it’s a tilted dialog: the customer tells Lego a lot, Lego doesn’t counter every customer suggestion with a suggestion for the customer. Instead, he or she has to wait for the next product release, and hope. What you’d like is to unleash the creativity of the development team in making the new products “orthogonal” – simple and powerful to use – and speed up responsiveness to all customers, not just the enthusiasts, by more frequent incremental product releases.
Final Thought
Rather than go through the last article, which doesn’t add anything in terms of agile theory, I thought I’d make an overall comment. It seems to me that many of these researchers were perhaps not thinking in as agile a way as they might. For example, many of these insights are based on rigid surveys and existing data. Certainly that’s understandable – obviously, agile theory is not widely applied anywhere except in agile software development.
Still, it does make me understand better why I like the customer survey/interview techniques I stumbled on 15 years ago. They let the customer provide an insight into his or her wants or needs, by telling about the product I’m surveying about as a story of a solution to his or her needs. They are open-ended, allowing the customer to take the questionnaire in a direction not contemplated initially, and allowing me to adjust agilely to that change in direction. They specifically ask for important information outside the bounds of the questionnaire. In effect, my research is a bit more agile because I am acting more in an agile manner.
All those who are researching business value-add, might this approach be of help in understanding your work through the lens of business agility? Or do you have agile suggestions of your own? I don’t know the answer. I’m just trying to be agile.
No comments:
Post a Comment