Author Archives: theitriskmanager

About theitriskmanager

A IT programme manager specialising in delivering trading and risk management systems in Investment Banks. I achieve this by focusing on risk rather than cost. A focus on costs can lead to increased costs.

Why Business Cases are Toxic

Business Cases where product owners have to justify investments by presenting the benefits in financial (monetary) terms are toxic. They create two significant problems that prevent a customer focused agile approach to product development:

  1. They remove the need for executive decision makers to learn about business value metrics.
  2. They create a big batch development mentality rather a desire to create a continuous flow of value and learning about the customer.

Many executives embark on an agile transformation with the intention of becoming more responsive to customers needs. Unfortunately executives want to change their product organisations but retain practices that stifle agile transformations. The worst of these is the business case expressed in financial (monetary) terms.

The Business Case

An Agile product owners identifies an opportunity to invest in the product. Traditional organisations insist that the product owner justify the investment in financial terms. The product owner then has to explain the investment idea in monetary terms.The conversation goes something like this:

  • Product Owner: I want to build a purple widget.
  • Executive: What is the business case?
  • Product Owner: This spreadsheet model shows that if we build the widget we will make £1,800,000.
  • Executive: How did you come up with this model?
  • Product Owner: We hired some consultants who used the data from one of our other products.
  • Executive: The return looks good so go for it.
  • Product Owner: Great so if we deliver a purple widget, we get to claim the £1,800,000 benefit? After all, there is no way to check that we have actually delivered the £1,800,000.
  • Executive: That makes sense.

To make this approach work, the product owner describes the solution in terms of functionality and then translates that into a financial amount. The executives then agree that building the solution will deliver that amount of financial benefit. Given the complexity of most organisations, it is impossible to directly attribute any financial outcome to an individual investment. As a result, the product owner gets to claim success simply by delivering the solution.

It is even worse when the translation to a financial amount is limited to those translations supported by existing data. This is equivalent to searching for you car keys under a street light when you dropped them in a field.


A further consequence is that the product owner knows what they need to do for success and seeks to minimise the effort to build it. Rather than build the solution incrementally, learning about the customers and their needs as they build it, the product owner builds the whole thing in a big bang waterfall or water-Scrum-fall development. There is no point building it incrementally as the Product Owner already knows what they have to do in order to be successful.

The Metrics based Approach

In the metrics based approach that modern, customer centric organisations use, the Product Owner identifies an opportunity to invest and expresses it in terms of a metric.

The product owner and the executives should engage in a conversation to agree the exchange rate between the metric and a monetary amount. For example, the product owner has identified an opportunity to improve the conversion rate of the customer acquisition funnel. The conversation might go something like this:

  • Product Owner: Currently our conversion rate is 35%. I think we can do some things to get that closer to 50%. What is that worth?
  • Executive: I’m not sure, lets work it through.
  • Product Owner: We currently get 100,000 potential customers a month into the funnel and 35,000 sign up as customers, or a conversion rate of 35%.
  • Executive: Our existing one million of customers generate £10,000,000 in revenue which means £10 per customer.
  • Product Owner: Therefore a 15% increase of conversion means 180,000 extra customers a year.
  • Executive: Or £1.8 million, which is a good deal based on the proposed investment.
  • Product Owner: And a 10% increase of conversion is worth £120,000.
  • Executive: So every 1% increase is worth £12,000, or lets keep it simple and say £10,000 per 1%.
  • Product Owner: I can work with that. Do you want to know what we intend to build? I have the specs for the purple widget here.
  • Executive: Only out of interest and to ensure that the investment is coherent with the outcome. It is your responsibility to ensure the conversion rate moves, after all, you are the one with all the detailed knowledge.
  • Product Owner: So if you agree with what I suggest and I build it, I’m a success?
  • Executive: You are only a success if you increase the conversion rate regardless of whether I agree the purple widget sounds like a good idea. The responsibility stays with you.
  • Product Owner: In that case I build what I want, how I want, as long as I improve the metric you agree to, in this case the conversion rate?
  • Executive: That’s the deal. That what autonomy means.
  • Product Owner: What about the coherence thing you mentioned?
  • Executive: I’m responsible for a wider set of metrics. The only challenge I will make to your investment is if what you intend to do is not coherent with the metric you intend to move. For example adding Adverts to the funnel to improve conversion.
  • Product Owner: Got it, because Adverts increase revenue but will possibly harm conversion. So Adverts should be aligned with a revenue metric directly rather than the conversion metric.
  • Executive: You got it.

In this example the Product Owner retains responsibility for moving the conversion metric. The Product Owner needs to build something that moves the metric and cannot claim victory simply by implementing the purple widget. The success of the Product Owner can be easily determined from whether they moved the conversion metric. The Product Owner and Executive have agreed an exchange rate between the conversion metric and the “financial return” so that the executive can judge whether the investment is sound or not. The exchange rate can change based on the sentiment of the executive. For example if churn is high and customers are leaving, they may prefer an investment to reduce churn rather than conversion which simply on-boards customers who leave.

The First Investment

The first investment that a competent product owner makes is to establish the baseline values for their metrics. This allows them to determine whether their investments are working or not. If you do not know your starting point, there is no way to know whether the things you are doing are improving the product or otherwise. Without your baseline metrics, you have no way of learning whether the things you have built are a success or not.

A culture of Metrics versus Features

When your goal is to move the metrics instead of building features, you have to learn about your customers and their needs. If you do not study your customer, the features you build are a big gamble, nothing more than a wild bet.

Building features is hard, however it is CYNEFIN.complicated problem which can be solved by experts or analysis. Moving metrics involves building features which is CYNEFIN.complicated, and it is also hard because understanding what your customers need is a CYNEFIN.complex problem to solve. Poor quality Product Owners will ask their executives to turn their CYNEFIN.complex problem (Move the metric) into a CYNEFIN.complicated problem (Build a feature). It is the responsibility of the Executive to prevent the product owner from doing this.

A simple trick for Executives is to get their product owners to move the metric to claim success, and give no credit for simply building the feature. In short, ditch the business case and embrace metrics.

Fairness in processes and systems

Just back from the annual holiday with the family. One of the worst things about the work we do is that there is no switch to “Turn it off”. Whilst on holiday we had the cliched problem with sun loungers and towels and it bought focus to the problems we face at work in Product Management.


The situation was typical. So typical that it was a cliche in management terms as well as sun loungers. Simply put, there were not enough sun loungers, towels were deployed, the rules were not clear and people got upset. Management had policies in place that made matters worse. Even worse, staff were not empowered to resolve problems for customers. It was a classic case for deployment of the theory of constraints.

Step 1: Find the constraint. That was easy. There were more people who wanted a sun lounger than there were sun loungers to go around.

Step 2: Prioritise the constraint. This is where management policy failed the “fairness rule” and customers got upset. This lead to conflict between customers, and conflict between customers and staff.

No need for step 3 and step 4.

So the problem for the hotel management was that there were not enough sun loungers. We have all been in that kind of situation. The problem for the customer was that the system was not fair and even monkeys get upset when treated unfairly. ( <– Watch this 2 minute video, its a treat. )

Screen Shot 2017-07-29 at 09.42.34

So why wasn’t the process fair?

  1. The customers knew that only two thirds of the sun loungers were actually being made available. One third were being held back for unspecified reasons. (Two reasons suggested were that “The manager thought it made the pool look untidy.” and “If too many were put out, the decking around the pool might collapse.” – Neither of which are good from the customer’s perspective. Either the manager’s sense of esthetics was more important than his customer’s comfort, or the pool area was dangerous.)
  2. Some sun loungers were deployed in the darkened indoor spa pool where there were already warmed stone beds to use instead. As a result the sun loungers were not used but they could not be moved to the pool side (unless you applied enough pressure on the pool staff).
  3. The spa reserved some sun-beds for people from outside the hotel who had signed up for a day spa experience. This meant that people staying in the hotel would be without a sun lounger all day because a day spa guest might want to sit by the pool for an hour.
  4. The rules for reserving sun loungers with towels were not clear or explicit. On day one I discovered that a French family had reserved a number of sun loungers with towels. On day two, I reserved a number of sun loungers before breakfast only to discover they had been removed by a German couple when we came to use them. When I asked one of the pool staff for assistance he randomly removed some towels from sun loungers for us and when the Dutch owners of the towels turned up, we faced the same awkward conflict situation with the them as the German couple had faced with us.
  5. The hotel staff did not take ownership. When we complained to the pool staff, they pointed us to reception. When we complained to reception, they pointed to the pool staff. It was only when we demanded that the General Manager come to the pool that the spa management rudely and begrudgingly found some extra sun loungers. (Note – We do not blame the spa management, anyone who has managed a constraint before knows that you need to lose empathy or otherwise you cannot function). It should be noted that the staff were wonderful but had no space to move within the rules specified by a general manager who clearly did not understand empowerment.
  6. An extension of the lack of ownership was that pool staff were only available to put out extra sun loungers at 11:00am. (The hotel wisely took the light weight sun loungers in overnight in case they blew about in strong wind.) This meant that there were even fewer sun loungers during the most popular time of 9:00am to 11:00am. Check out this wonderful picture of a person with a medical walking stick having to sit on the floor next to another person using the step as a cushion because the manager thinks the pool looks better with fewer sun loungers. Other customers choosto lie on a towel on the floor. The Emergent Behaviour of customers can be quite vexing for managers who would rather they shayed in their room out of sight.Screen Shot 2017-07-29 at 13.13.52
  7. Reception staff were helpful and raised the issue with management. Their solution, my family would get special treatment and have a number of sun loungers reserved for us… more unfairness.

So what can management do? We can apply the same kind of thinking for most constrained resources:

  1. Transparency – Make sure customers have transparency on what resources are available. No hidden resources. Hidden resources are unfair and destroy trust in the integrity of the system which leads to people gaming the system. Screen Shot 2017-07-29 at 09.42.49 After all, Unfairness leads to unhappy Monkeys!
  2. Deploy all resources – Get all your sun loungers out at 8:00 am rather than force people to wait until 11:00 am and create an even more severe and artificial constraint. In other words, its not fun being a constraint. (Step 3 applies here. People from other departments could be deployed to assist. Else step 4, more staff.)
  3. Understand customer need – Customers need sun-loungers in the sunshine by the pool, and not in darkened rooms. In other words, respond to customer needs rather than management needs. If management needs trump customer needs, make it a feature of your hotel and notify your customers at their time of booking. A simple “Basil Fawlty’s opinion matters, not yours!” on your web-site should suffice.basilFawlty
  4. Reserved Resources – Where resources need to be reserved, make it clear and make sure they are only reserved when needed. Attaching a tag to a sun lounger saying “This sun lounger is reserved for day guests, please vacate it if a day guest needs it”. Note – If the London Underground can do this, I’m sure an exclusive hotel can.LondonUndergroundSeat
  5. Transparent Policies – A notice warning guests that they cannot reserve sun loungers using towels.
  6. Police the Policy – Staff need to consistently enforce policies. It should not be left up to customers to confront other customers. After all, customers are meant to be on holiday and are not really expecting conflict with other customers and staff because the hotel is creating an artificial constraint and failing to implement proper policies to manage the artificial constraint they have created.

In summary, constraints can cause conflicts so don’t create them artificially, and make sure any policy for managing the constraints is transparent and fair. The similarities with constraints in product development are striking.

So now I’m off to read some books and find out if there is a way to switch off these mind viruses when I want to get away from it all.


Executives and Empathy

One of the major global IT companies has a saying

Its not personal, you were just road kill.

Screen Shot 2017-04-17 at 15.49.03

“Road kill” refers to the fact that your career destruction was not a personal act but simply a result of a shift in an executive’s strategic direction, or a whim. Although it feels personal to the hedgehog, there was nothing personal from the eighteen wheel truck driver’s perspective, and why should it. The phrase is normally used when the hedgehog is well known to the driver of the eighteen wheeler.

Lets take a systems thinking view of this phenomena.

Whence Road Kill?

Why “road kill”? “Road kill” refers to the “unintentional” destruction of someone’s career when an executive rolls out a top down strategy.

Whence Top Down?

Why a top down strategy rather than a bottom up strategy? “Top down” puts the executive in charge. They can be seen to be active in the initiative. At the end of the year, they point at the result of the initiative and claim them for themselves. “Top Down” is a Dragon Slayer strategy.

Have you ever noticed that a visit to the local Doctor (GP) normally results in either a prescription for pills, or a referral to a consultant (a specialist doctor)? That’s because doctors in the UK get a bachelors of medicine, bachelors of surgery which is one degree with two titles. In order to maintain their status in society and justify their high salary, the GP wants to be in control of your treatment. Doctors are finding life increasing stressful as the internet allows people to self diagnose or check their doctor’s diagnosis. If you receive a diagnosis of Diabetes you can expect Metformin or Insulin as a treatment. Alternatively, your doctor will prescribe a change of lifestyle, a change of diet and prescription of daily exercise and regular vigorous walks in the Welsh Mountains. Changing lifestyle is as much to do with changing your social network.

So why do some Doctors prefer to prescribe medicine? In the UK, only Doctors can prescribe medicine, patients cannot just rock up at a chemist and ask for whatever they would like. Doctors act as a gatekeeper to medicine. If a doctor convinces someone to change their lifestyle, it is the patient who gets the credit for their cure. In other words, some Doctors prescribe medicine rather than lifestyle because it puts them in control whereas lifestyle changes are in the control of the patient.

This is not meant to be medical advice. Always consult a doctor!

Similarly, only executives can implement top down strategies. People at the gemba (where the work is done, the coal face) cannot implement top down strategies. They have to get the support of executives to do so. Top down strategies empower the executive, giving them something to point to at review time.

Whence the need for Empowerment?

Executives are like sharks. They need to keep moving or they will drown. Its not their fault, its the lack of life support at such high altitudes. They need to keep demonstrating value otherwise they will be out in the next corporate reshuffle caused by the top down initiative of a more senior executive or the turmoil caused by a merger or acquisition*


The executive suite can be a very lonely place. As an executive, you have probably seen a number of your friends turned into road kill… often at your own hand. The safest thing to do is not have friends. You are constantly fighting turf wars with other executives, with minor skirmishes being fought at lower levels of the organisation requiring your close attention. You hire ambitious individuals to get the job done, and each one of them is looking to stab you in the back and take your job as they seek to reach the top of the pyramid. Friends become a liability as you climb the ladder, they may reveal a weakness or may be held hostage in some executive action. The executive suite can be a very lonely place.



There are no training courses for executives. There are no training courses to prepare people for a role in the executive suite. MBAs and their flawed case based approaches teach students what good looked like a decade ago but do not teach practical day to day skills for today. Harvard Business Review and its monthly serving of early majority ideas provided comfort for executives looking for ideas. The HBR Online blog is a machine gun rapidly firing out anxiety inducing ideas reminding executives of the things they are not doing. Add subscriptions to CourseRA, Economist, Wired, McKinsey and you are fully in overload, and in need of beautiful expert consultants to help with your anxiety. None of them talk about failure, about things that other executives tried but failed. Talking about failure would only make you feel less inadequate.

And none of them teach obvious practical skills that you need to perform well in the long run.

How many of them teach the following strategies:

  1. Coaching and skills to help others learn. To enable executives to distribute their strategies effectively rather than having to rely on consultants.
  2. Real Options so that executives can effectively risk manage their organisations, and learn to make decisions when faced with uncertainty.
  3. Cynefin so that executives can understand the appropriate approach for each problem.
  4. Exaptation so that executives can reuse existing people and assets instead of buying new products and services.
  5. Safe to Fail so that executives can ensure that initiatives are safe to fail, and they can teach their organisation to be safe to fail.
  6. Culture. How to see it and how to left shift it to where they want to be.
  7. How to build a learning network that extends beyond their organisation so that they can learn from other organisation’s failures.
  8. The values and principles of Lean, Flow and Agile so that they understand and further the state of the art.
  9. Facilitation skills so that they can show by example how their managers can step back and let others do the work in a focused and risk managed manner.
  10. Cost cutting.


Many executives are often blind to the realities of what is happening in their organisation. They rely on second, third and fourth hand accounts of the impacts of their initiatives. They receive their intel from power points that are beautiful with beautiful images and beautiful diagrams and beautiful prose that tell beautiful stories that are written by beautiful story writers who are beautiful consultants from beautiful firms.

When the executives “Go to the Gemba” to see the work, it is part of carefully prepared state visits that would make ambassadors and state department civil servants blush. It is joked that the queen thinks the world smells of paint because everywhere she goes, one hundred metres in front of her is a decorator painting the walls. Executives think the world smells of fresh powerpoint, immaculate Kanban boards and improv presentation skills.

When executives do make impromptu visits they are made aware that they are causing a disruption.

No one teaches executives how to read the raw data or create a culture where no one notices when they make an impromptu visit.


Most executives rely on consultancies for introducing change. Consultancies have access to skills that are not available in the organisation. In reality, organisations have better access to the skills.

Consultancies are great for people looking to get diverse experience, or build their brand. Most competent practitioners in a new skill are unlikely to work for a consultancy. Why would you work for a consultancy and give up 60%-70% of the fee? Furthermore, world class experts want to build their own brand rather than be subservient to the consultancy’s brand.

Assuming you are an executive who knows the community you want to hire from. You will struggle to bring them into the organisation. You will spend orders of magnitude more effort to bring in a world class expert over the effort of bringing in someone mediocre from a consultancy on the preferred supplier list. Most organisations are geared to make it easy for executives to get good support from consultancies rather than top class support from world leading experts.

Consultancies come with other added benefits. If you bring in someone from a top consultancy, they will have a hot line to the top of the organisation. Whilst you need to respect the hierarchy, anything that threatens the success of your consultant will go straight to their engagement partner who will tell the top guy what to do.

The Executive Team

Most executive teams are not an executive team. They are a bunch of individuals each with individual responsibility for their own initiatives. They succeed or fail according to the success of their initiatives. How often are the entire executive team held responsible for the success of an initiative? If they are, they becomes the responsibility of the CEO.

Most executives really are on their own.


Safety Net

Many executives have spend many, many, many years building a network within their organisation. They need the network in order to make them effective. Studies have shown that shown that high performers at one firm become significant less effective when they move to another firm. It would seem that executive effectiveness is much a function of an their network and relationships. Often an executive moves organisation, to discover they it was their network and relationships that made them successful, and their skills are not enough.

Al-Noor Ramji understood the value of the network. He successfully moved from Swiss Bank to Dresdner Klienwort Benson to QWest to BT, and each time a chunk of his team followed him.

I know a number of senior executives who devoted a significant chunk of their career to building an organisation. Executives who failed to get a similar role when they left the organisation and are now working in a much smaller role because their network has no value to them. Executive effectiveness does not tend to be transferable.

In most cases, an executive’s network in the organisation they leave has no value to their new employer. The exception is consultancies. A friend who worked for a consultancy once told me that they had reached the time in their career where they needed to work for their client, a government department, for a few years. They would hire a team of managers to report to them before rejoining their current employer as a partner. Then the network and all of the relationships would be valuable, especially their successor who they would chose and mentor. This is why consultancies are often perceived as the recruitment consultancies for senior executive positions.

Is it any wonder that executives are often risk averse?

Whence Empathy

I started writing this series of posts where “Executive and Agile Beliefs Diverge” because I hoped to show executive a better way of thinking. As I’ve written the pieces I’ve developed empathy for executives. They exist within a system that prevents them from succeeding at introducing change.

The following are all set up to make the executive’s life hard:

  • No friends to support them
  • No training
  • No transparency
  • Consultancies without world class experience
  • No team
  • No Safety Net

Would you want a job like that?

Most organisations have a group of experts in system thinking. Perhaps they should get them to map out the systems at the executive level of their organisation to identify the system level changes that need to be made.

Me, I now have a lot more empathy for executives trying to make change happen in organisational systems that provide them little in the way of support. Rather than seeing them as the controllers of the system, perhaps we should see them as the ultimate victims of the system who need our support.

Happy Easter!


*Mergers were very popular in the 1980s and 1990s as a means for investment bankers to make money out of over capacity in markets. Unfortunately mergers lead to lumpy revenue streams but require maintaining high cost M&A departments. Since the 2000s, investment banks prefer to make money out of over capacity in markets through the credit derivatives markets. The credit derivatives market provide constant revenue streams which benefit from the occasional bankruptcy.



Executives and Top-Down Transformations

An obvious place where Executives and Agile Beliefs diverge is when it comes to Agile Transformations. Executives tend to favour top down big bang implementations whereas Agile Practitioners prefer bottom up safe to fail experiments.

Screen Shot 2017-04-15 at 10.55.47.png

This is not really the executive’s fault as they are driven by the need for fast results. Executives generally have a tenure of five to ten years. This is a surprisingly short period of time to effect significant lasting change in any established, traditional organisation.

The difference between traditional methods and Agile is that traditional methods tell you how to write software. Agile methods do not. As Tony Grout says “Agile methods are the simplest practice that will tell you the problem you need to solve“. Whereas traditional methods force the team to mold around the practice, Agile molds practices around the team and the context that they operate in. In other words, one size DOES NOT fit all. It takes time for a team to develop a stable and effective method for their context. It is not simply a case of the teams learning a new method, its a case of the team using Agile practices to create their method.

The change is bigger than just the development teams


Its not just the teams. The program management structure that manages the risks of the cross team development needs to be developed using Agile techniques. Whether you adopt Flow, LESS, Nexus, SAFE or DAD, its not just a process. All of the people operating the system need to learn a new way of working, and even harder, a new way of behaving. People need to learn how to learn “work with” rather than “work for”.

At the portfolio level, the organisation needs to bring all the business heads together in order to agree on the organisation’s backlog. This allows engineering to start managing its skill liquidity using a tornado graph to support investment and divestment of capacity. The organisation can become a team of teams and focus on its customers and it external competition rather than focus all of its energy on internal rivalries.

Screen Shot 2017-04-15 at 14.17.04.png

And this brings an uncomfortable truth and realisation to the CEO and Chief People Officer. Getting a business executive to give up their goals in order to help a fellow executive achieve theirs for the greater good of the company means that the (executive) reward system needs to be upgraded. An upgrade to reward collaboration and reward focusing on the goals of the overall organisation rather than sub-optimal local goals. It will take the HR function a number of attempts before they find the right path to a new successful reward system.

The organisation will need to implement a risk management system that allows business leaders and IT leaders to collaborate on managing the risks associated with investments involving IT. Not just copying a blog post but training audit and assurance functions in how to tell the difference between a well run project and one that presents a serious risk to the organisation.

The simple matter of funding becomes a issue at some point, though later than most think. Although the finance department needs to build a new way of funding projects, a more urgent imperative is to find a better way assessing the value that investments in IT deliver.

As well as learning to collaborate as a team, the executives need to learn how to create safe to fail cultures that promote learning. Executives need to learn an entirely new set of skills and behaviours. They need to learn how to create a new culture and tools for changing culture such as story telling and walking to talk. They need to learn how to see culture, the culture they need and the culture they need to move away from.

But before anything can start they need to build trust and respect with their fellow executives. Not something that happens over night.

And they need to do this fast, during their short tenure of five to ten years. No wonder they prefer big up front design, top-down transformations run by consultants who can be blamed for failure.

Starting an Agile Transformation Fast the obvious way

Doing it fast is easy. You select a method…. LESS, NEXUS, SAFE or DAD and simply roll it out. You hand out copies of the relevant book. You hire clever consultants and coaches, and you hire trainers to roll out standard training.

That “works” if you assume that an Agile transformation is “obvious” in Cynefin terms.

You will start fast and fail even faster, though perhaps only after you have spent a lot of money on consultants and coaches and training.

The upside for this strategy is that your bosses will perceive that you are a “get it done” individual who is making a difference. You will have a big up front design for your transformation. A big plan from a big name consultancy to get to success.

In the words of Helmuth von Moltke the Elder

“No plan of operations extends with certainty beyond the first encounter with the enemy’s main strength” (or “no plan survives contact with the enemy”) and “Strategy is a system of expedients”.

Starting an Agile Transformation Fast the complicated way

Instead you may consider that an Agile transformation is “complicated” in Cynefin terms and seek “experts” or get a big name consultancy to undertake an extensive analysis.

  • If you are unlucky, you will encounter consultants who will show you powerpoint slides with lots and lots of detail of successful transformations at similar organisations, a brightly painted roadmap, and a standard process that involves time boxed analysis or capability assessments. They will have an army of graduates and cheap developers micro-managed by “get it done” leaders to help you transform.
  • If you are lucky, you will hire one of the small handful of people in the world who have real experience of creating genuine Agile transformational change… And they will tell you that an Agile transformation sits on the boundary of “complex” and “chaos” in Cynefin terms, with large elements of “obvious” and “complicated”. P.S. If you are wondering which stone to look under to find these people, you could do worse than start here.

You will learn the goal or destination in an Agile transformation is “complicated” which only an expert or analysis can tell you. Big name consultancies are good at providing a business case and delivery plan to help you secure funding and “commitment”. They will provide a nice “complicated” powerpoint diagram showing all of the elements of the new organisation. It will be a beautiful diagram with an even more beautiful story told by beautiful expert story tellers in beautiful suits with beautiful hair. It wont work of course, but it will be beautiful.

The good news about assuming the transformation is “complicated” is that if it doesn’t work, you can always blame the experts and their beautiful diagrams. This is a particularly popular strategy in risk averse cultures.

Finishing an Agile Transformation Fast the Complex / Chaos Way

Although the goal is “complicated” the transition from where you are now to where you want to be sits firmly on the border between “Complex” and “Complicated”. Although everyone might agree that the destination is Paris, the path you take will be different dependent on whether you are in Versaille, or London, or Tokyo, or Cape Town, or Athens, or Olympia, or more likely Olympus Mons.

Experienced agile practitioners will tell you that tales of success are inspiring but you need to dig beneath the polish and look at the failures. Success is more likely if you avoid the failures rather than try to emulate the success.

Screen Shot 2017-04-15 at 14.27.17.png

You will need to set up a portfolio of “safe to fail” experiments. Experiments that tell you the best place to apply LESS, the best places to try SAFE and DAD and Nexus. The best places to organise using the Spotify Model and the best to organise using the Buurtzorg Model. In order to make the experiments “safe to fail” you will need to speak to people with real experience of applying these approaches so that you can learn about the known failures. You won’t find out about failures from a sales brochure or a shiny powerpoint. You find out about them from people who trust you.

Executives attempting an Agile Transformation need to build a lot of trust and that takes time. It takes time to build trust with the Business Heads, and the CFO, and the CRO, and the CPeopleO, and the COO… Especially as the CIO is often not considered important enough to be on the board of non technology companies, often reporting to the CFO or COO.

When instigating a Lean Transformation Students of Taiichi Onho would insist on the board, lead by the CEO making a significant change to the production line. Taiichi Onho’s students would lead them from the boardroom and make them publicly dismantle a key part of the production line. If they were not prepared to do that, Taiichi Ohno taught them to walk away as they were not ready. If an organisation is embarking on an Agile/Lean Transformation, the first act of the board should be to appoint the CIO to the board (if they are not already on it). The second act should be for the board to go to the place where the transformation will start and dismantle the desks and dark cubicles with screw drivers and allen keys and , and replace them with collaborative spaces. The board should collaborate with the teams to create the Kanban boards that they want to see when they “Go the Gemba” to sit with the teams so that they can remove impediments and blockers for the teams. If the board are not prepared to do these things, they should abandon the transformation before they start.

The board need to understand that the transformation is not the destination. They need to understand that the transformation is the journey. They need to nourish and protect their experiments, removing impediments and blockers for them. At Agile2007 in Washington D.C. one of the participants stated that “Agile is a commitment to personal growth and learning as well as a company’s commitment to growth and learning.” The board need to make their trailblazers feel safe on their learning journey and shape a culture that supports growth and learning. The board need to be involved and make sure that improvements are happening. The board needs to ensure that value is delivered along the journey and not just at the end. A constant movement towards a better organisation.

A tale of two approaches

The Agile approach to transformations is to start small and gradually grow the size of your “safe to fail” experiments as you succeed. Start small and build your knowledge. Grow your people and get them to engage with the Agile community outside of your company. As you build your knowledge, build your infrastructure and risk management systems to support the new way of working. The key to success is growing the knowledge and experience of your existing people so that its your own people who do the scaling and not external consultants.

The executive approach is to hire a big name consultancy, create a top-down big up front design of the organisation and implement it in a big bang approach. Of course the bang normally comes just after the consultants have taken their fee. It is normally driven out of IT as an IT initiative without the need for proper engagement with the business. The IT executives do not need to learn anything new as they are doing it to their organisation rather than with the organisation. The good news about this approach is that the experts or consultants can be blamed when it fails.

Perhaps if CEOs were given the proper amount of time to roll out a transformation and given the proper support of their colleagues on the board (assuming they are on the board), they might try a more sensible approach.

Executives and Courage

A key value of both Scrum and Extreme Programming is courage. Both methodologies are based on the idea that team members create a system that allows them to act with courage.

Screen Shot 2017-04-09 at 14.30.07

Scrum says…

“Because we work as a team, we feel supported and have more resources at our disposal. This gives us the courage to undertake greater challenges.”
Extreme Programming says…
“We don’t fear anything because no one ever works alone.”
Agile believes that team members can act with courage because they act as a team where everyone supports each other and no one is allowed to fail as an individual. Executive teams by comparison are assigned clear accountability and responsibility for certain operation aspects. This accountability is so baked into the executive culture that it is reflected in their job titles. Chief Financial Officer, Chief Operational Officer, Chief Information Officer, Chief People Officer. Yet these roles interact. Operation fails because the technology is lacking. The technology is lacking because there is inadequate investment funding. Investment Funding is inadequate because spending on Operations is too high. They operate an inter-connected system by trying to optimise their own sub system. Even worse, they are often competing with each other in a zero sum game bonus and promotion culture. This lack of team work and safety at the executive level leads executives to lack courage and they engage in risk averse behaviour that permeates the culture of their organisations.
To understand risk aversion, lets look at the behaviour of investors. Risk appetite is a well studied and understood aspect of finance. In finance, there are three categories of risk appetite:
  1. Risk Averse – The risk averse want to avoid or ignore risk. Their main strategy is to get an expert to manage the risk for them.
  2. Risk Neutral – The risk neutral are flat risk, they buy and sell and aim to keep their position flat or neutral. They often act as intermediaries in deals or use their superior expertise to break complicated problems into simple ones.
  3. Risk Takers – These people seek to understand risk and manage it. Their goal is to make risk free profits through arbitrage.

In finance, behaviour of the people with the intention of being risk averse is to assume massive risk due to their ignorance. The behaviour of risk takers is to understand risk and only take it on when they are adequately compensated, often making profit with no risk.

When attempting to transform an IT function, most executives are risk averse. They seek to hire experts who will manage the risk for them. The problem with hiring experts is that you really need to be an expert to hire them otherwise you will not know whether they are an expert or a smart person reading one chapter ahead of you. As a result, executives tend to appoint big name consultancies so they cannot be blamed as an individual if things do not work out. Robyn Dymond has written an excellent article on the subject. The reality is that most big name consultancies have little or no depth of Agile experience. The big name consultancies are buying in experts themselves.

So what is needed for an executive to adopt the agile value of courage?

  1. The whole executive needs to work as a team to solve the problems that an Agile Transformation throws up. The CEO needs to act as the product owner and the CFO, COO, CPeopleO, CProductO, CMO, Business Heads need to act as a team rather than compete. They need to empower and support whichever executive is leading the transformation and help them remove impediments where ever they arise. This will allow the executive leading the transformation to manage the risk rather than go risk averse and appoint a big name consultancy. In other words, the executive team needs to model the behaviours that they want to organisation to adopt.
  2. The entire executive team need to engage in deep learning. Each executive should engage a number of coaches and commit several hours a week to learning about the new way of running the business. After all, they are transform their organisation and need to know how to run it when it has changed. This will mean new behaviours and patterns of working. It will almost certainly mean that all executives will need to “go to the Gemba” (Go to the place where work happens) rather than receive the majority of their intelligence through carefully manicured and filtered powerpoint decks.
  3. Executive will need to visit companies that are touted as successful. However, that is not enough. They need to use their existing employees and coaches to manage context risk. Get their team to attend conferences and find out the real stories behind the success. Understand if the solution they are looking to adopt will fit with their context. Most importantly, they should know what failures have been experienced by organisations adopting approaches.
  4. The executive leading the transformation should engage in several “safe to fail” experiments to try out different methods and approaches. They should try out one or two big name consultancies, as well as small niche Agile consultancies, and groups of independent experts. The only measure of success for these projects is real business benefit and not the production of paper or software “deliverables”. The IT Risk Management Framework might be useful for this.
  5. The executives need to understand that an Agile Transformation is hard and that some of the sacred cows of cost cutting need to be slain along the way.
  6. Any consultancy proposing a big bang, one size fits all approach should be shown to the door. That is exactly the reason the IT Risk Management Framework was created, so that teams and departments could adopt the most appropriate method for their context in the knowledge that the IT investment risk was managed if they operated within the constraints of the framework.
  7. Finally, executives need to understand that context is the most important thing for them to consider. They should become experts at managing risk and spotting when a solution does not map well to the context.

So whenever you are thinking that your executive is not acting with courage, understand that it is probably the team they are working with and the reward system they operate within that forces them to be risk averse. Its really hard to go back and learn a new way of thinking and doing, and it is something that will only really happen when you have the support of your team.

Executives and Safety

This is the third post on where Executives and Agile Experience diverge. It relates to the attitude towards creating a safe environment to work in and in particular the attitude towards “Get it done” individuals.


“Get it done” Individuals

Executives love “Get it done” individuals. “Get it done” individuals agree a set of outputs and deliver them with ruthless efficiency and focus. “Get it done” individuals speak to executives in simple terms that the executives understand. In return, “Get it done” individuals focus on the results and nothing else. Anything that stands in the way of the agreed outputs is steamrollered in pursuit of the goal.

Agile environments are learning environments. In order to learn, people need safety, emotional safety and job safety. “Get it done” individuals are toxic in those environments. If you are an executive, and you want to create an Agile Environment that delivers outcomes rather than outputs, you need to have a zero tolerance to the following:

  1. Threats
  2. Abusive Behaviour
  3. Bullying
  4. Prejudice
  5. Cronyism
  6. Cliques
  7. Wilful Incompetence
  8. Over simplification
  9. Lying
  10. Failure to deliver outcomes

These are all tactics that “Get it done”.

Agile practitioners have a zero tolerance towards these tactics. If you do not stamp these out, especially in your “Get it done” individuals, your best performers will leave and you will be left with a culture of under-performance.

Threats, Abusive Behaviour and Bullying

You would think that in any modern organisation, threats, abusive behaviour and bullying would result in instant dismissal. However it turns out that these behaviours are tolerated by executives in “Get it done” individuals, especially if it is in the pursuit of results. “Get it done” individuals are expert at these tactics. Years of practice means that they know just how far they can go. They know what to say that gets the menace across without putting themselves or their career in danger. They have honed their tactics to know when they can most easily get away with it (late at night in an empty office is popular) and when they cannot (in a public place where there are independent minds that they cannot control).

These tactics mean that the “Get it done” individual can slice through argument and get things moving in the way they want. The fact that they might traumatize people in the process holds no interest for the executive.

Agile is all about learning. Individuals who embrace agile start to learn at a much faster rate than colleagues who do not. Learning means taking chances and trying new things. The result is that these individuals become much more valuable in the marketplace. When these individuals experience threats, abusive behaviour and bullying, they discover they have options, ones that pay them more, and ones that have better working conditions… ones without threats, abusive behaviour and bullying.


If you are an executive and you tolerate prejudice in your organisation, expect your best people to leave. Prejudice takes many forms. As well as racism, sexism, homophobia, beware of more subtle forms like roleism or employee type.

Agile as a community is bringing together all of the roles to work out better ways of delivering value. If your developers are allowed to abuse your testers and business analysts, good people will leave. Similarly consultants and permanent staff should not abuse contractors or vice versa.

As an executive, it is your responsibility to stamp out any form of prejuduce. Agile believes executives own that responsibility and should actively detect problems and remove them rather than turn a blind eye or claim that you were unaware. A failure to be aware of prejudice is no defence as it is the executive’s responsibility to know.


Cronyism and Cliques

“Get it done” individuals love cronies. They love people whose primary qualification is loyalty. They will happily deploy individuals who have neither the “Skill” and/or the “Will” to do a job, simply because that person will be loyal drone and act as a spy. “Get it done” individuals will happily employ people who add no value simply because they are loyal and spy for them, or drive through their agenda.

People  without the “Skill” and/or the “Will” create resentment in the hard working individuals who are delivering value because they have to work harder to carry them.

Experienced “Get it done” individuals will have a number of cronies who form a clique. The trusted individuals who drive through the “Get it done” individual’s agenda are also allowed to do whatever they choose. The clique get the credit because its the “Get it done” individual who delivers the message to executives. By comparison, Individuals outside the clique get no recognition by the “Get it done” individuals even though they are the ones doing the work.

Guess what the highly talented, delivery focused individuals do when they encounter cronies and cliques?

Executives in learning organisations “go to the Gemba”, they connect with people at all levels of the organisation. They make it easy for anyone to tell them about risks and issues. Successful executives in Agile organisations make themselves accessible. Individuals do not abuse the option to access power, they respect the individuals time and only come to them with important issues. Giving everyone access to power rather than just the select few means there are no stones unturned, or dark places for the cliques and cronies to hide beneath.


Wilful Incompetence and Over simplification


“Get it done” individuals celebrate the fact that they are not experts. They celebrate the fact that they are incompetent as if that was a positive quality. They are action oriented individuals who are experts at making decisions. They often make the wrong decisions but that is never their fault. They celebrate the fact that they can take complex and complicated situations and come up with an obvious solution. Einstein said…

Everything should be made as simple as possible, but no simpler.

“Get it done” individuals have simplified this statement further to form their own manifesto…

Everything should be made as simple as possible.

As a result, complex and complicated tasks like Lean and Agile transformations become reduced to a four step process:

  1. Measure the lead time
  2. Map the value stream
  3. Identify delays
  4. Remove delays

Executives love this simplification that removes the messiness of context and the challenges of understanding their customers and the things that they value.

Experts find themselves in meetings where they struggle to explain to executives that the over simplications are right… but utterly useless. Experts that discover they are valued more in other organisations where the executives share the view that “but no simpler” is just as important.

So Agile believes that Executives should learn about the things they lead. They should learn enough that “Get it done” individuals cannot violate the “but no simpler” rule.

Lying and Failure to deliver outcomes

Lying is an art form. Its harder to lie on an Agile project but it is still possible if executives lack experience with the Agile Toolkit. Executives that are new to Agile will be steered toward burn down charts, velocity graphs and lists of stories that are completed during a sprint. In other words, they will be steered towards activity and outputs rather than outcomes.

“Get it done” individuals will point to stories that demonstrate activity and inputs. They will point to the completion of features and stories.

Agile believes in transparency.

Agile practitioners understands that burn downs and velocity are tools for the team to help the team improve.

Agile practioners understand that progress is measure by achieving business value outcomes and showing progress toward delivering business value outcomes. (Progress is shown using cumulative flow diagrams.)

Executives are too tolerant toward “Get it done” individuals that fail to deliver business value outcomes. Executives are far too tolerant towards “Get it done” individuals who restate complex problems as complicated or obvious problems with a contractual check list of deliverables and outputs. Instead of “reduce churn in Asia”, the problem is restated as “build a blue widget” or create a “Service Blueprint” and a “Wireframe”.

If your deliverable does not involve an outcome involving the customer, you are probably being had.

“Get it done right!”

Agile practitioners “Get it done right”. They believe in delivering value with sustainable quality, and managing risk by reducing lead time and providing transparency.

In order to achieve this, the following constraints need to be applied by executives:

  1. Create a safe environment to learn, where it is safe to fail because individuals are taught how to create safe to fail experiments, and understand their risk limits.
  2. Have a zero tolerance to “Get it done” individuals or anyone for that matter who engage in any of the following.
    • Threats
    • Abusive Behaviour
    • Bullying
    • Prejudice
    • Cronyism
    • Cliques
    • Wilful Incompetence
    • Over simplification
    • Lying
    • Failure to deliver outcomes

Executives need to take responsibility for their organisations and the culture in their organisation. Not knowing is no longer an acceptable excuse.



Dragon Slayers and Farmers

This is the second post on where Executives and Agile Experience diverge. It relates to the attitude towards Dragon Slayers and Farmers.


The Dragon Slayer

The executive sat in their office looking out toward the team. They hoped that today would be a quiet day, a day without Dragons. Draco arrived late and unpacked their back pack over their desk. Draco was often late because they nursed the system late into the early hours until it was stable and on its way to a successful run. Draco had saved the Executive’s job several times… a week… ever since the executive had taken over.

The executive opened outlook and started to scan their e:mails and mark them as urgent or important. As they worked down the list, a small crowd of the usual players gathered around Draco’s desk. Draco took a sip of their coffee as they listened, put down the coffee, and removed their glasses to pinch the bridge of their nose. They closed their eyes and remained still for a moment before silently nodding consent. How many times had the executive seem this ceremony play out? The players were headed towards their office. Behind them, the executive noted Giles and returned his wave. Giles pointed at their wrist indicating they would be over in five minutes for their one-to-one. Giles would push the executive for more money to invest in irrigation and fences, not an exciting decision for a battlefield commander. The delegation was now at the executive’s office. They paused at the threshold to make eye contact and agreement to progress. The executive waved them in and they rushed to their familiar spots around the executives small table, with the major positioned at the white board.

“Dragons! Dragons!”

The major cleared their throat. “The trades failed to cross the bridge. There was a new variant of trade that caused the check-point to fail.”

The executive nodded. “Go on.”

The major drew three squares on the white board and tapped on them before crossing one out. “I propose we clear the bridge, delete the offending trade and restart. We should be done by the deadline and the Prince need not know anything about it.”

Out of the corner of their eye, the executive saw Farmer Giles hovering at the threshold to the executive’s office. The executive waved the farmer away. The one-to-one would have to wait. There was a Dragon to slay!

The executive stared out his window at the office directly opposite. The office with a small leather sofa AND a small table. The office that they hoped would be theirs one day, providing the Dragons did not kill the executive’s career. “Draco, what do you think? Will it work.”

Draco blinked behind their thick glasses. Remained silent for a few seconds and then replied. “It won’t work. There are several reconciliation points which would fail later on as they check to make sure every trade is present.”

The major jumped in. “So what should we do?”

Draco, more confident now. “Lets clear the bridge. I’ll copy the bridge script and create a tweaked version for the new trade. We should hit the deadline.”

They turned to the executive who continued to stare out of the window. “Draco. Will it work?”

Draco was quick to answer. “Yes. It will”

The executive closed their eyes. This is a good decision for a battlefield commander. “Do it!” they said.

“I’ll get my men to clear the bridge and prepare for the script variant.” The major was happy to have a role to play in slaying the dragon. They all rushed from the executive’s office.

Later in the day, the executive looked up to see the Prince laughing and joking with Draco and the Major. The Prince saw the executive looking at them and waved. He strode over toward the executives office. “Great team you have here.” And then the Prince was gone.

The Farmer

The farmer signaled to the executive that they would join them in a few minutes as they passed behind Draco and co. The farmer checked the monitors for their system. Nothing had happened. Boring, boring, boring! Just as they liked it.

They dropped their bag on their desk and headed over to the executive’s office wondering whether their weekly one-to-one would happen. It was cancelled more often than not by a wondering Dragon that Draco needed to slay.

The executive waved the farmer away. They frowned, it would mean longer until they got more capacity in the lower field.

The farmer was grateful that they did not have to fight Dragons every day. The first few months had been hard. Early starts, late finishes and never a chance to help with the school run. The arguments with their partner because they could not take the kids to school or drop them off. Hiring the right people, shaving the Yak, introducing effective tests, removing technical debt. “Digging ditches and mending fences” as he explained to the executive and Prince. Now the system was boring, boring, boring. The farmer saw no reason to leave, provided they got the promotion they expected.

The Annual Appraisal

The executive hated the annual appraisal and promotion round. There were always people who were angry and annoyed. This year was going to be worse than normal, the Prince had told the executive that there would only be one promotion in their team. They would have to choose between Draco and Giles.

The executives focused on the questions that formed the promotion request.

“Please give evidence of leadership and problem solving.”

“Please give evidence of calm leadership under pressure.”

“Please give evidence of where the candidate has put the company first.”

It was easy to fill out the form for Draco. Draco filled the form several times a week. They barely knew Giles, it had been a month since the last one-to-one. He remember that he had been quite stressed when he started the job, and the executive had doubted their strategy of digging ditches and building fences when the dragons were flying overhead. In fact, the executive remembered feeling quite anxious about it all.

Besides, the Prince knew Draco well and did not know the Farmer at all.

The Aftermath

The executive was quite pleased with the way things were. Unfortunately Farmer Giles had left after it was announced that Draco would take over, something that had only been made possible by an ingenious double promotion. As soon as Giles and some of his team left it became apparent that they had been hiding things. Dragons had started to appear but luckily they had Draco in place to cope with them, the executive was sure that the system was now in safe hands. The executive looked forward to their new office.

The executive picked up the book in front of them “Agile Software Development” by Alistair Cockburn. Something about the story of the author’s son planting next year’s profit bothered them but they could not work out why.

Author’s note

There are a couple of points I want to confess to with this post…

  1. This is faction. It is based on several real experiences and observation made since first reading Alistair’s book.
  2. This is the first blog post I’ve tried to deliberately write in a gender neutral manner, trying to use “They”/”Them” instead of “He”/”She”. It was harder than I expected and it does not flow as well as I would like.
  3. The photo of the Dragon guarding the City of London was taken yesterday outside of Chancery Lane tube station. I tried to snap the Dragons in Moorgate and Bishopsgate but they are gone. Perhaps it is a sign that there are fewer Dragons in the city thanks to Agile?
  4. The photo is the first that I have edited. The dark original with tree branches and a tower is shown below side by side with the edited version finally used.

Screen Shot 2017-03-19 at 07.47.54