Scrum, Kanban, ShapeUp, and their like are comfortable prisons that make it easy to be mediocre. They promote an illusion of productivity and a mirage of predictable delivery. Just relax and follow the script, and you’re sure to get results–the same lackadaisical results as everyone else. It’s no accident that one of them is called “SAFe”, because no one ever got fired for following a framework.

Profitable tech organisations don’t look like this: they put productivity before predictability, take risks rather than seek shelter, and fail in interesting and educational ways. There is a difficult but rewarding path to building such an organisation, one that involves challenging conversations, building trust, and jointly designing the “why” and the “how”–but there’s no magic recipe book that will get you there.

I’ll show you practical steps that you and your team can start today to escape the framework prison and build a truly agile tech organisation that’s ready to profit from disruptions like ChatGPT and supply-chain shocks. We’ll discuss case studies drawn from hundreds of my clients who have benefitted from these methods and how you can apply the lessons learnt. Forget your frameworks, jettison Jira–you have nothing to lose but your Gantt charts.

I can’t figure out what scrum master do or why we have that title, agile coaches either

I can’t figure out why we have frameworks

-> their are much better ways to organise our technological work than frameworks

ex: customer, beautiful kanban board, done column with URL’s pointing to demo?!? during two years they have been building software that have never been released

a lot of people are good at doing the right thing

what happens when an org spends two years building a system that no-one has ever seen that is absolutely compliant with every agile principle, what goes wrong?

people do not have the right conversation -> book Agile Conversations by Jeffrey Frederick and Douglas Squirrel

what is easier is to avoid the conversation

what you really need is courage

how does it come that someone writes a book about Scrum, everyone follows what’s written down, but they do not get the results?

a creation story

how does someone create these frameworks?

they have a successful team, they deliver software and users get some benefits out of it

we should write down what we did, so we can repeat this and others can benefit from it, but they forget some important bits

there’s one exception: eXtreme Programming: if you take the original book, that talks a lot about courage, fear and the things that stop people from having the right conversations

but there are tons of teams following scrum, kanban, shape up or safe that do not produce any software

we follow all the rules, we’re doing all the right stuff, but we don’t get the right results, because we never mark to market

mark-to-market: day-to-day value of assets

a lot of financial orgs got in a lot of trouble because they didn’t mark to market: ex. Enron, cryptocurrencies, …

mark-to-market is tremendously valuable to financial circles

but also to technological circles, we do not do enough of that

ex. Gecko board, build beautiful dashboards, they are extremely interested to know whether they software is valuable

-> helped to deliver in one day slices

ex. change colour picker: they wanted to know how valuable this was to their users, but they did not want to wait for all the time it takes

they started with the Painted Door: have a colour picker button, when you click it, nothing happens, placed it on the beta version of Gecko board, people reported bugs because nothing happened. Gecko was happy about that. They phoned up the people that reported bugs to ask what they wanted to do. They received useful feedback. This took no more than a day to do.

next they took a JPEG of a colour picker, when they clicked the button, the picture showed that does nothing, they phoned the users again to understand what they wanted to happen, again they got useful feedback

notice: they haven’t touched the database or the user interface

next step: more effort, put a real colour picker, users could pick a colour but when saving nothing happens

fourth day: they made the colour picker to actually work, then they stored it in the database, …

for many of you this is not a surprising story, yet it does not happen in your day-to-day job, no value is delivered, no marking to market is happening

you know how to do this, your engineers know how to do this, but it does not happen, because it is much safer to follow all the steps

the fear that leads to not doing what you know how to do

=> Alister Cockburn, Elephant Carpaccio

this giant project, that elephant, you want to slice it into pieces so thin you can see through them you can do them, according to Cockburn, in one hour slices

I demand one day, the problem is people do slices of one month or one quarter, those are not carpaccio, these are very thick slices

the other problem is people slice their slices in the wrong direction, horizontally -> unable to demonstrate to users, no value, no marking to market

if you try to mark to market -> slice into one day vertical pieces that we can demonstrate to users

=> the criteria is: release every day

Hardware: that is hard, you may not be able to mark to market every day, it is difficult but doable

Biotech company: we can do it every 3 weeks, but our competitors take a year to get a new feature on the market

Gigantic XML spreadsheet for hedge fund to online software: where to start? we copied the numbers from the spreadsheet to a static HTML page and showed the dashboard the traders were usually looking at in the spreadsheet, the users told us this number is wrong, how should it look like?, then we made it dynamic, it is wrong, how should we fix it? …

trying to adopt things like agile, but the fear gets in the way, in many large organisations it is pernicious, so we will keep doing what we were used to do because that is safe …

-> Normalisation of Deviance

Fear

don’t get rid of fear, it’s a good thing to have it, we can mitigate this

-> coherence busting technique

release every day is a standard thing to do, every engineer knows how to do it, the reason it does not happen is they are afraid or they don’t think they really should do it

fear we might build the wrong thing, we can mitigate this by actually understanding what is needed by running experiments

=> marking to market mitigates that fear because they learn

Questions

How to mitigate the fear of building a feature that does not nothing for the user?

using the Painted Door? yes

contacting the users, coming and talking to them mitigated that

Why investing in releasing every day when you can get the data from user research and other places?

get the data! please mark to market

there are so many organisations that invest in software that is just waste, because nobody wants their product

stop saying we are 60% done, this is our velocity