lidenskap.blog

It is in our nature, and we love it.

What images are evoked when you hear the word "learning"? Sitting passively in classrooms or meetings and listening? 

Taking in information is not the same as learning.

When we have learned we are able to do something we never were able to do. Learning is about expanding our ability to produce the results we truly want. We never "arrive". It's a process.

The best learners get comfortable being uncomfortable. The way you like to learn is what makes you comfortable, but isn't necessarily how you learn best. Practicing something before you master it is uncomfortable, so you often avoid it. Accelerating learning requires you to use your knowledge as you acquire it.

The most powerful learning comes from direct experiences. As babies we learn eating and walking by trial and error. We didn't learn to speak our mother tongue in a textbook, starting with grammar and, checked by bi-quarterly exams, systematically fitting words to the acquired rules.

There is a dilemma here. Yes, we learn best from experience but we never directly experience the consequences of many of our most important business decisions. How do you and your organization learn then?

Teams, not individuals, are the fundamental learning unit in modern organizations. When teams are learning, the individual members are growing more rapidly than could have occurred otherwise.

Is it crazy to say that the primary objective of a team is to learn? Isn't the primary goal to deliver value? But how do you know you deliver optimal value without learning? The faster you learn, and the quicker you can integrate those insights into your delivery, the more value is created.

One of the best measures of any group's culture is its learning velocity - how quickly it improves its performance of a new skill.

You probably have performance goals. What about learning goals? Getting A in French vs. Learn to speak French. Which one leads to mastery?

But hey, we don't learn from experience, we learn from reflecting on experience someone said. But we are busy, so we don't have time to just sit around and talk, right? We barely have time to think. 

Reflection that isn't connected to action is what makes people think they don't have time for this. We need a culture and the discipline to integrate reflection and action.

Teaching others is a surprisingly powerful method of learning. My favorite. The protégé effect. 

If we know that others are going to learn from us, we feel a sense of responsibility to provide the right information, and fill our own gaps. It is simple. Next time you have learned something, explain it to someone else.

Learning starts with me. I can never expect the people around me to be more open and willing to learn and improve than I am. 

To learn I must be humble enough to realize I have something to learn.

They planet ...

We fear uncertainty

We fear uncertainty. We don't start walking until we find an approach that's guaranteed to work. How can you know what you are doing when no one has done it before? 

The secret is to start walking before you see a clear path. If you stick to the familiar, you won't find the unexpected.

First-principles

Reason from first-principles. Doubt everything you can possibly doubt until you are left with unquestionable truths. That's where you start. With each commitment, each presumption, each budget item, ask yourself, what if this were not true? Why am I doing it this way? Can I get rid of this this or replace it with something better?

Compare oranges and apples

Approach life not with the assumption that we know (or should know) the answers, but with the desire to learn, experiment and absorb. Compare oranges and apples, look for connections between seemingly unrelated things.

Tackle the hardest part first

If your goal is one percent improvement, you can work within the status quo. But if your goal is to improve tenfold, the status quo has to go. You must then start with a blank slate and question all assumptions. Picture the perfect and ask what it takes to build it. Move backwards. Tackle the hardest part first.

Problem reframing

In schools we are taught to answer problems, not to reframe them. Problems may have multiple causes, don't stick with the first that pops to mind. Don't fell in love with your favorite solution and define the problem as the absence of it.

Opinions are sticky, hypotheses not

We undervalue evidence that contradicts our beliefs and overvalue evidence that confirms them. Opinions are sticky. Instead, generate several working hypotheses. Opinions are defended, but working hypotheses are tested. Your goal should be to find what's right, not to be right.

Failure is success if we learn from it

Celebrate lessons from failure, not failure itself. Good decisions can lead to bad outcomes. In uncertainty, outcomes are not completely within your control. Focus on the variables you can control – the inputs – instead of the outputs. Even if the project fails, you can take the input that worked and use them elsewhere.

Surviving your own success

When we succeed, we believe everything went according to the plan. When we succeed we stop pushing boundaries. Surviving your own success can be more difficult than surviving your own failure. Instead of risking something new, we maintain the same "proven" formula that led to our success.

Remain in Day 1

The rocket-science mindset requires remaining in Day 1. We must keep devising thought experiments, taking moonshots, proving ourselves wrong, dancing with uncertainty, reframing problems, testing as we fly, and return to first principles.

That's the mindset of a rocket scientist!

"Think Like a Rocket Scientst" by Ozan Varol

When we are going to do something we have done before, we know what we don't know. 

We know where and why delays are likely to occur and we usually know what to do if something goes wrong. We can plan the steps ahead. In this world, clarity and process optimization is good.

Wicked or complex problems on the other hand are different. There is no one right answer. There are no agreement on what the problem really is. 

You face many stakeholders with conflicting objectives. No solutions are right or wrong. You can make the outcome better or worse, but you are never done. Forcing clarity in this world will inevitably hinder innovation.

Getting married is not complex, but having a happy marriage is. There is a manual for getting married. But there is no "best practice" for a happy marriage. It's the sum of many small parts which makes it difficult to make a detailed plan. You cannot copy someone else's work and expect the same results because no two complex problems are alike.

All the analysis, plans and methodologies used to build a car are useless if your problem is car traffic. A car slowing down will cause ripple effects in the traffic difficult to predict. The issue with traffic is not the cars, the buses, the bicycles, or the pedestrians. It is in the relationship between them.

Building the Titanic out of LEGO bricks is not complex. You can simply follow the instructions. The whole equals the sum of the parts.

What about development of digital products that you haven't built before, either at all or in your context?

Market conditions change. Technology is changing. People's behavior change. We don't quite know how we are going to do it. We don't know what people want. You don't know what you don't know until you do something and get feedback. That's when the actual development starts.

Leading in complexity calls for something other than plans and best practices. Sense what's happening. Get some data. Take small actions based on the data and see what happens. Learn from it. Do more of what works, and less of what don't. Find the small changes that have a large positive effect.

Easier said then done. We are humans and we fear uncertainty. When we face uncertainty, we often manufacture excuses for not getting started. We don't start walking until we find an approach that's guaranteed to work.

It's hard to say to your stakeholders that you don't know exactly if it will be a success, when it will be finished and what it will cost.

What we can do is to deliver something early and often and let people try it and give feedback. 

We can also share what we believe (our hypothesis), what we will do to verify it, how we will measure it, what we observed, what we learned from it and what we will do next based on that.

In complexity, how do you measure success? You get what you measure you know ...

• How did we achieve our results? 
• How ambitious were the targets? 
• Was there a headwind or tailwind? 
• Which risks were taken? 
• How sustainable are the results? 

These evaluation questions require more effort than comparing two numbers.

Hitting a target does not necessarily mean that this was the best performance possible because it assumes that the "right" target was set.

Beyond Budgeting is a journey where the direction is clearer than the destination, if there is one.

Changing what we do helps little unless we also change how we think. That is the hardest part.

"This is Beyond Budgeting" by Bjarte Bogsnes

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

Today we talk about product management, agile, waterfall, projects, iterative and measures of success. I enjoy putting this in a historical context. Because those who fail to learn from history are condemned to repeat it. History can help us prepare for the future. Jim Highsmith's career over the last six decades is a good start.

Wild West (1966-1979)

Software engineering was in its infancy and the knowledge of how to software development negligible. Software project success was measured by completion and cost. Businesses operated on the premise that the world was predictable and if plans failed to materialize, the problem was execution, not planning. Change was the "unusual state".

Structured Methods and Monumental Methodologies (1980 - 1989)

This was an era where management theory was firmly stuck in the command-control model. IT projects were generally viewed as out of control. Managers assumed building software was similar to building a warehouse. They often knew little about the value of IT systems, even though productivity increased, and focused therefore on "out of control" cost and schedule overruns. 

Structured methods should bring discipline and control to software development.

But the attempt to go from the undisciplined Wild West to a more disciplined, formal approach overshot and focused on the wrong things - processes and documents. 

Formality was mistaken for discipline. Formal processes, phase reviews and documentation added a level of bureaucracy that overshadowed the benefits of structured techniques. It worked for tangible products and construction-type projects though.

The belief was that documentation was enough to convey all the information required by individuals in the next phase of work.

A paper by Winston Royce in 1970 is often credited with introducing the Waterfall model of software development (a term he never used in the paper). However, Royce did not advocate for the  model in its strict, linear form. He highlighted its limitations and risks, particularly the challenge of accommodating changes once the project is underway. To address these shortcomings he argued for feedback loops, overlapping development phases, and the need for more flexibility and adaptability.

But the waterfall lifecycle was greatly influenced by the surrounding ethos, manager's thinking and the serial "hardware" mindset of the times. Departments outside of IT also adapted their work to conform to the serial mindset. For example, accounting started to classify operating (OpEx) versus capital (CapEx) costs.

Too much structure reduced problem solving and innovation; too little created chaos and ineffectiveness.

The Roots of Agile (1990 - 2000)

Executives now cried for help. "It takes too long, costs too much, and doesn't meet our needs".

In response, software developers began experimenting with RAD (rapid application development) methodologies. They assembled a small team, delivered working software every week, and conducted "customer focus groups" every Friday to get feedback. This was about value, quality, speed, leadership, and collaboration.

The 1990s were the decade where software outsourcing to solve technical debt and the high-cost mess began to flourish. The assumption was that less expensive programming could be accomplished with minimal communication. But much of the outsourcing was based on the false premises of predictability and prescriptive practices.

Worse, it stripped internal IT teams of the expertise they would need in the coming Internet upheaval.

The methodology of software development continued to be deterministic and formal in the 1990s, but slivers of RAD and iterative development began to creep in, especially for rapidly expanding Internet applications.

The 1990s were the decade of process for IT. We sought not just perfection in the way we built software, but total predictability. It wasn't enough just to do things right, we also had to say in advance exactly what we intended to do, and then do exactly that.

The Agile Era (2001 - 2010)

Demand exploded. Acquiring and retaining technical talent proved difficult. Many companies didn't have the money or the talent pool to respond to the pressures of the 2000s. IT organizations faced pressure from the high costs. Companies had to innovate and expand their technical and product design capabilities.

Technical debt, which had been growing rapidly, was still almost invisible to business executives. IT struggled to convince business leaders to approve the investments required to reduce technical debt, thereby enabling continuous value delivery.

On February 11-13, 2001, 17 software developers met at the Snowbird ski resort in Utah to talk, ski, relax, and try to find common ground leading to the Agile manifesto.

Many software engineers were concerned about the nascent agile movement. They viewed agile development as a retreat to ad hoc practices of the past. But in reality, teams were highly disciplined, but worked somewhat informally. The emphasis shifted from documentation towards collaboration, replacing traditional formality.

From 2001 - 2004, individual teams received dispensation to try this "agile stuff". Teams focused on iterations, stories, daily stand-ups, backlogs and co-locating teams - but the core technical practices were often bypassed.

Agile projects' success was often downplayed by others: "it was just a small project", "it was a new project", "they didn't have to follow our standards". General comment from Agilists was "We don't need any project management". But the management of tasks rather than people was what they were complaining about.

From 2005 to 2010, success versus failure with organizational implementation of agile development rested with courageous executives who understood agility at their core. Courageous executives thrived on adventure, the corporate kind, and had the ability to sort through a myriad of opportunities, engage others with their enthusiasm, and demonstrate results through action.

Another success factor was that Agilists had enough background in change models to muddle through team-level implementations. At an enterprise level, it made a difference when they received help from organizational change experts.

Do we implement from top to bottom, or from bottom to top? Do we start with a few teams and user their experience to seed others, or do we "sheep dip" everyone? What was the strategy for moving agility up (the organizational hierarchy) and sideways? How do we instill both being agile and doing agile? Whose change model and approach do we use? Agilists were simply not experts in change management.

Other success factors were demonstrated business benefits, practices that appealed to engineers and a manifesto that stated a clear purpose and principles for the movement.

Digital Transformation (2011 - present)

The problem now wasn't scaling agile, it was scaling agility and innovation at enterprise levels.

Remember the lessons from agile projects: To change behavior and culture, you must change measures of success. Many managers wanted agility, but with traditional performance measures (planned scope, schedule and costs).

Over the last six decades, measures of software development success have evolved from completion to customer value. Nothing drives change like the way organizations measure success, but few things are harder to change than those measures.

The Digital Transformation period explored what becoming a digital enterprise meant. Enterprise executives developed digital strategies but found their transition from strategy to operating models lacking.

Enterprises today should be seeking to become digital transforming rather than to achieve digital transformation. Transformation indicates completion of a stage, whereas transforming suggests a constant state of becoming.

More than six decades of change have required organizations to constantly adapt by addressing the following areas:

• Measures of success - this can drive or restrict change.
• Being digital demands a better business and technology partnership.
• An operating model linking strategy to action.
• Creating a quickly malleable organizational model.
• Management suited for the digital era.

Preparing for the future

Over the 60 years, have anyone notice the rate of change in the world, in technology, and in business slow down? Change has spiraled constantly upward, not only linearly, but bordering on exponentially.

One conclusion from history is that agility, not agile, should be the goal. Agility is a mindset; agile is a type of methodology. Failure to make this differentiation has left organizations with prescriptive methodologies, while leaders who embrace agility have the best chance of thriving in the future.

Change takes more than a one-day workshop. No one changes deeply held mental models easily. Even when organizations and managers intend to start the journey with the right mindset, many don't realize the magnitude and complexity of this transformation.

The root cause of success is people and their interactions, and the root cause of failure is also people and their interactions.