lidenskap.blog

As understanding deepens, the strategist seeks the crux - the one challenge that both is critical and appears to be solvable.

A diagnosis of the situation. Figure out what's going on here and understand the challenge you face. The challenge can be to deal with change and competition, it can be triggered by a large opportunity or it can be internal like outdated routines, bureaucracy, or lack of collaboration.

A guiding policy, i.e. what will you do and what will you not do with the challenge. It is "guiding" because it channels actions in certain directions without defining exactly what shall be done.

A set of coherent actions that will carry out the guiding policy. This part is so easy to leave out because people like to think of strategy as a high level conceptual thing. Strategy is about action. There must be enough clarity about action to bring concepts down to earth.

When deciding what you will do with the challenge, find your source of advantage. Do you know something that others don't? Do you have a skill that others don't have? Do you have a reputation, brand or existing market system that others cannot replicate? Do you have scale, technology, experience or other resources that others don't have?

A bad strategy is fluff and fails to face the challenge, it lacks the diagnosis. If you don't frame the challenge it is difficult to assess the quality of the strategy.

Another mistake is to treat goals as a strategy. Many bad strategies are just statements of desire rather than plans for overcoming obstacles. Good strategic objectives are the outcome of a strategy, not its input.

Bad strategy is the active avoidance of the hard work of crafting a good strategy. One common reason for choosing avoidance is the pain or difficulty of choice.

Good strategy requires leaders who are willing to and able to say no to a wide variety of actions and interests.

Strategy is not mysterious. It is about solving the most important problem you are facing. You need to be focused on something doable and be consistent about it.

History's role is not to help us predict the future, but to prepare us for it. 

Jim Highsmith's career over the last six decades is a good start.

In the Wild West Era (1966-1979), software engineering was in its infancy and the knowledge of how to "do" software development negligible. This era was wild.

The Structured Methods and Monumental Methodologies (1980-1989) era was an attempt to go from the undisciplined wild west to a more disciplined and formal approach, trying to be recognized as an engineering discipline. 

IT projects were generally viewed as out of control, and business managers assumed building software was the same as building a warehouse. Focus on tasks rather than people and team dynamics.

A formation and expanded use of waterfall, control-oriented, and process-heavy methodologies emerged assuming that documentation was sufficient to communicate between groups with no need for further explanation. Variation from the plan was seen as poor execution.

Despite of this, the approaches managed to deliver value. The success and failures of one era form the base for the next.

"IT projects take too long, costs too much, and don't meet our needs". Welcome to The Roots of Agile (1990 - 2000). In response to executives cries for help, software developers began experimenting with iterative Rapid Application Development (RAD and RADical) methodologies, especially for Internet applications.

• "It was just a small project", 
• "It was a new project", 
• "They didn't have to follow our standards".

Management wanted agility, but with traditional performance measures. To change behavior and culture, you must change measures of success.

In the current Digital Transformation period (2011 - present), the problem isn't scaling Agile, but enterprise-wide scaling of agility and innovation. 

We need to move from predicting and planning for the future, to building a platform that enables us to adapt to whatever happens.

Preparing for the future challenges us to scale an agility mindset, not simply agile methods and methodologies.

Many have witnessed failed transformations, but few have witnessed true successes. 

Moving to the product operating model is a transformation. At the end, it's about consistently creating technology-powered solutions that your customers love, yet work for your business. It's about delivering real results. But what do you change exactly?

You change how you build. Products are managed as an ongoing effort - improving every week until it's decided to sunset it. You do frequent, small releases so you know that it's working and how it's being used.

You change how you solve problems. Empowered product teams are given problems to solve and outcomes to achieve instead of a list of prioritized features, projects and perceived solutions decided by various stakeholders.

You change how you decide which problems to solve. A strong product company has a compelling product vision and insight-based product strategy identifying the most critical problems that need to be solved to deliver on the business objectives. Your strategy cannot be to serve as many business stakeholders as possible.

Pushing the decisions and responsibilities for finding the best solution to the problem down to the relevant product team, and then holding that team accountable for the results also drives the need for new product core competencies (that normally takes years to learn). 

Unless you are willing to establish these new competencies, your transformation hopes will likely end here.

For the product team together with the product manager to discover and deliver effective solutions, it is absolutely critical that they have direct access to:

1. Users and customers,
2. Product data, 
3. Business stakeholders and
4. Engineers (the tech lead as a minimum).

Fight any attempt to place a well-meaning person or cumbersome process between the product manager and these constituencies.

An honest and accurate assessment of the organization’s current situation is essential to any plan to successfully transform. Be realistic, talk to all levels and look for evidence. 

Start with pilot teams volunteering to be on the leading edge of these changes. Develop the skills of the product teams (bottom up) and the skills of the product leaders (top down). Ensure your CEO supports and is a champion of the change.

Transformation is a long game, and for that reasons it helps to have some quick wins. It could simply be a team that has never visited users starts doing do and shares it experiences and insights. 

Constantly beat the drum, evangelize and show everyone the progress being made.

"Transformed - Moving to the product operating model" by Marty Cagan.

In the Age of Digital, don't use methods from two technological revolutions ago on unique, knowledge-based work that is emergent and full of unknown-unknowns.

Start with the "Why"

Start with why if the why is not already clearly understood, and communicate it three more times than you think you need. You cannot over-communicate the why.

What happens if the status quo is maintained? What’s the “so what”? Why do people need to go through the discomfort of change and lack of mastery? What appeals to the selfish gene? 

There should be a compelling why unique to your context and organization, which is the call to action. “We want to be more agile”, “We want to be more lean”, “We want to be more product-oriented” are insufficient calls to action.

A useful exercise is doing a “five whys”. Break into pairs with the starting question of “Why change?” and take turns asking why five times with each answer forming the basis of the next question.

Desired outcomes

Next, articulate and agree on your desired outcomes. Agile, DevOps, Lean and Design Thinking are the means to an end, they are not the end. They are bodies of knowledge, wisdom, principles, and practices to be applied in context to achieve desired outcomes.

Outcomes should be measured and visualized. Focus on the trend over time and relative ranking on improvement rather than on absolutes, as everyone has a different starting point. The goal is to improve over time.

Business outcomes are hypotheses and they are nested with a lineage up to longer-term, organization-wide strategic outcome hypotheses. Outcomes are not passed down, unchanged, in a traditional order-giver, order-taker manner. Instead they align. They are written and “owned” by the people at each level in the nested value streams.

Leaders go first

The leadership team is number one. If a leadership team is not willing to role model desired behaviors, why shall other teams do it?

People in senior roles have a disproportionate impact on behavioral norms. Trust and role modeling are essential.

Ways of Working Center of Enablement

In order to be successful, there is a need for people who are dedicated full time in a servant leader capacity to orchestrate the improvement of the system of work across an organization. 

For a large organization, the success patterns is to have federated Ways of Working Centers of Enablement, with one for each business unit or value stream and a central one providing the team-of-teams coordination.

The Center of Enablement deal with impediments to achieve the outcomes that bubble up, with a goal of solving them at the lowest possible level. They are not a department of improvement where improvement actions are lobbed over the fence.

There should be an impediment backlog, with the Center of Enablement orchestrating the right people in the organization to help alleviate the top-priority impediments where this is beyond the sphere of influence of a team.

This is leadership in ways of working, being coaches, guiding people on the journey, sharing learning internally and externally, communicating, creating community, rewarding and recognizing desired behavior and outcomes.

Achieve big through small. 

Achieve big through small instead of big through big. Minimize time to learning. 

Change is hardest at the beginning. There is no one size fits all. Context matters. Every environment is unique. Starting small makes it safe to learn, keeps change within risk appetite, and generates social proof unique to your context.

People have a limited velocity to unlearn and relearn. You cannot force pace of change. If you do, you will only get new labels on existing behavior. Start small and within the risk appetite. 

Amplify the experiments that work well, and quickly dampen the ones that don’t. Experiments are then amplified or dampened.

Let the natural champions go first

Allow people to satisfy their psychological need for agency and control, the need to feel in control of one’s own destiny. Allow the Innovators, the natural champions, to identify themselves. They are motivated by the buzz of being first, and have probably been working this way formally or informally for some time. 

Invite participation and get behind the champions. Give the champions the coaching and the support they need in order to deliver business outcomes. As the benefits are seen, recognized and communicate via every mechanism available, the early adopters will want to join in. They can see that it’s safe to put a toe in the water. Gradually invite them in too, within the pace of unlearning and relearning and within risk appetite.

Invite everyone from top to bottom

Invite everyone from top to bottom (a vertical slice), don't leave the pressurized middle behind. They have to deliver, come what may, and are now being asked to change ways of working as well as continuing to deliver. It’s a difficult role and is often missed during a change that is sponsored from the top table and implemented at grass roots. 

Everyone learns together, and no one is left behind. It's not easy, as the most enthusiastic group of people is at the team level. 

Communicate, communicate and communicate

Communicate three more times than you think you need. Use every communication channel at your disposal and add some more.

Use the channels to reinforce the why, the values and principles, the outcomes, to recognize desired behavior and to do story-telling. Have senior leaders recognize the great work of teams in improving outcomes and have teams share their stories.

Stick at it

It requires commitment and resilience. It takes years for sustainable, lasting culture change, for genuine agility. 

For a large organization with a tailwind, it’s three to five years, longer with headwind. There are no shortcuts. 

In organizations with traditional ways of working, change is staccato. In evolutionary biology terms it is "Punctuated Equilibrium" rather than "Punctuated Gradualism". There are long periods of stasis, then a burst of disruptive change. There is lack of ongoing continuous improvement.

Become the best at being better.