context Risk Management

context is the most important consideration for any organisation engaged in a Organisational Agile Transformation. Most teams of seven plus or minus two are fairly similar. The issues they face are fairly common and are fairly well served by established Agile practices like Scrum, Kanban and devOps (The new popular brand name for eXtreme Programming). Once you move beyond the team, the organisational context starts to play a bigger and bigger role. This means that as an IT Risk Manager, you need to manage the risk that failure occurs due to context. You need to understand the risk that a practice may work in one context but not in another. In other words, in which contexts is it safe to employ a practice, in which contexts do you need additional tools, and in which contexts is the practice likely to fail.

The Agile Community is an important tool for managing the risk due to the context. The Agile Community is a tightly knit, highly connected group of practitioners who communicate with each other about new ideas and contexts. Anyone can join the community provided they put in the effort to get to know the people involved. Although the strongest relationships are between those who meet face to face at meetups and conferences, there are plenty of on-line communities that are easy to join. The highly connected nature of the Agile community means that it is possible to connect people with a question “What problems did ABC have implementing XYZ” with the people with the answers “At ABC, we did not have a problem because of DEF. Solving DEF is your hardest problem.”. Often the material is in the public domain (e.g. on InfoQ, Vimeo or YouTube) if you know where to find it.

The Agile Community is the repository of all the failure stories that happened before the successful practice was discovered. Having access to these failure stories is incredibly valuable, especially as organisations modify practices and tools in order to make them work in their context. The principles and values help, but sometimes trial and error across a distributed community is the only way to succeed. Its not that the Agile Community hides its failures, its just that a book that says “We tried this and it did not work, we then tried this and it did not work,… and after ten attempts we came up with blah” is much harder to consume than one that says “Do blah, it works”. Think Edison and the light bulb, you get the idea.

The trusted nature of the Agile Community means that members are often aware of failures that are not necessarily in the public domain. One of the filters I apply when recruiting coaches who advocate a certain approach is their attitude to a less well known failure applying that approach. If they are not aware of the failure, they may not be as well connected as they think… and if they are aware of the failure but do not care, they are probably in the community of solutions rather than the community of needs. All coaches need to be in the community of needs, prioritising the organisation that pays them over their desire to promote their pet practice or tool.

The Agile Community is also a fantastic place to seek advice on how to make experiments safe to fail. They do this by sharing the cautionary tales (failure again) and offering feedback on things to watch out for.

High Quality Agile Product and Service Companies employ many highly connected and respected members of the Agile Community. Ronica Roth, Eric Willike and Martin Burns at Rally, Robert Holler and Olav Maassen at Version One, Dennis Stevens and Mike Cottmeyer* at LeadingAgile, Too many to mention at ThoughtWorks and BJSS. These individuals only work for these companies because the companies have a strong Agile pedigree. Their personal reputation and brand means that working for an Agile Industrial Complex company would lead to personal loss of (social) value and effectiveness within the network.

Agile Industrial Complex tend to hire Agile experts on a transactional basis. Often the people they hire have lots of qualifications but they are not trusted members of the Agile Community. This means that the coaches they provide to their clients do not have access to the richness of the shared memory of the Agile Community. This means that context becomes a big risk. Their coaches know the practices and tools, but they do not necessarily know where those practices and tools fail because they have only accessed Agile through the community of solutions (Training Courses). Junior coaches will often work in the Agile Industrial Complex as they build their own experience and personal brand.

Not all of the coaches in an organisation need to be members of the Agile Community, however if none of them are, you are exposing your organisation to context risk.

Thank you to Guy Winterbotham for inspiring this post with his comment yesterday.

*Mike Cottmeyer, what can I say. Highly connected but….remember Agile2009? 😉

Cultural Debt

Most of us are aware of the concept of “technical debt”. “Technical debt” refers to short term compromises to speed up delivery of value that have to be paid down in the future. For me, “Technical debt” does not impact quality or value directly, but it has a huge negative impact on lead time and thus massively increases the risk of IT investments. Extending the metaphor, “Cultural Debt” is when we make short term Cultural compromises in order to speed up our Agile transformation which result in significant repayment in the future.

When considering “Cultural Debt”, you need to consider how much harder it will be to bring about change in the future to remove the debt compared to the cost now.

Two common forms of “Cultural Debt” are:

  1. Imposing Agile rather than allowing people to opt-in.
  2. Focusing on Practices and Tools exclusively and ignoring the Principles and Values.

Imposing Agile

Imposing Agile on teams and individuals is completely opposed to the principles and values of Agile. Whilst Agile Industrial Complex members might advise a client to adopt this approach, they are doing their client a major dis-service. The corner stone of Agile is motivated teams who take responsibility for their own actions and make commitments to each other and the organisation. As soon as a manager forces a team to adopt Agile, they not only disempower the team, they also take away their responsibility for their own actions. The team may confirm and adopt the practices being imposed on them but they are less likely to engage and excel in them. As Tony Grout says “Most Agile Practices are the smallest process that will show you what needs to be fixed.” Teams that are not motivated will follow the process by rote and will ignore the improvements they should be making in favour of an easy “box ticking” life. Agile requires self motivated individuals who take responsibility for their own continual improvement. Continual Improvement is less likely to occur in teams where Agile has been imposed and the team are dis-empowered.

Fundamentally the organisation suffers in the long run.

Establishing a team’s responsibility from the start is much easier than trying to get the team to take responsibility later on. The team will have established their own culture and norms and will be reluctant to take on new responsibilities and changes, especially if they have gone through a painful recent change.

Rather than force a team to adopt Agile processes, a more enlightened leadership approach is to place constraints on the teams and let them decide how to meet them. This is what Al-Noor Ramji did at DrKW when he insisted every project should deliver value every three months. The leaders can then provide support for those who want to learn new approach (such as Agile) and tooling that might help them achieve that goal. An even more enlightened leadership might offer the choice of traditional oppressive governance and a light weight IT risk management framework.

Focusing on Practices and Tools exclusively and ignoring the Principles and Values.

The Agile Industrial Complex focus almost entirely on the implementation of new Practices and Tools. That is because it is significantly easier than helping people appreciate Agile’s Principles and Values. Teaching the Practices and Tools ignores that troublesome context stuff.

The Principles and Values are the way organisations adopt Agile in a resilient way. Ignoring the principles and values can result in cargo cult adoption that can fail catastrophically or regress when management attention shifts elsewhere. Much of the value of Agile is in the Principles and Values, even if organisations initially buy the Practices and Tools. Put another way, Organisations miss out on chance to have those super cool productive teams when they fail to acquire the Principles and Values.

However, starting with the Practices and Tools is a great way to build credibility with clients. Starting with the practices can naturally lead to introducing the Principles and Values at a later date. However the Principles and Values should be part of the discussion from the start. It is just that the organisation may not adopt the Principles and Values at the same time as the Practices and Tools.

Implementing the Practices and Tools only is Fake Agile. Sometimes you have to fake it until you make it. But you should never settle for just faking it.


Starting with the Practices and Tools and then adopting the Principles and Values later is an example of Cultural Debt that might naturally be paid down provided the Principles and Values are part of the conversation from the start. Agile coaches should always model the Principles and Values otherwise they will lack credibility later if they try to implement them.

Imposing Agile on teams is an example of Cultural Debt that is very risky from the organisation’s perspective. Forcing teams to adopt Agile may make it difficult or even impossible for the teams to accept responsibility for their own actions later. If your Agile Industrial Complex partner is suggesting you impose Agile, you should show them the door and find a new partner who’s goal is your success rather than an easy life.

Principles Over Practices and the AIC

“We value the Principles over the Practices” was one of the key learnings that I took away from the Agile Development Conference in Salt Lake City in 2004. From the start, the “leadership” of the Agile Community decided that the most important aspect of Agile was the Principles and Values, and not the Tools and Practices.

Most Agile Practitioners I know constantly dip into the Principles and Values which act as their true north for how to handle contexts that they have not encountered before. It is the principles and values that drive the creation of new tools and practices, something that was a constant in the early days of Agile. It was the principles and values that allowed people to say “That’s not Agile!”. Many a “good” idea was tossed aside because it did not align with the Agile principles and values.

The problem with the principles and values is that people need to change their values to “get Agile”. It takes time for people to make the journey to a new way of seeing and thinking about the world. And some people don’t make that journey, either because they can’t or they do not want to. By comparison, adopting Agile Practices and Tools is fairly straight forward and generally doesn’t challenge your values and principles. The result is an explosion of the Agile practices and tools, and a absence of the principles and values.

I’m sure you’ve experienced something similar to these:

  1. A flag ship “Agile” project that follows Scrum/Kanban religiously but hasn’t done a release to customers for two years.
  2. Development teams that use Given-When-Then but do not engage with the business or Product Owner.
  3. Retrospectives where people are criticised for raising issues.
  4. “Agile projects” with fixed scope, fixed budget and fixed timescales that have been negotiated in a dark room by people not involved in the delivery that does not allow for customer collaboration.
  5. Agile practices imposed on teams as “Best” practice.

Around 2010, executives in organisations across the world woke up to the promise of Agile. They noticed that teams adopting Agile were more effective than teams following traditional methods. They mandated the use of Agile because they wanted results. The results they wanted were those delivered by teams that adopted the values and principles, and not the practices and tools. Teams were not successful because they adopted Given-When-Then, they were successful because the customers and business subject matter experts were communicating effectively with developers. Teams were not successful because they adopted Jira but because they were self organising, collaborating and acting with self discipline. The results came from adopting the Principles and Values. The practices and tools were incidental and often ditched by Agile Practitioners in favour of a home grown approach that better fit the context.

In 2010, the number of Agile Practitioners was growing, but not growing as fast as demand required. This lead to a vacuum. The traditional waterfall service integrator and snake oil salesmen stepped into the vacuum and created the “Agile Industrial Complex” as Dan Mezick calls it.. “Doing it” is no longer a criteria that matters, with thought leaders promoting ideas they just made up and never tried. Self Organisation and Frequent Releases of Value are optional, to be tolerated at best. The Agile Industrial Complex sees Agile as business as usual, but with stand ups and stickies.

I see the need for a new movement, a movement that focuses on the Agile Values and Principles. Practices and Tools relegated to examples of how to implement those values and principles. A movement where only those who are “Doing It” are allowed on stage, and theorists and marketers are allowed to suggest hypotheses but not allowed to profess something as good until is properly tested in all contexts. The name I’m noodling with is “Context”. The “Context” Movement as context is what matters more than anything else.

Why is this so important now? The Agile Industrial Complex (AIC) is destroying the Agile brand that so many Agilistas have worked so hard to create. The AIC is telling clients that they have solutions (Practices and Tools) to the Scaling Agile problem, solutions that have not been tested in all contexts and could lead to major failures. Our clients deserve the Agile based on values and principles that truly delivers results. They deserve better than the roll out of sad grey practices and tools that break when they encountered new contexts that they haven’t been tested in. Our clients deserve to know that the practices and tools they are adopting have failed in certain contexts, and an understanding of the context they failed in so that they can manage the risk properly.

So lets clean ship and adopt integrity as one of our values. Lets write experience reports about the failures as well as the success. Lets acknowledge the real state of Scaled Agile.

Lets create a new community called “Context” based on the principles and values of Agile.

Lets deliver the value that our clients deserve and show them by example the difference between context and the Agile Industrial Complex. Lets show what it means to be really Agile.

  • Deliver Value
  • Reduce Lead Time
  • Sustainable Quality
  • Manage Risk

Please leave a comment regardless of whether you agree or you think I’m smoking crack.

Why I find Agile Coaching so hard

During my LAScot keynote last year I explained that when we are immersed into a new culture we can see all of these things that are alien to us.


As we adopt the values of the culture around us, we no longer see the things that are alien to us. Adopting the values of the culture around us is important. It makes us one of the “us” tribe, rather than “other”. It means we feel comfortable and we can drawn emotional strength from being a member of the tribe. We feel safe.


When I was a practitioner, before Agile was considered “best practice”, I was part of the team. I was part of the tribe. We worked together to deliver using Agile. Everyone went through their own learning journey and understood the value of Agile to them personally. They were there because they chose to be. We were content to be allowed to work the way we wanted and did not care how others worked. Now Agile, or the Agile Industrial Complex as Dan Mezick refers to it, is imposed on Organisations as “Best Practice”. As a coach, I participate in this imposition of Agile on the Culture of Organisations. As a coach I try to help individuals understand the value of agile so that they can “opt in” to their own personal journey. The companies I work with do not force Agile on the teams as the teams self select into Agile. However we are introducing a new culture with a new set of values. A new culture that the existing culture supports in some ways but opposes in more significant ways.

As a coach it is important to live the values of Agile, such as self organising teams, which sets you apart from the existing culture. In fact, as a coach you lose your ability to see problems if you become part of the existing culture. You are no longer appalled that management imposes organisation or targets on the team. You are no longer appalled when management start estimating points for the team so that the team can hit deadlines that have been imposed. Management do this for expediency because doing it the Agile way is too hard and takes too long. Doing it the Agile way means winning hearts and minds. Doing it the Agile way takes too long for senior management who want results for their impatient executives. The forces and motivations are easy to understand, but real change is hard and takes time.

This inability to assimilate into the existing culture is hard, especially on long term enterprise wide transformations. It is this needing to hold firm to Agile values that is exhausting. It is made harder because as a coach you need to maintain empathy for those who have not yet started their learning journey, to maintain empathy for those who oppose you.

I find it is only possible if you have a support network of like minded people to understand and empathise with you. And that is why I’m so grateful to Tony, Marc, Kate, Jitesh and the crew for reminding me I’m not crazy. That there is another way.

Fundamentally it about understanding that an Agile Transformation is about changing Culture, which in turn is about helping people adopt a new set of value. The Agile Industrial Complex picks and chooses the Agile Practices it sees as important. It imposes those practices rather than promote the principles and value of Agile.

So as I start my two week of rest, I would like to thank all of you whose support makes the Agile Coach role bearable. Who provide the creative ideas and emotional support that make it possible. Thank you all and merry non denominational pagan based festival of peace to all.

NB. This is a personal experience. I make no claims that anyone else feels the same.

Six Agile Executives to Study

Whenever agilitistas get together they lament that their attempts to improve an organisation are thwarted by the executives. Not by an active attempt to undermine an agile transformation, but rather a lament that they unwittingly destroy the improvement in the same way that a five year old destroys their parent’s favorite rose bed in an attempt to build a mud castle. This might lead casual observers to reason that all executives are ignorant, uninformed and self obsessed. I may be an exception to the rule but I have been fortunate to work with a number of inspirational executive. I have learned a huge mount from them over the years. Many of the practices I have adopted came from them. My only lament is that they are not studied as closely as they should be. Instead the agile community is obsessed with promoting “celebrity executives” who have never delivered significant agile change, or done the things they talk about.

This post is about those executives who I have been fortunate enough to work for, executives who have profoundly impacted the way I work, think and the way I look at the world. I have worked for some duffers but rather than focus on the mediocre, I chose to celebrate the genii. The common differentiator is that these exceptional executives were not afraid to do the right thing, they were not obsessed with hitting the targets on their balanced score cards. They all focused on brilliance and refused to compromise. Each of them realised they were sailing in uncharted territory and managed that uncertainty rather than follow the rest of the flock like sheep… or lemmings. Once a practice was established they would adopt it but they were smart enough to realise when they should go it alone.

A number of these executives were difficult to work for. Mainly because they had a vision that was not the run of the mill, and we often got things wrong as we attempted to execute on the the novel using our old tired perspective.

In chronological order:

Andrew Green

When I moved into Andrew’s world I was a fully fledged Waterfall developer and business analyst / project manager. Up to that point in time I had been a slave to the process. Andrew’s team were different. We focused on the customer, and we focused on speed. We focused on getting stuff done for the traders and those that supported them on the trading floor. Shortly after I joined in 1997, stacks of four or five PCs appeared at the end of each trading desk. On top of each stack was a single monitor and keyboard and a switch to select which PC box. These stacks were the fore runners of Grid computing.

Al-Noor Ramji

Al-Noor stands out even in this crowd. He demanded several challenging things from his department. You had to deliver value to the customer every three months or he would pull funding. I remember the all hands when Al-Noor declared victory and his speech “It took three or four years and the hardest part was convincing the business, but we’ve done it”. Al-Noor set very high standards for his department that he would not compromise on. Everyone needed a masters degree and everyone needed to attend an all day assessment centre, where they had to score in the upper quartile… a bar that continually raised. In addition, EVERYONE had a final interview with Al-Noor. This broke down the power distance index and meant that everyone had met him personally. Everyone could stop in the corridor and tell him about a problem he needed to know about.

During the dot com boom, Al-Noor challenged his team to think like start ups and regard the bank as an incubator. I know of at least two successful companies that spun out of Dresdner as a result.

Al-Noor was also incredibly loyal to his people. When I was made redundant, he met me to explain how I could go about getting a job in his new department. This was a man in charge of a department of ten thousand people and he took the time to meet with one junior person.

JP Rangaswami

JP took over from Al-Noor who had moved to QWest. Personally, JP had the biggest impact on me as a person. He drove me to learn about how to do my job, he drove me to think. It was during this period of my career that Paul Simmons introduced me to the eXtreme Tuesday Club. It was because of JP that I valued it. JP had me read “Agile Eco-Systems” by Jim Highsmith, “The Social Life of Information” by John Seeley Brown and the Cynefin White Paper by Dave Snowden. It was during this period of time that I started to use Staff Liquidity and early versions of the skills matrix. We created the practices that would become “Break the Model” and wrote the “A project creates value when we increase revenue, reduce cost or protect revenue.” paper. The first two from “The Goal” and the third from the Global Debt Business Manager at Dresdner.

JP was incredibly accessible to everyone in the organisation and this had a profound effect on the culture. He encouraged people to think and to learn.

To this day, Dresdner Kleinwort Wasserstein is still the most Agile organisation I have worked for.

Mark Gillet

Mark is a genius. He drove Skype to adopt Scrum but realised it was not enough. He understood that the organisation needed a definition of value and created the Value Cascade (Hierarchy). Mark also understood that the application needed to be redesigned in order to create the right agile organisation in order to deliver value. Mark understood the need to fund teams instead of projects. My prediction is that Skype will come to be known as the Zerox PARC of Scaled Agile.

Lee Nicholls

Lee is an executive who has actually studied Agile and Lean. It is very intimidating meeting an executive who has an understanding of Agile and Lean that surpasses that of many coaches. He managed to distill all of his knowledge into a single simple strategic goal for his organisation. Reduce lead time by 50%.

Jim Bannister

Jim showed me what the Product Owner team of the future will look like. He created a department with skills and experience that I had never experienced before. He did not just pay lip service to some of the hip and groovy product memes. Instead he created a team with skills and experience that I had never experienced before. He has a practical hands on approach to product that uses techniques that I had never seen before.

If you get the chance to work with any of the above, I would heartily recommend it. It may not always be comfortable, but you will learn in ways you do not expect.

The real state of Scaled Agile

On Thursday I delivered the opening Keynote at Conferencia Agile Spain. They are an incredibly warm and supportive community. I highly recommend that speakers join them if they get the chance. ( The beer and tapas was fantastic! )

The talk started by introducing the Community of Needs / Solutions ( Video from LAScot ). Part of the talk explains how an idea progresses from “Need” to the “Chasm”.


The journey from “Need” to “Chasm” involves the idea encountering new contexts (or Fitness Landscapes) that it was not originally invented in. As a result the idea is refined. An idea starts in one place (even though their might be several similar ideas being developed at the same time) with one small group of people. Initially the idea spreads by word of mouth with “first followers” who have direct access to the originators. Then people share in workshops with people with similar ideas. By the time the idea reaches the chasm, most people access the idea through “books”, and most of these people do not have access to the originators.

As an idea travels towards the chasm more and more people encounter it, and start to value it as they understand how it can help them in their context.


I introduced the ideas/tools* that are needed to manage a Scaled Agile organisation. The CAS audience then voted using red and green cards to indicate whether they valued the idea and had started to learn about it as a result. We counted the percentage or red and green cards to understand where an idea is on its journey.


The results were much as I had expected.

If you listen to the people selling “Scaled Agile” frameworks, the consultancies selling Agile to executives who do not know what Agile is, they present an picture that looks like this.


I’m not describing the Agile Consultancies who act with integrity. I’m not talking about ThoughtWorks, BJSS, Radtac and Leading Agile. I’m talking about the consultancies that sold Waterfall and Off-Shoring to their clients as the way forward.

The CAS audience present a picture that was similar to the one I expected…


Now more than ever we need Communities of Need to try out the ideas in many contexts to ensure they are safe to cross the chasm to the unforgiving CEOs who live in a place that demands certainty, the realm of the early majority.

* The ideas/tools I referenced in the talk are:


  • Scrum
  • Kanban
  • Extreme Programming
  • Retrospectives
  • Given When Then


  • Cumulative Flow Diagrams
  • Cynefin
  • Cynefin AND Cumulative Flow Diagrams used together
  • Skills Matrix


  • Demand Mapping


Enabling Functions

  • Beyond Budgeting
  • HR policies that create a collaborative creative culture


The number one problem with Waterfall.

Waterfall is a driver-less car circa 1930. You have a list of tick box items that check to ensure you have followed the process correctly. If you follow the process, your organisation will be safe from rogue projects and bad investments. It will protect you from risks on your IT Investment.

First thing I thought of when Uber announced they were going with driverless cars

And this is the number one problem with Waterfall. Passengers on the driver-less car can absolve themselves of responsibility for risk. They can blame the creators of the driver-less car if it fails because it encounters a context that wasn’t anticipated by its creators.

The alternative to the driver-less car is a normal car with a Instrument Panel, Steering Wheel, Cruise Control and a SatNav. One in which different people take responsibility for overlapping risks. The executive ensures the investment is going in the right direction and that it is effectively managing all risks. The executive is like the passenger trying to reach a destination. The product organisation are responsible for picking the right destination and the right route. The delivery organisation are the driver and the engineers who drive and look after the car. Each manages a set of risks that overlap. Each has responsibility… including the executives. In order to manage those risks, the organisation needs a framework to help them ensure they understand the risks, and appropriate processes and instrumentation to ensure the risks are visible and managed effectively.

Rather than rely on the framework to manage the risk on an IT Investment, an IT Risk Management Framework specifies the constraints that allow the risk on an IT Investment to be managed by the Operators, namely all the people involved, including the executives. As well as managing known risks, everyone is responsible for identifying new risks ( or risk leadership as I call it ). This allows the IT Investment eco-system to respond to shifting contexts and emergent risks.

The average “Scaled Agile” project is probably like a normal car without Instrument Panel, Steering Wheel, Cruise Control and a SatNav. Or rather bits but not the whole thing, and with a dodgy steering wheel.

So instead of relying on the creators of your Waterfall to provide you with a “circa 1930s driver-less car” to provide your risk management, opt for a top of the range vehicle with trained drivers, mechanics, logistics team and executive who can adapt to the context and risks that your organisation faces.

Renounce risk averse, and embrace risk management.

Footnote for Execs: During the second world war a study was performed to see which role was most stressful. It turned out the barrage balloon spotters had the most stressful role. This was because they could easily be killed by enemy pilots but they had no control over their situation. The average executive responsible for a Waterfall Project has the same level of control as the barrage balloon spotter because they are blind and can rarely identify opportunities to intervene in a timely manner. They are like a passenger in a car traveling at ninety miles an hour down a motorway with no steering wheel, instruments and a blacked out windscreen. The IT Risk Management Framework cleans the windscreen, and installs instrumentation and SatNav. More importantly the timeliness of the information arrival process provides them with options to intervene… they get a steering wheel.

Just like Arnold, its time to take control of your IT investment vehicles before Start Ups and Fintechs catch up with you.