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.


Dear UK Energy Minister…

Dear UK Energy Minister,

I would like to make you aware of an interesting option that is about to expire. This option was discovered after almost five minutes of research and several discussions over coffee with David Stoughton, Nick Coutts, Graham Oakes and Tony Grout. If your expensive advisors have not made you aware of this option, you may want to consider replacing them with David, Nick and Graham.

The UK is engaged in building a new £18 bn power station at Hinkley Point. We need to produce enough energy to handle peak demand. If we look at the seasonal and daily variation in energy need, from Chart 2 we see that the difference between average and peak load is about 10% to 20%. According to Wikipedia, we have about 80 power stations in the UK. So if we could plan for average demand instead of peak demand, the UK could reduce its generation needs by 10% or several power stations. We can only do that if we find a way to store electricity to balance demand and supply over time rather than instantaneously. Storing electricity is notoriously difficult with solutions ranging from pumping water between two reservoirs and using trains on steep hills, both to store potential energy. And this is where the option exists, and its an option that is about to expire. The problem with storing electricity is that the generators are looking for big electricity stores. The human body doesn’t store energy in one place, it stores a little bit in each and every cell. And that is where the UK should store electricity too… In every household. We should install Tesla Powerwalls in every UK home. For the cost of one £18bn power station we could buy 5.5 million Powerwalls ( Assuming £10,000 retail and £3,333 wholesale price ). That is one fifth of all UK homes or 20% of demand. Furthermore it would be a much less risky investment than building a power station.

Battery technology is the future of energy. It will spawn a massive industry to research and supply the batteries. An industry consisting of valuable jobs for areas of Britain needing more than McJobs and Call Centers. Real Engineering jobs. Britain could be a leader in battery technology and production. And that’s before we even think about the jobs generated by making and installing solar panels that look like roof tiles.

So why is the option about to expire? Because the Germans, French and every other country in Europe are probably thinking the same thing. So you have a short period of time before one of them calls Elon Musk to buy a chunk of Tesla.

Call 001-555-Battery. Good luck. The UK is depending on you.

P.S. It will help you with your climate change PR as you can switch from Coal to Nuclear as we all know the problem with Nuclear is it takes a long time to change supply. Batteries also facilitate the use of local green energy production… Solar*, Wind and bio-digestors

* Thank you Richard Warner for reminding me of the obvious. Doh!

Slice Value, Not Functionality.

Product Owners often struggle to make stories small enough. Agile projects end up with “MVP”s that take the team months to build. The solution to this problem is to slice value rather than functionality, but what does that mean?

Traditional projects often have a “scope”. “Scope” normally means “As an investor I have given you this much money for this set of functionality”. As a result, product owners and business analysts often focus on the functionality of the product rather than the value of the product to the customer or user. This leads to all sorts of problems. Consider the example where an investor wants to deliver a portfolio of products to their customers. That portfolio consists of a cup of tea, and a cup of coffee. The functionality required is that the project needs to develop the capability of delivering a cup of tea, and a cup of coffee.

To me, the business analyst toolkit is focused on delivering capability (or functionality) within an organisation. By contract, the product management toolkit focuses on satisfying the needs of the customer. The product owner needs both of these tool kits in their product owner team in order to be successful.

Slicing Functionality

The first problem when we slice functionality is that the definition of the product to satisfy the needs of the customer is subjective. I worked on a project where we had to deliver a “cup of coffee”. Before we delivered the product, we had a long series of  reviews with the chief product owner where they gave feedback. One chief product owner would say “Too bitter!”, and the other would say “Not bitter enough”. The project had delivered a cup of coffee but the acceptance criteria were not clear enough. This is a failure state that product owners often find themselves in.

The other problem is the variants. The scope said that we needed to deliver a cup of coffee but all of a sudden, we discovered lots of variants. We need Cappuccinos, Americanos, Lattes and Macchiatos. We need coffee delivered in paper cup, and china cups, and tall glasses. We need full fat milk, semi skilled milk, skimmed milk, rice milk, lactose free milk, and soya milk. Whenever we speak to the investor (sponsor in Corporate speak to indicate they are investing someone else’s money), they insist we have to include whatever niche variant because they know someone who drinks it, or might want to drink it. “Bob in marketing drinks double double decaf upside down with a twist of vanilla in a bring your own sports cup with straw.”

Whenever you try to reduce the scope, it increases as you make the investor aware of a gap in their original thinking. Whenever we think of a variant, our investor thinks of someone who might need it. Our “scope” balloons out of control and we end up with massive releases.

Slicing by Value

Slicing by value makes it much simpler to create small stories. Instead of functionality, we aim to improve a business metric by satisfying the need of a customer segment (or persona). For example, our organisation has three top level metrics, “Number of Customers”, “Activity”, and “Revenue”. Based on the current portfolio of metrics values, the chief product owner agrees with the product owner which metric it would be best to invest in. The product owner team then identifies those customer segments and needs that would most likely deliver on the metric. Alternatively the product owner team might identify the best investment to make based on their understanding of the customer segments and their needs, and then agree the metric with the chief product owner.

Now the product owner team can be much more focused on the delivery of the cup of coffee. We are looking to “increase revenue by focusing on commuters who have a need for habit and ritual in their commute”. We can also agree measurable acceptance criteria, say 50% of twenty commuters tasted rate the coffee ten out of ten. Now we have our design brief (Metric, Customer Segment, Need), we can create a set of designs. Each design is a hypothesis that might satisfy our design brief. After initial team and user (in)validation (See Melissa Perri’s Bad Idea Terminator), each design becomes an Epic that feeds into the Agile Development Process. An Epic might be needed to create the output of the system that is used in User (In)validation.

Small Stories

So if you have a problem with “stories” that are mammoth beast, try slicing them by value instead of functionality.

Use the “Design Brief” format of

  • In order to move <metric>
  • As a <customer segment>
  • I need <job to be done>

And the Epic Format

  • In order to move <metric>
  • As a <customer segment>
  • I need <job to be done>
  • With the hypothesis that <“Functionality”> will satisfy the need

This is so much better than the format


  • As a <customer segment>
  • I need <“Functionality”>
  • So that <“Don’t know what to write here, so I’ll ignore this bit”>



Three top tips for using Given When Then.

Behaviour Driven Development is like Jazz. It is a constantly evolving approach to communication between all those involved in the specification and delivery of value in software development. Aslak, the creator of Cucumber, has cut a vinyl called “Kind of Green“. As the co-creator of the Given-When-Then format, this is an MP3 I knocked together in my bedroom. Its not quite my vinyl, more of a sample.

As a coach I spend most of my time with Product Owner Teams and Managers in large enterprises with established products, normally with millions of existing customers. The product team who create the stories, or the “Three Amigos” consists of the Product Owner (Product Owner, Chief Product Owner, Product Director), A developer, A testers,…. and A business analyst, architects (business, technical, and security), UX Researchers, UX Designers, System Designers (Lean Services representing the call centre), Data Analysts, and the occasional tastapod. I find the tester is normally best placed to facilitate the “Three Amigos” session.

Top Tip 1: Start with the value

Most product investments start with a “Tea Bag”, a partially formed idea. No one ever wants a tea bag. The conversation goes like this:

  • Someone: “I want want a tea bag!”
  • Product Owner: “Why?
  • Someone: “Because I want a cup of tea”
  • Product Owner: “Why?”
  • Someone: “Because I’m thirsty and cold and its a habit OK?”
  • Product Owner: “What customer segment does this someone represent?”
  • UX Researcher: “The are a commuter, represented by Warren the Worker”
  • Product Owner: “So if we meet this need for the Warrens, we should increase activity in our stores.”
  • Chief Product Owner: “Activity is a good and righteous metric to move given the current state of our metrics.”

The role of the Chief Product Owner is to ensure that the Product Owner is investing in the right metrics. They ensure alignment across the portfolio. They are an optional member of the product owner team.

  • Product Owner: “We will deliver a cup of tea to satisfy the habit and thirst need of Warrens to drive up in-store activity”
  • Lean UX Smarty Pants: “Isn’t that like a whole load of hypotheses?”
  • Cynefin Smarty Pants: “And that is why we will engage in multiple safe to fail experiments, some of which are oblique.”
  • Agile Coach: “That means small Stories and Epics, respond to feedback from real customers.”

The “Find the Value” activity can involve the whole team, however the risk associated with certain aspects is owned by certain roles:

  1. The product owner owns the risk that the investment should be moving an appropriate metric.
  2. The Chief Product Owner owns the risk that the right metric is being moved given the wider organisational metrics.
  3. The UX Researcher / Data Analyst owns the risk that the right customer segment / persona is identified.
  4. The UX Reseacher owns the risk that the customer need identified is done so in appropriate manner.

The output of the “Find the Value” Activity is a design brief.

The design brief consists of:

  1. The metric to be improved.
  2. The customer segment / persona.
  3. The need to be satisfied.

At this point, the chief product owner and product director can check to ensure that the investment is aligned with all the other investments in the portfolio.

Please note that this is quite a long post and I still have not got to the bit where talk about user stories and given when then scenarios. You need to do the “Find the value” step first, otherwise as the Cat from Cheshire would say “If you don’t know where you want to go, any way is just as good.”

Top Tip 2: Work Backwards

Once we have a design brief, the entire team can engage in creating designs to satisfy the brief. The UX designer owns the risk that the design process is righteous and good, even if non designers are involved, especially in the original brainstorming.

The first step moving backwards is to start with the need and take one step backwards to consider the output of the system that will satisfy the need of the customer. (The value to the customer is in the output of the system, the need that it satisfies). When we have a design, we can test it on users to get early feedback.

Consider an app that is a music version of IMDB. An example design brief might be “Increase number of customers (metric) for super users (User Segment / Persona), by meeting their need to know where significant events occured for one of their favourite artists.“. The designs that satisfies that output might look like the following, one of which has been discarded as a result of user testing. The user testing has suggested we are best focus initially on the design on the right.

Screen Shot 2015-03-14 at 11.14.53

There are two considerations when working backwards from the design. The first is the data that needs to be displayed on the output which is covered by information smells (article video). The second is the behaviour of the application, which is normally expressed using the Given-When-Then format.

Note that identification of data is a complicated problem that is the domain of the business analyst and the architects. There is a right, knowable answer that can be verified by research using information smells.

The behaviour of the application needs an understanding of the value to be delivered, the needs of the customer segment, the technical constraints, and the possible failure states, or “quality” paths. As a result, all of the product owner team should be involved at various points.

When specifying the behaviour of the application, the team should start with the output, which means the first thing they should write is the “THEN“. For example:

  • THEN the app displays a map
  • AND the user location
  • AND the location of any “Lady Gaga sites”
  • AND the description of any “Lady Gaga sites”

The product team can then discuss the ways that the user would access the output. What event would cause it to be displayed. There may be several. The ones that are not an initial focus become TODOs that become part of subsequent Epics.

  • WHEN the user is within one mile of an “Lady Gaga site”
  1. TODO: When the user selects map from “Lady Gaga” page

The “Three Amigos” product team can then create the Conditions necessary, or GIVENs.

  • GIVEN the user has selected “Lady Gaga”
  • AND there are “Lady Gaga” sites within a mile
  • AND the user has enabled notifications on their phone
  • AND the user has enabled GPS

Out tester with a black hat is recording the quality paths as TODOs for other Epics:

  1. TODO – Lady Gaga not selected
  2. TODO – Notifications not enabled
  3. TODO – GPS not enabled

The product owner decides the tester can handle 1 and 3 on their own but wants to be involved in 2 as the product owner would like to design an e:mail to tell users what sites they missed.

Which gives us the following first scenario:

  • GIVEN the user has selected “Lady Gaga”
  • AND there are “Lady Gaga” sites within a mile
  • AND the user has enabled notifications on their phone
  • AND the user has enabled GPS
  • WHEN the user is within one mile of an “Lady Gaga site”
  • THEN the app displays a map
  • AND the users location
  • AND the location of any “Lady Gaga sites”
  • AND the description of any “Lady Gaga sites”

The product team then takes each of the GIVENs and turns them into a THEN as they continue to work backwards:

  • THEN the user has selected “Lady Gaga”

The event that triggered that was:

  • WHEN the user selects “Keep me informed of nearby Lady Gaga sites”

In the following conditions

  • GIVEN the user is on the Lady Gaga page
  • AND the user is logged on

Top Tip Three – GIVEN-WHEN-THEN first, stories second.

The product owner team can then slice the Epic into Stories.Starting with the GIVEN-WHEN-THEN, work out which bits of the Epic are the riskiest to complete.

  • GIVEN the user has selected “Lady Gaga”
  • AND there are “Lady Gaga” sites within a mile
  • AND the user has enabled notifications on their phone
  • AND the user has enabled GPS
  • WHEN the user is within one mile of an “Lady Gaga site”
  • THEN the app displays a map
  • AND the users location
  • AND the location of any “Lady Gaga sites”
  • AND the description of any “Lady Gaga sites”

The developer and architect might suggest starting with the map as they have not used the map service before. Or they might suggest the “Lady Gaga sites” because that uses a service on the new untested architecture.

The tester might suggest the location trigger (WHEN) because they are not sure how to test it effectively.

The UX researcher might suggest the location trigger (WHEN) because they are unsure how users will respond and they want to test it with a screen mock up.

The security architect is worried about whether people will enter bogus artist sites to spam friends or enemies.

The team orders the stories with the riskiest first. They do the story that is most likely to fail so that they can get quick feedback.

Note that this different to the way that many people advocate. I am suggesting you create the GIVEN-WHEN-THEN scenarios for the design first and then create the stories whereas most other people advocate creation of the stories and then the GIVEN-WHEN-THEN scenarios.

Bonus Top Tip – Micro-Service Design

Starting with the output makes the design of micro-services easier as well. You start with the last thing to be displayed. To do that, you need look no further than your THENs and combined them with your domain model generated using information smells. The input to the last service becomes the output of the preceding service.


  • THEN the app displays a map
  • AND the users location
  • AND the location of any “Lady Gaga sites”
  • AND the description of any “Lady Gaga sites”


  1. getMap (Location)
  2. getArtistSiteDescription (ArtistSiteLocation)
  3. getArtistSiteLocations (UserArtistList)
  4. getUserArtistList (UserId)
  5. getUserId(Username, Password)

Hopefully working backwards will rid the world of projects where the Login screen is the first thing developed.

When do you book a flight and hotel for a conference?

When do you book a flight and hotel for a conference?

A friend recently booked a flight for a conference six months in advance. Another friend suggested they should wait. This is a great discussion to explore some of the subtleties of real options, and especially the lesser known fourth law:

“The value of options increases with uncertainty.”

The flip side of this law is that options have no time value when there is certainty. The option value collapses to the intrinsic value.

For my friends who are Cynefin fans, it means that options have no time value when you are in the “Obvious” and “Complicated” domains (oops, sorry Dave, I meant quadrants, all five of them). Options play a major role in the “Complex” and “Chaos” quadrants, which is no surprise as Dave Snowden used Real Options to help create the Cynefin Framework well before Olav and I started talking about them.

But here is the real kicker. Dave tells us that Cynefin is a multi ontological sense making framework. What does that mean in English? It means that Cynefin considers the Ontology, Phenomenology and Epistemology of a situation, or “How it is”, “How we perceive it” and “How we act upon it”. These three are all very different, but do impact upon each other.

Olav and I have given many talks on Real Options. The focus of much of those talks is about the Phenomenology of Real Options and Commitments. The third law of Real Options “Never commit early unless you know why” is about the Epistemology of Real Options or “How we act”. It says never to commit unless you have enough certainty or in other words, never commit unless the time value of the option is zero due to certainty. This statement weakens the phenomenology of the commitment by putting the emphasis on certainty before the commitment. The ontology is that there is never certainty, certainly not until the end of the universe. There is always a itsy witsy small chance. Uncertainty hides in that 0.001% chance. That itsy witsy small place that is home to the black swan. That itsy witsy small place according to the phenomenology which is actually rather large according to the ontology. In fact, the phenomenology is the exterior of the tardis whereas the ontology is the inside of the tardis. Two different dimensions, and Real Options tilts us towards the ontology.

So what does this have to do with booking flights and a hotel for a conference?

Lets handle the easy one first, the hotel booking. Most hotels give us a free option. They give us the option to stay in the hotel at a fixed price. The option expires and becomes a (financial) commitment on the day of the stay. Therefore as soon as we think we might go to a conference like Agile20xx where the hotel sells out, it is worth taking up that free option. If closer to the conference we decide not to use the hotel reservation, we simply cancel it, or even “sell” it (probably for kudos as currency rather than cash). In other words, hotels give away free options which is something that is trying to monetize by allowing hotel to offer cheaper rooms if the guest pays in advance and makes a commitment.

Airlines do not give away free options. A more subtle strategy is needed. In addition, airlines use utility based option pricing models for their flights. As the flight date approaches the price goes up, especially as the flight starts to sell out. As a result, flights are often much cheaper if purchased well in advance.

For a big conference like Agile20xx that is often in a location that is poorly served by international flights, the routes are often illiquid. (Illiquid means there are few options). Illiquid routes often spike in cost. As such, as soon as I think I’m pretty sure I’ll go to a conference like this, I buy a flight. This is an option to attend. From experience, leaving the flight to Agile2006 too late resulted in a flight that cost £1400 whereas the flight the following year cost about £350. I had bought the option to attend for £350. The point I buy the option is the point at which I’m pretty sure I will attend.

Another key point about Agile20xx is that the conference pays a fixed fee rather than cover travel expenses. Most conferences pay for expenses, and possibly a fee. That means that the risk of flight costs going up is borne by the conference rather than the speaker. So the best option is to attend the conference as a speaker so that the cost of flight risk is managed for you. Either that or get a sense of how much flights cost change closer to the time of travel. I generally book a month before travel but have been caught out once or twice.

Sometimes we need to constrain a situation in order to make things “obvious”. Anyone who has to work with an ex-partner to coordinate holidays for children, or provide certainty of dates for work colleagues, or clients attending a training course will recognize this situation. In other words, sometimes we need to give up our own options and the ability to respond to uncertainty in order to make things easier for others. This in turn helps us.

So coming back to “When do I book a flight and hotel?”

  1. Book the hotel as soon as you think you will need it. You can always switch to a cheaper up front cost on closer to the time.
  2. Either book the flight as an option well in advance, or book the flight when you have constrained your options enough that the uncertainty is removed for other.

This post was inspired by a great conversation on Twitter between Gitte, Yves and Samantha.

Seven FAQs about Agile Frameworks

My thanks to Martin Burns, Erik Gibson and David Morris for great challenges and questions about the Framework:

  1. Is the Framework a Trojan Horse? – No. Quite the opposite. The Framework makes it easy for control functions to clearly identify whether an investment is operating within the risk limits. The framework consists of risk management constraints that also act as enabling constraints that encourage improvement. Once control functions become familiar with the framework, they will start to appreciate that their existing SDLC style stage gate processes are not as effective.
  2. Does the Framework Support Incremental Implementation? – Yes. Organisations should start by getting good at the team level. The framework specifies the limits that team level investments should operate within in order to be effectively risk managed. If an organisation choose to go full in and create a multi-team program level “Flagship” agile project, the Framework will constrain it so that it does not become a rogue Water-Scrum-Fall or Scrum-Fail project. The control framework can identify those risk factors that are out of limits and as such require more careful monitoring.
  3. Does an investment need to to fully comply with the Framework before it can be considered safe? The framework acknowledges that organisations will need to go on a journey. The framework introduces limits, and the processes for monitoring the organisations journey towards compliance. e.g. Each investment needs a weighted lead time of a month or less, unless all of the executives have committed to be within the limit within an agreed timescale AND CAN DEMONSTRATE PROGRESS TOWARDS THE GOAL. Simply saying you’ll do it is not enough, you need to demonstrate you are on the journey and take the limit seriously. As Martin puts it, they just need to deliver.
  4. Does the framework compete with Safe. DAD and LESS? Quite the opposite. The framework compliments the scaled Agile frameworks. Safe, DAD and LESS can be plugged into the framework. Organisations have a clear idea about which controls am approach covers and what else they need, like Cynefin, Real Options and Beyond Budgeting.
  5. Is the Framework commercially available?  Not yet. If anything, the framework will be available as an open source framework. That way, it can evolve to identify new controls and limits that might be needed to cater for contexts that were not originally considered. Associated with the framework would be a list of methods and tools with associated strengths and weaknesses describing the context where each method and tool has a sweet spot, and where each may create risk for the organisation. Expect a wikipedia style process with approapriate editing controls.
  6. Does an organisation need to reach a certain level of maturity before they can adopt the framework? The framework is a good game in “Reality is Broken” terms. An organisation can adopt it at a very low level of maturity and have transparency that it has a lot of risks that are not managed effectively. As the organisation matures, it can use the framework to demonstrate progress. Rather than maturity levels, the framework can be used to build a backlog of targeted improvements. The backlog could be ordered using a WSJF style process where the value is the amount of risk reduction.
  7. Does the framework require a big up front implementation of a process. Quite the opposite. The framework shows the risk hot spots that the organisation needs to address. The organisation can incrementally adopt methods and tools to address the risks and then choose the level of control that is necessary according to the context of the investment. The same organisation might have different levels of control depending on the context. e.g. A mission critical investment might be required to operate within more limits than a small innovative investment. The framework creates transparency into risk and helps the organisation choose their preferred adoption path for a scaled agile framework. It helps people who are not experts understand how to pick and choose the best elements from each approach. Philosophically, its similar to Alistair Cockburn’s Crystal Methodology for organisations. Risk limits for how an organisation creates transparency around the improvement backlog are covered in he “Deliver Value” and “Governance” control.
  8. Will certification be available? If people want to pay me money, I will happily give them a certificate that they can sign saying that they are “Aware of” and “Value” the framework. Ideal for “control” professionals.