Can being SAFe help your organization survive?

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.

perfectStormWave

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.

screen-shot-2017-01-11-at-3-23-20-pm

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.


Adaptability
target-practice-530Is 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?


Efficiency
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 images-4common 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.
If you do not put any scaffolding in place for your organization it will all gravitate towards centralized. One way I suggest you can reinforce it even further – punish incorrect decisions. Here is a question to consider: Given the choice between making no decision versus making a wrong decision which do you think your organization encourages? That can be a difficult question to ruminate on. Too often – no decision is allowed to prevail. But what exactly is learned while the organization is busy making no decision (other than how to stifle a yawn?).

Decisions as products
Without too much of a stretch you can view a corporate decision as a product. When you make a decision you really do “make” something. You create and then deliver clarity where none went before it. Once you start to view your organization’s decisions as deliverables in their own right you can begin to ask some Screen Shot 2017-01-12 at 10.42.29 AMinteresting questions which you might make of other types of work:
  • 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?
These are knowable and potentially trackable. Be careful with metrics as you can easily drown in them if you are not careful. But somebody has a right to ask the question ‘are we getting better?’. And they have a right to know on what basis you are answering in the affirmative. A decision is an entity – a thing – which is created at a price. What does it cost the organization to make it and when do you get back what you invested? What does it cost the organization if it is not made (or if its deferred)?
Decisions are work and they therefore require some of your organizational capacity. They are also work which deserves to be made visible as much as any user story or task. Ever been in the situation where an irate staff member would have liked to have been involved in a decision but is now dealing with a fait-accompli? Have you ever been accused of being overly authoritarian or secretive? All of that is far less likely if you are maintaining a Kanban board of which decisions are up for consideration, which are in flight and which have been completed.
Open question: what do you think your efficiency as an organization would be if you were to calculate when a decision is being worked on vs when it sits idle in a queue? If you were to conduct a value-stream mapping exercise on your organizational decision making … I would forecast that you would be aghast at how many times an item is simply waiting in queues.
The potential for SAFe to help
So what of SAFe and the title of the blog? Can SAFe help my org survive disruption? Change (process change) is hard. You need a framework which governs your engagement and provides model within which you can strive for greater adaptability and efficiency. Scrum/XP (on which SAFe rests) will bring enormous benefits to teams of 5-9 but it falls short of what is needed by a typical large enterprise.  In my opinion, SAFe is an excellent model of engagement which can create the scaffold for the promise of agile to be realized at scale. We owe an enormous debt of gratitude to the creators of Scrum/XP but they weren’t targeting enterprises and large companies when they created the agile manifesto. They were targeting an overly regimented and unrealistic set of practices which were not serving the discipline of software development very well (my words not theirs).
SAFe seeks to scale agile in the enterprise. To the extent that you buy into the goals of adaptability and efficiency in decision making then SAFe can help you take a massive step in a positive direction. The core values, principles and practices which comprise SAFe are field-tested and are being constantly improved upon. Adaptability is built into the very process by which SAFe evolves. You may find ways to improve on the default framework. Scaled Agile freely acknowledges and welcomes this possibility. In particular they would welcome you sharing your findings so that they can learn from you in the field.
When I attended Leading SAFe class I came away a better leader and coach for it. But above all else I believe I was a better agilist as a consequence. The class shone a flashlight into areas which needed to be addressed to succeed at scale. It helped me better understand why some adoptions had struggled in the past … and what I would do differently going forward.

 If you do choose to explore SAFe more deeply you will find:

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.
That barely begins to scratch the surface of SAFe. A common piece of feedback I hear as an instructor/coach is just how much material is included in SAFe training.
At the start of this post I shared some stats related to organizations in the Fortune 500 and S&P 500. It will be fascinating reading in 10 or 20 years to learn how those organizations who chose to adopt SAFe have fared. I can’t help but feel that those organizations who have positioned themselves to better respond to disruptions are better protecting their futures. I have tried to make a case that focusing on adaptability and efficiency would be two great places to start.

ABPLogoNarrow
AgileBigPicture provides SAFe certification training and is a Silver Partner in the Scaled Agile Partnership program. If you feel you might benefit from SAFe training or embedding a SAFe coach into your organization contact us at admin@agilebigpcture.com.
Our next course is available in Boston on January 30th.

References
1. When digital disruption strikes: How can incumbents respond?
https://www.capgemini-consulting.com/resource-file-access/resource/pdf/digital_disruption_1.pdf
2. Credit to Jim Highsmith for his book Enterprise Adaptabilty which I devoured
3. Credit to ScaledAgileFramework from which I draw heavily in all that I do.