Why we carry watermelons?

I was working with a client recently that had decided to start a program of work involving 15 independent project teams, all working together to deliver a few key business objectives. 15 project teams comprised of roughly 140 people, all co-ordinating and collaborating together from different departments, locations and functions across a global organization with a few external vendors thrown in to add a little spice.

A challenging mission at best, I was keen to understand how the Program Management Office would measure progress towards the identified outcomes, while ensuring that individual teams shared information across the program of work.

I carried a watermelon?

I carried a watermelon?

“We’ve a program dashboard that each team populates with project status, progress, risks and issues each week”. I looked at the dashboard. “Everything is on track, and has been since we started a few weeks ago. We’re confident we’ll deliver everything within the program time line and constraints”, said the Program Lead. All the initiatives were green. “I think you’re carrying watermelons”, was my response.

What is a watermelon?

Green on the outside but with orange or red cores, watermelons are a nice analogy for healthy looking project reports served to PMOs on a weekly basis. In an environment of mistrust, fear or bureaucracy watermelon serving is rife. Teams tend to suppress or hide information that may highlight that everything isn’t executing as defined in ‘the plan’ – especially when everyone else in the program is serving up fresh green goodness too!

No one wants to be the focus of management never mind the PMO, they paint the happy, healthy and wholesome picture, avoid discovery and convince themselves everything will work out before the next checkpoint. The Eye of Sauron moves onto the next green blip and the team hopes to pull back the difference by the next time the dark lords glare comes around.

HealthCare.gov was a $93.7 million investment that turn into a $292 million failure for the US Government. People and teams within the program were aware that the initiative was not in a good state, yet they continued to report that everything was running to schedule, on track and green — even though inside the projects people knew the reporting was a fallacy and the status was red.

They lived their days hoping that everything would turn around, that they would reach the dates, and deliver the system. No one wanted to be the bearer of bad news. No team wanted to highlight that they had an issue, they were waiting for someone else to blink – why, so everyone could blame someone else for the failure that was about to happen?

Breaking open the watermelon culture

Visibility, transparency and the appropriate level of decision making lead to better choices. But yet, there are prerequisites that must be in place to get there.

To calibrate openness and safety teams monitor the response of leadership to difficult situations and emergent circumstances. Teams adapt the quality and detail of information they share in relation to the actions, not the words, in response to the information.

Encourage teams to cut the watermelon open and have a conversation about what you find inside. Then by working together to eat up what you find it encourages others to do the same.

Team will always encounter problems on any delivery initiative. Our mission is to create willingness to take accountability for the challenges faced and find the best solutions together.

Decisions on how teams work towards solving the challenges should be made by the teams doing the work, not someone in management located on the other side of the world.

However, these teams are then responsible for the outcomes of their decisions thus empowered to be accountable to do the right thing. The job of leadership is to provide support, space and remove blockers in their way.

In my experience programs based on cultures of fear tend to follow the pattern below

Transparent, trusting and teamwork based programs tend to be this pattern

We need to change the way our people think and work together towards a common goal. To do this, we need to address a few aspects;

  • Clarity of Purpose – clear direction from leadership and the team on the outcome (or target condition) to achieve
  • Alignment – collaboration and agreement on the tactics to achieve the target condition
  • Engagement – regular feedback loops with everyone involved in achieving the target condition. Then adjust and adapt based on the information we are learning from performing the work to address the issue at hand

When working with teams, I favour a “Go to Green” strategy by reviewing all aspects of the current situation including data presented by other team leaders in the program. By creating visual artifacts (not paper reports) where teams can meet, share and collaborate on current state and circumstances we can make better decisions that will improve outcomes for the entire initiative. It also serves to foster transparency and trust between all parties as they work together to solve problems and win.

Plan, assign and execute those decisions in an agreed time frame, then set a frequency to review outcomes, share successes or revise activities based on what we’ve learnt from doing the work.

Conclusion

If you have a culture based on fear, you will never have true information flowing through your organizations network. People will share the right information, not the correct information.

The role of leadership is encourage transparency and recognize that their actions in response to negative news is what will create an environment of safety. When people feel secure to share real information on the situation, knowing that leadership will work together with them to identify strategies directed to solutions not blame, the system improves for everyone.

Encourage teams to work together to solve problems, thus building relationships and trust with one another to achieve successful outcomes for all by eating up those watermelons together!

melon-shark

References

The first time I heard the term ‘Watermelon Reporting’ was from Marc Loffler when he got on the stage at ALE 2011 with a meat cleaver and a bag of watermelons. I’ve kept it with me since then.

All watermelons from http://www.whataboutwatermelon.com

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
Follow

Get every new post delivered to your Inbox.

Join 1,121 other followers