Can adaptability and efficiency better protect you when the competition shows up and they are even less friendly than the Vikings?
Of the companies which were in the Fortune 500 in 2000 … 52% have either gone bankrupt, been acquired or ceased to exist. A sobering statistic. For the majority of them a disruption came along to which they could not adjust. When they needed to be adaptable … to make a change … they couldn’t do it. They certainly couldn’t do it … quickly enough. The life cycles of companies have been tightening relentlessly. Consider that in 1958 S&P 500 companies had an average tenure of 61 years. By 2011 it was 18 years. There are some rich topics to harvest from that data. The one I want to focus on today is your organizational response to a disrupting change.
There is some interesting work out there which talks about the available options. For example you can attempt to frustrate the disruptors legally. This is what has been happening recently with Uber. But it really has the feel of attempting to legislate against the incoming tide, a-la Nero. (Uber might themselves be washed away in the near future if they do not fundamentally change. Connecting a customer to a freelancer driver is disruptive today. But consider that car manufacturers are tooling up to produce vehicles without a steering wheel and without pedals. Will Uber become the disruptee when these go mainstream?).
Resisting change might buy a little more time but there comes an inevitable tipping point when reality has to be accommodated. Maybe … just maybe … people will be willing to buy organic pet shampoo on-line. Personal note (and painful one) … I have never held much enthusiasm for twitter. “Just how much can you do with so few characters?” I would say to myself. Well the answer would appear to be – win an election and run a country – or so it would seem.
Time and timing becomes critical when it comes to the business of disruption. The quote from Tom DeMarco that “a day lost at the beginning of a project is as valuable as a day lost at the end” is more relevant than ever (allowing that we would like to be a little less project based).
So what to do? When a disruption materializes it is not your exception logic in the cart checkout web service which is in question. It’s your company’s strategy. It’s the viability of your products. It’s the basic context in which you are operating. It is the 5-year plan which needs to be torn up (and not rewritten). Put simply … its the big stuff which is about to change. And your organization needs to change quickly.
If change is not built into your corporate culture you probably have a problem. You didn’t before (heck you’ve been wildly profitable for 20 years) … but you do now.
In order to position your organization for future disruption you should be focusing on two key capabilities:
1) As an organization you need to be adaptive and
2) Your company needs to be efficient.
Is change built into your corporate mindset and culture? Can you change when you want to? Does your organization tend to assume variability or does it prefer to plan away uncertainty (or at least construct the illusion that it has done so)? If you are in the habit of building highly deterministic plans and then carefully executing on those plans … there is a high probability that when a disruptor comes along your org will resist even acknowledging it at first. After all, nobody needs to look silly by blowing up a three year plan just because a distraction has surfaced … right? This position can’t last forever – but it will burn up crucial time during which your organization could have formulated a response. By contrast an adaptive organization is constantly asking itself “what do we know now that we didn’t know a month ago? Based on the data we have today … what should we do next?”. Instead of a highly deterministic plan such companies favor a plan which is continuously evolving. That some discovery will occur is anticipated. That is not to say that all strategic considerations go out the window. The key difference is the duration of the corporate learning cycle. Do key learnings, insights and responses happen on a once per year basis (even less frequent than that?). Or do you collectively seek to learn every week, every month, every quarter? When you learn something do you use the information to inform your planning? As you steer the large ship which is your organization which of the “a little rudder early rather than a lot of rudder late” … is more likely of your organization?
There are several takes you could make on the topic of efficiency. It is NOT about competing until we are all working for $8 an hour. A common way in which agilists look at efficiency is to emphasize the work NOT done. By striving to find the most valuable items to work on we avoid a lot of wasted capacity. This is of course, important. But another aspect to efficiency is this: how long does it take your company to make a decision? Snails are after all, adaptive. One way to frustrate adaptability is to mandate that all designs and decisions be approved by senior management. Have them get together once a quarter. Get a review board going. When you centralize decision making in this way you will place a bottleneck and the flow of work will be severely interrupted. So a key question here is whether your decision making model is centralized or decentralized? Some decisions are worthy of senior and central oversight. Does your organization know how to determine which ones? Have you articulated the circumstances under which a decision can be made locally? Some types of decisions you would prefer be made by those closer to the problem. It will be a better-informed decision. It will cause more junior staff members to exercise leadership skills. It will be made more quickly.
- What is our average lead time and cycle time in making decisions?
- What is the ‘definition of done’?
- How soon can the decision be released to consumers?
1. Clear recommendations provided
What would a prototypical Kanban board look like? What should be the agenda for Day 1 of a planning meeting for a large expensive program? What types of considerations should be driving non-functional requirements? How does my program ensure that we neither under-invest nor over-invest in a reusable framework? These types of questions are going to surface for you. SAFe takes positions on such things and provides some clear guidance
2. Common language, shared model
SAFe articulates a model for engagement and collaboration. It provides some new terms with specific meanings and definitions. As a consequence a language of engagement is also established which can cut across the numerous disciplines present in any large enterprise. This provides a basis for meaningful discussion as you forge consensus in the pursuit or organizational change.
3. Guiding Principles – rules which sustain over time
The nature of the changes suggested by an adoption of SAFe are broad in scope. Your OCM journey is likely to be unique to your context. But some principles are universal in nature and are likely to sustain over time. The underlying principles which drive SAFe have been remarkably stable over time and they are codified and taught as part of the overall SAFe framework.
4. Guidance on practices
Yes principles add value … but what should we actually DO? SAFe is firmly anchored in concrete and pragmatic advice on how to approach the complex task of building software systems. The magic happens when the disparate viewpoints and different types of experience are able to work together in concert. SAFe emphasizes alignment and provides guidance on how to achieve that.