Lean Enterprise at Spark The Change

Spark The Change

Spark The Change

I had the pleasure of attending one of the most interesting, diverse and engaging conferences in recent memory last week in London. Spark The Change was designed to bring together leaders from across the business to explore how they can work together to create lasting and total change.

I was honoured to be invited to speak about Lean Enterprise.

Our world and future business opportunities are continuously emerging through advances in design, technology, and wider social and economic change. Organizations must continually revisit the question, “What business are we in, and how can we organize to maximise our performance”.

The session discussed how to embrace a culture of continuous experimentation and learning, to transform our business to an adaptable, resilient Lean Enterprise.

 

Lean Enterprise at ThoughtWorks Live Australia

I had the pleasure of traveling around Australia with my colleague Gary O’Brien to share our experiences on the secrets of transforming enterprises, helping them to develop new products and services faster and efficiently.

We aimed to address the most troublesome and counterintuitive aspects for adoption: process, budgeting and compliance, design and culture – providing examples from organisations that have learnt how to do it the hard way.

Our talk was excellently captured via stechnote by Gary Barber – thanks!

Lean Enterprise Sketchnote

Lean Enterprise Sketchnote via Gary Barber @tuna

The full presentation and slides are here.

Want to avoid disruption? Then keep exploring

Article for The Economist Insights

Want to avoid disruption? Then keep exploring

Want to avoid disruption? Then keep exploring

Businesses have always come and gone, but these days it seems that companies can fall from market dominance to bankruptcy in the blink of an eye. Kodak, Blockbuster and HMV are just a few recent victims of the rapid market disruption that defines the current era.

Where did these once iconic companies go wrong? To my mind, they forgot to keep challenging their assumptions about what business they were actually in.

Businesses have two options when they plan for the road ahead: they can put all their eggs into one basket, and risk losing everything if that basket has a hole in the bottom, or they can make a number of small bets, accepting that some will fail while others succeed.

Taking the latter approach, and making many small bets on innovation, transforms the boardroom into a roulette table. Unlike a punter in a casino, however, businesses cannot afford to stop making bets.

Business models are transient and prone to disruption by changes in markets and the external competitive environment, advances in design and technology, and wider social and economic change. Organisations that misjudge their purpose, or cannot sense and then adapt to these changes, will perish.

The sad truth is that too many established organisations focus most of their time and resources on executing and optimising their existing business models in order to maximise profits. They forget to experiment and explore new ideas for customer needs of tomorrow.

What business are we in?

Believe it or not, photography giant Kodak, which filed for bankruptcy in 2012, actually invented the digital camera. Steve Sasson, the engineer who created the potentially game-changing technology in 1975, was met with puzzled bosses who could not comprehend the future opportunity, or why customers would ever want to view photographs on a monitor.

Kodak’s business was optimised for developing photographs, not capturing memories, so the idea was not explored. Had Kodak built the capability to bring new products to market and evolve its business model, it could have led the digital revolution from the front. Instead, the reverse happened: after years of foot dragging, Kodak perished at the hands of competitors who had grasped the digital opportunity.

Contrast Kodak with Amazon, a company that was once dismissed as mere book seller. In 2008, it experimented with what is now Amazon Web Services as a way to operate IT infrastructure more effectively. It soon realised that the approach it was developing could be used to provide external customers with computing services. Six years later, Amazon is the company to beat in the cloud computing market.

Amazon’s willingness to flip a business model on its head can create runaway success stories, while stubbornly clinging to an established business model often signals an organisation’s demise.

As Amazon CEO Jeff Bezos notes, “What’s dangerous is not to evolve.”

These are no happy accidents

Winning organisations are continually experimenting, testing theories to learn what works and what does not. The reality is that fewer than one in ten of these new ideas or products will work, but the ones which do pass the litmus test could have a massive impact on the business’ future fortunes.

When exploring new ideas, here’s a five-point plan that businesses should follow:

  1. Support the culture of experimentation. The only failure is the failure to learn. Leaders are responsible for creating and defining this culture.
  2. Don’t just set up a big project, make lots of small bets. Ramp up successes and limit losses.
  3. Give your initiatives enough money to do something, but not enough to do nothing. Focus on frequent demonstrable value and validated learning before further investment.
  4. Create co-located, cross-functional teams to explore the problem space with end to end responsibility for the product.
  5. Continuously evaluate the performance of your initiatives and adjust the direction based on frequent customer feedback.

These ideas form the basis of Eric Ries’ Lean Startup philosophy. But they also provide a way to evaluate and start up large programs of work within enterprises. We discuss an evidence-based approach to enterprise portfolio and program management based on these principles in our forthcoming book Lean Enterprise by Jez Humble, Joanne Molesky and myself, Barry O’Reilly.

How to implement Hypothesis-Driven Development

Remember back to the time when we were in high school science class. Our teachers had a framework for helping us learn – an experimental approach based on the best available evidence at hand. We were asked to make observations about the world around us, then attempt to form an explanation or hypothesis to explain what we had observed. We then tested this hypothesis by predicting an outcome based on our theory that would be achieved in a controlled experiment – if the outcome was achieved, we had proven our hypothesis to be correct.

We could then apply this learning to inform and test other hypotheses by constructing more sophisticated experiments, and tuning, evolving or abandoning any hypothesis as we made further observations from the results we achieved.

Experimentation is the foundation of the scientific method, which is a systematic means of exploring the world around us. Although some experiments take place in laboratories, it is possible to perform an experiment anywhere, at any time, even in software development.

Practicing Hypothesis-Driven Development[1] is thinking about the development of new ideas, products and services – even organizational change – as a series of experiments to determine whether an expected outcome will be achieved. The process is iterated upon until a desirable outcome is obtained or the idea is determined to be not viable.

We need to change our mindset to view our proposed solution to a problem statement as a hypothesis, especially in new product or service development – the market we are targeting, how a business model will work, how code will execute and even how the customer will use it.

We do not do projects anymore, only experiments. Customer discovery and Lean Startup strategies are designed to test assumptions about customers. Quality Assurance is testing system behavior against defined specifications. The experimental principle also applies in Test-Driven Development – we write the test first, then use the test to validate that our code is correct, and succeed if the code passes the test. Ultimately, product or service development is a process to test a hypothesis about system behaviour in the environment or market it is developed for.

The key outcome of an experimental approach is measurable evidence and learning. Learning is the information we have gained from conducting the experiment. Did what we expect to occur actually happen? If not, what did and how does that inform what we should do next?

In order to learn we need use the scientific method for investigating phenomena, acquiring new knowledge, and correcting and integrating previous knowledge back into our thinking.

As the software development industry continues to mature, we now have an opportunity to leverage improved capabilities such as Continuous Design and Delivery to maximize our potential to learn quickly what works and what does not. By taking an experimental approach to information discovery, we can more rapidly test our solutions against the problems we have identified in the products or services we are attempting to build. With the goal to optimize our effectiveness of solving the right problems, over simply becoming a feature factory by continually building solutions.

The steps of the scientific method are to:

  • Make observations

  • Formulate a hypothesis

  • Design an experiment to test the hypothesis

  • State the indicators to evaluate if the experiment has succeeded

  • Conduct the experiment

  • Evaluate the results of the experiment

  • Accept or reject the hypothesis

  • If necessary, make and test a new hypothesis

Using an experimentation approach to software development

We need to challenge the concept of having fixed requirements for a product or service. Requirements are valuable when teams execute a well known or understood phase of an initiative, and can leverage well understood practices to achieve the outcome. However, when you are in an exploratory, complex and uncertain phase you need hypotheses.

Handing teams a set of business requirements reinforces an order-taking approach and mindset that is flawed. Business does the thinking and ‘knows’ what is right. The purpose of the development team is to implement what they are told. But when operating in an area of uncertainty and complexity, all the members of the development team should be encouraged to think and share insights on the problem and potential solutions. A team simply taking orders from a business owner is not utilizing the full potential, experience and competency that a cross-functional multi-disciplined team offers.

Framing Hypotheses

The traditional user story framework is focused on capturing requirements for what we want to build and for whom, to enable the user to receive a specific benefit from the system.

As A…. <role>

I Want… <goal/desire>

So That… <receive benefit>

Behaviour Driven Development (BDD) and Feature Injection aims to improve the original framework by supporting communication and collaboration between developers, tester and non-technical participants in a software project.

In Order To… <receive benefit>

As A… <role>

I Want… <goal/desire>

When viewing work as an experiment, the traditional story framework is insufficient. As in our high school science experiment, we need to define the steps we will take to achieve the desired outcome. We then need to state the specific indicators (or signals) we expect to observe that provide evidence that our hypothesis is valid. These need to be stated before conducting the test to reduce the biased of interpretations of results.

If we observe signals that indicate our hypothesis is correct, we can be more confident that we are on the right path and can alter the user story framework to reflect this.

Therefore, a user story structure to support Hypothesis-Driven Development would be;

We believe <this capability>

What functionality we will develop to test our hypothesis? By defining a ‘test’ capability of the product or service that we are attempting to build, we identify the functionality and hypothesis we want to test.

Will result in <this outcome>

What is the expected outcome of our experiment? What is the specific result we expect to achieve by building the ‘test’ capability?

We will know we have succeeded when <we see a measurable signal>

What signals will indicate that the capability we have built is effective? What key metrics (qualitative or quantitative) we will measure to provide evidence that our experiment has succeeded and give us enough confidence to move to the next stage.

The threshold you use for statistically significance will depend on your understanding of the business and context you are operating within. Not every company has the user sample size of Amazon or Google to run statistically significant experiments in a short period of time. Limits and controls need to be defined by your organization to determine acceptable evidence thresholds that will allow the team to advance to the next step.

For example if you are building a rocket ship you may want your experiments to have a high threshold for statistical significance. If you are deciding between two different flows intended to help increase user sign up you may be happy to tolerate a lower significance threshold.

The final step is to clearly and visibly state any assumptions made about our hypothesis, to create a feedback loop for the team to provide further input, debate and understanding of the circumstance under which we are performing the test. Are they valid and make sense from a technical and business perspective?

Hypotheses when aligned to your MVP can provide a testing mechanism for your product or service vision. They can test the most uncertain areas of your product or service, in order to gain information and improve confidence.

Examples of Hypothesis-Driven Development user stories are;

Business Story

We Believe That increasing the size of hotel images on the booking page

Will Result In improved customer engagement and conversion

We Will Know We Have Succeeded When we see a 5% increase in customers who review hotel images who then proceed to book in 48 hours.

It is imperative to have effective monitoring and evaluation tools in place when using an experimental approach to software development in order to measure the impact of our efforts and provide a feedback loop to the team. Otherwise we are essentially blind to the outcomes of our efforts.

In agile software development we define working software as the primary measure of progress. By combining Continuous Delivery and Hypothesis-Driven Development we can now define working software and validated learning as the primary measures of progress.

Ideally we should not say we are done until we have measured the value of what is being delivered – in other words, gathered data to validate our hypothesis.

Examples of how to gather data is performing A/B Testing to test a hypothesis and measure to change in customer behaviour. Alternative testings options can be customer surveys, paper prototypes, user and/or guerilla testing.

One example of a company we have worked with that uses Hypothesis-Driven Development is lastminute.com. The team formulated a hypothesis that customers are only willing to pay a max price for a hotel based on the time of day they book. Tom Klein, CEO and President of Sabre Holdings shared the story of how they improved conversion by 400% within a week.

Conclusion

Combining practices such as Hypothesis-Driven Development and Continuous Delivery accelerates experimentation and amplifies validated learning. This gives us the opportunity to accelerate the rate at which we innovate while relentlessly reducing cost, leaving our competitors in the dust. Ideally we can achieve the ideal of one piece flow: atomic changes that enable us to identify causal relationships between the changes we make to our products and services, and their impact on key metrics.

As Kent Beck said, “Test-Driven Development is a great excuse to think about the problem before you think about the solution”. Hypothesis-Driven Development is a great opportunity to test what you think the problem is, before you work on the solution.

More thoughts on Business Model Generation, Lean Startup and Continuous Delivery will be included in our upcoming book, Lean Enterprise.

References

[1] Hypothesis-Driven Development By Jeffrey L. Taylor

How Learning Really Drives The Innovation Cycle

tw-live-13-europe-logoThe software delivery problem has evolved, now its about leveraging the insights that our customers are giving us to build truly innovative products and services that challenge both their and our own assumptions about what we should be doing next.

In this presentation with John Crosby, Digital Product & Technology Leader for Travelocity International and lastminute.com, at ThoughtWorks Live we share the story of how we implemented Lean practices and principles within lastminute.com to create a new mobile web platform that doubled customer conversion compare of the existing site.

Key stories and concepts in the presentation are:

  • how to articulate clear product and technical vision to engage everyone across the organisation
  • how to communicate clear team goals through product scorecards based on real business outcomes, not efficiency or velocity
  • how to define the problem you want to solve, then create hypotheses to test the solution in order to validate or invalidate assumptions you are making about your product/market fit
  • how to reduced cycle time from concept to customer through Continuous Design & Delivery
  • how to get out of the building and talk to your customers to understand their problems using innovative approaches to user testing and sourcing customer feedback

Further talks from ThoughtWorks Live Europe

Mental Models for Agile Adoption

ALE

Following being invited back to the Agile Lean Europe (ALE) unconference in Bucharest this year, I thought it would be a nice idea to share the presentation Jo Cranford and I gave at the inaugural unconference in Berlin in 2011 on ‘Mental Models for Agile Adoption’.

What are Mental Models?

Our mental models help shape our behaviour and define our approach to solving problems, carrying out tasks and form the structure of logical reasoning. One view suggests mental models can be constructed from perception, imagination, or the comprehension of discourse.

What are mental ingredients to support Agile adoption within learning organisations?

How do we amplify what enhances adoption and break down barriers that inhibit it?

We attempted to explore ideas how mental models are at the very heart of success of organisational change and individual transformation.

Key concepts;

  • The difference of ‘Doing Agile versus being agile!
  • How Agile and Lean concepts are often interrupted as counter-intuitive
  • How we make mental leaps of abstraction
  • How are governing variables drive our action strategies
  • The ‘Theory of Action’ from Schon and Argyris
  • Double versus Single Loop Learning
  • Tools and techniques to improve outcomes
    • Left Hand and Right Hand Column
    • Personal Reflection

Living Below The Line

Over the last few days I’ve been finding out what it means to Live Below the Line, by taking on a weeks challenge to survive on £1 a day. Unfortunately what for me is a challenge is the reality of life for 1.2 billion people on our planet.

LivingBelowTheLine

What is it?

Live Below the Line is an initiative of the Global Poverty Project, an education and campaigning organisation whose mission is to increase the number and effectiveness of people taking action against extreme poverty.

Throughout April and May 2013, Live Below the Line is running simultaneously in the UK, Canada, New Zealand, Australia and the USA, with more than 20,000 people spending 5 days living below the poverty line. Across three continents people will join the movement to experience the challenge of living on £1 or less a day, while raising money and awareness to tackle extreme poverty.

Why £1?

Live Below the Line challenges individuals and communities to see how much change you can make out of £1. By living off just £1 per day for FOOD you get to bring to life the direct experiences of the 1.2 billion people currently living in extreme poverty.

Think about that figure – 1.2 BILLION – that’s over 20 times the population of the UK or over 15% of the planet – living in extreme poverty on less than £1 every day.

People Living On Less Than £1 A Day Globally

Percent of People Living On Less Than £1 A Day Globally

What did I do?

I was lucky enough to be involved in a set of remote workshops with the team from Global Poverty Project, ThoughtWorks India and Europe to help shape and understand the next steps for the platform that had originally been developed by ThoughtWorks Australia.

We got together in a room in South London with projectors, post-its and a raft of digital tools including – GotoMeetings, Google docs, cardmapping.com and ideaboardz.com to figure out how to open up the platform to new markets across the globe.

Remote Inception

Remote Inception

I’m delighted to say that the project was a great success with Global Poverty Project and ThoughtWorks working exceptionally well together to deliver a product that will allow Live Below The Line  to improve on the £500,000 raised last year from the initiative.

How can you help?

5 Day Food

After being involved in the program, I and colleagues at ThoughtWorks Europe decided that we would take part in the challenge to help raise more funds to support the future development of the platform – enabling Global Poverty Project to continue to grow and build upon the success of the initiative thus far.

I bought my food for the week and have been living on a staple diet of muesli, instant noodles, cup-a-soups and crackers for the last few days to raise funds and awareness of global poverty. I can honestly say that it has been an eye-opening challenge to experience the hardship of constantly making choices of what I could get and eat over the last few days. This highlights even more to me to the difficulty some people face when thinking about their next meal, while others more fortunate are able to take  food for granted.

My shopping list included;

  • 500g Muesli - £0.59
  • 4 Noodles – £0.72
  • 1 Tin of Sweetcorn- £0.32
  • 1 Packet of Cream Crackers – £0.26
  • 2 Tins of Soup - £0.48
  • 1 Tin of Mushy Peas – £0.15
  • 1 Tin of Tuna – £1.63
  • 1 Potato – £0.30
  • 1 Packet of BelVita – £0.21

Total – £4.66

I would really appreciate your support by donating to my fundraising page to help drive change and progress in one of the biggest issues we face on our planet.

Our goal is make the change – not only for ourselves but for everyone out there – and to advocate passionately for social and economic justice.

Donate At: https://www.livebelowtheline.com/me/boreilly

Follow Us: #twbelowtheline | @LBLuk | #thoughtworks #belowtheline

//

I don’t do Agile, I AM Agile!

Too often in agile software development we tend to use methodologies and all their components simply because the rule book says so. Why not select the tool based on the context of the goal your trying to complete.

Anything that you use that does not lead towards a direct value add to the final product delivered is simply an overhead and waste.

This presentation covers discovering what is the minimum amount of practices that are required to achieve the goal of delivering a product we desire – safely, quickly and successfully. Thus allowing us to start getting feedback and improving it.

Tagged , , , ,

Tradition vs. Lean and Agile PMO and Organisations

We are in one of the most interesting and disruptive eras of business change the world has known. The landscape and competitive environment is evolving at rates we have not seen before, and it’s only going to accelerate. The average life expectancy  for an organisation is plummeting from 67 years in the 1920s to 15 years today, according to Professor Richard Foster from Yale University. At the current churn rate, 75% of the S&P 500 will be replaced by 2027.

Below I have included a deck contrasting the differences between traditional and Lean/Agile PMOs and organisations, outlining the value a Lean/Agile approach can bring. I have been able to extended the deck with the help of David Joyce and Ian Carroll in order to start a discussion on how the future can look for organisations as they attempt to scale lean and agile practices and principles across the entire organisation.

Even though traditional models of how projects, portfolios and organisations are governed represent thinking that originated in the 1890s with Taylor (fixation on efficiency and utilisation) and Gantt (of Gantt chart fame) they seem remarkably impervious to change. Our challenge for organisations today is that they need to change to keep pace with our ever evolving business environment, otherwise we can never achieve true business agility.

I plan to post deeper insights into each area over the coming weeks, however for now I will paint the boarder picture of where the majority of organisations are at today, and how they need to start changing and learning to move forward and be competitive in this era of disruptive change.

As W. Edwards Deming said, “Learning is not compulsory… neither is survival”.

Key concepts;

  • How traditional PMOs and organisations are setup
  • Legacy mindset that are alive and still driving the majority of portfolio/organisation behaviours
  • Comparisons of traditional and lean/agile mindsets
  • Principles of lean and agile portfolio/organisation management
    • Organisational structure
    • Annual vs Incremental funding (Beyond Budgeting)
    • Limiting Work in Progress i.e. its only matters how many projects you finish, not start.
    • Managing and visualising capability
    • Coping with portfolio complexity through experimentation and validated learning
    • Removing the concept of projects and focusing on continuous delivery of value
  • Benefits of lean and agile portfolio/organisation management

ProductTank at Google Campus

I was delighted to be invited to present at October’s meetup of ProductTank at Google Campus to share my experiences on what drives individuals, teams and collaboration in successful product development organisations.

ProductTank London is the original meetup for Product Managers throughout the city, and with over 1,100 members and 150+ attending every event. I had the pleasure of sharing the stage with Dharmesh Raithatha, Senior Product Manager at Mind Candy and Will McInnes, Managing Director at NixonMcInnes.

Dharmesh shared really interesting insights into how creating a shared vision, understanding and culture in an organisation is key to ensuring the success of the business, especially when you are a company like Mind Candy that has experienced rapid growth in a short period of time.

Will also put across a number of compelling arguments related to how so many organisations still remain closed, siloed, slow to change, and deeply hierarchical. He described how work places need to progress to become supportive, open, conducive to creativity, motivating, and fun while focusing on values that support a higher social consciousness and benefit over shameless and hungry profiteering to support a few individuals pockets. He has captured his thoughts in his recently published book called Culture Shock.

My presentation was focused on motivation, along with ideas on teams and organisation culture and values. I also included a couple of exercises and tools I use to visualise and surface these behaviours when working with groups.

Motivation

One of my favourite books on the subject of motivation recently has been Dan Pink’s Drive, where he covers concepts behind extrinsic and intrinsic motivation. Extrinsic motivation refers to motivation that comes from factors outside an individual, typically financial incentives. Intrinsic motivation refers to motivation that is driven by an interest or enjoyment in the task itself, and exists within the individual rather than relying on any external pressure. Intrinsic motivation is based on taking pleasure in an activity rather than working towards an external reward.

The key factors for those that are intrinsically motivated are:

Purpose – a clear vision and shared understanding of what needs to be done
Autonomy – space and support to achieving results using techniques and approaches under their own control
Mastery – interested in mastering a topic, rather than just learning to achieve ‘good enough’

Tribal Leadership

Birds flock, fish school, people “tribe”.

Tribal Leadership is a concept captured by Dave Logan and his team, which is based on research conducted over a 10-year period with 24,000 people across 24 organisations from around the world. His argument is what makes the tribe more effective than others is its culture. Tribes generally consist of between 20-150 people and have 5 stages of cultural significance.

Stage one - people are socially alienated, and the theme of their words is that life has given them a bad deal, so it’s ok to do whatever it takes to survive.
Stage two - people do the minimum to get by, show almost no initiative or passion, and engage in passive-aggressive behaviour.
Stage three - people engage in anything that’s going on, with energy and commitment, but when you listen closely, they talk mostly about themselves and focus on appearing smarter and better than others. They think they’re focused on team concerns, but their actions show their interest is personal. People tend to form two-person relationships, so if they manage of group of ten, they have ten relationships.
Stage four- teams are the norm, focused around shared values and a common purpose. Information moves freely throughout the group. People’s relationships are built on shared values. They tend to ask, “what’s the next right thing to do?” Their language focuses on “we,” not “me” – and are ready for genuine partnerships.
Stage five- the theme of communication is limitless potential, bounded only by imagination and group commitment. People in this culture can find a way to work with almost anyone, provided their commitment to values is at the same intensity as their own. (Unlike Stage Four, the focus isn’t on “our values” but on resonant values.) There is almost no fear, stress, or workplace conflict. People talk as though the world is watching them, which may well be the case, as their results are making history.

True leaders can talk to people at all levels, however people in each level can only move up one level. It is the responsibility of leaders to nudge tribes to the next level. Great leaders introduce tribes to one another – bring people together from tribes unknown to themselves and one another in order to create amazing things.

Presentation Slides

Follow

Get every new post delivered to your Inbox.

Join 1,115 other followers