Flow in different forms is crucial to speed up your delivery

Do you recognise the struggle of transforming your organisation? Where to start and what the aspects are that really make sense if you want to transform it into a high performing organisation? In this series of posts I want to address 5 principles that must be part of your organisational foundation and way of thinking. These are 5 crucial principles I’ve learned in the past few years from organisations that feel the urge to transform and are willing to make some sacrifices.

5 Crucial Principles that create the foundation of your high performing organisation:

  1. Flow in different forms is crucial to speed up your delivery
  2. How feedback loops will radically change your improvement cycle
  3. Strongly focus on the improvement of secondary processes
  4. Autonomy of teams cannot be given, it must be created
  5. The simplification of your products and processes will lead to faster value

Every post in this series will address concrete examples to find the principle in your organisation, an explanation why this principle matters during a transformation and finally, some practical suggestions to start today.

Flow in many shapes and different forms is crucial to speed up your delivery

You may have heard of flow before, flow as a state of mind, a magazine or a diagram to represent a certain process. There is more. If you break flow down in the view of organisational transformation, flow is about the efficiency of moving and processing units in a steady stream. A unit is a broad concept and applicable in many aspects of your organisation.

Do you want to increase the productivity in your organisation? You aim to deliver more value, for example by creating more and better IT systems? Not only must your IT department focus on more delivery. It is the total organisation that enables the value creation. You have probably improved the IT teams. They are likely already running liked high performing assembly lines, but if nothing is coming in very structured, they are doomed to fail. If your customer has a request, but it takes months before you can answer his questions, the flow in your organisation is most probably blocked.

Production via your production teams is one of the foundations of your organisation and a way to earn money. This department produces value for your customers as soon and as fast as possible. Flow is therefore crucial and bottlenecks in the production lines need to be solved. To get a better understanding of how flow is expressed in your organisation, let’s take a closer look to see some examples.

Some examples

discoverFlow of code to production

How long does it take to push code production? Are you aware of how the process is designed from the developer’s laptop all the way to production? This is one of the basic flows in your organisation that needs to be optimised. If the developers can push code to production quickly in minutes to an hour instead of days up to weeks, a lot of bottlenecks are already solved in this improved flow.

The second aspect of code to production is looking into your code. Ask a developer how many parallel branches there are. How long do they already exist, and what is their lifetime? Both the amount and the lifetime say something about focus, flow and dependencies. In this case less is more. If you have a few branches that are open for a short period of time, your code creation will start to flow.

Flow of activities on the team boards

A great indicator of flow in your teams is to go to the team boards. Observe them early in the morning when nobody is in. And go to the teams when they have a session at their team board. What do you see? How many items are they doing compared to the number of team members? And what is the lifetime of the actions in Doing? Again, for both, less is more. Only a few tasks in Doing means a focus for the engineers. If they can solve stuff in a day, they are able to create faster value. Bottlenecks around them are already solved in this case.

Flow of stories on the backlog

You can imagine that it is hard to achieve flow if you first produce an Opel with your assembly line and second a Toyota car. A lot of changeover time will be spent to reconfigure the assembly line.

If you have a close look at your list with upcoming work items (product backlog) how many various categories are there? How many applications needs to be worked on at the same time? If you can reduce this by, for example, sorting them in a different order or removing items, the changeover time will be reduced dramatically. People can work time after time on the same type of issues. This will enable flow in your whole organisation.

This is why flow is crucial

ideaFlow enables fast delivery to your customers

First of all, if you have flow at all levels in your organisation you can respond quickly to the customer’s needs and deliver what is needed. You can simply add new insurance products, change the design of your app to increase conversation ratios, and adapt to governmental requirements, and respond to upcoming payment standards. How long does it take before you have processed a customer’s wish?

Focus on flow solves bottlenecks in your organisation

If you’re focused on flow at all levels, you’ll be amazed how your organisation will start performing. Assume the teams are your production engines. How many bottlenecks do they face? How difficult is it to go to production, to make use of an acceptance environment, to pass the security gates, to get a new laptop, to get the right business roles to start working, just to mention a few? With a focus on solving bottlenecks first, you’ll challenge the processing time tremendously.

With flow it’s more fun shipping time after time

It’s more fun to have a high-speed value delivery in place. Imagine from the customer’s perspective, a wish is realised in days instead of months. Imagine a developer is happy because code is pushed to production in seconds with just one single click. Imagine your strategic stakeholder who was always blaming IT because it takes so long. Now, his roadmap is realised quarter by quarter. Smiling people are all around the place as a result of flow in your organisation.

How to start with the creation of flow

footsteps_icon_smallFirst off all, my suggestions are not a recipe to be executed in the exact same order. It’s what I’ve discovered and can increase the flow in your organisation. Some suggestions sound silly, are not as concrete as you might expect, or are too obvious, so please try them and discover what’s working and what’s not.

Support the teams with continuous delivery

To speed up the delivery of IT teams, high performing, robust and scalable continuous delivery pipelines with proper pipeline orchestration is the number one flow enabler for the engineers. Automating whatever is possible will reduce changeover time, handover moments, waiting time and many other appearances of waste.

Remove the change management process

Waiting for days or even hours for manual approvals? Immediately stop doing this. Some suggestions: simplify your landscape until alignment is no longer needed, ask yourself the question if the checks are really needed. What’s left: automate the checks and improve your monitoring to have early detection in place. Your developer shouldn’t be aware of a change management process. With continuous delivery is in place, it must be like a click on a button.

Start in the middle and expand upwards and downwards

Where should you start with the focus on flow? Start on the team boards. These boards perfectly demonstrate the flow in your organisation. The amount and the time items are on the board reflect your organisational behaviour. The improvements will be found down the stream in your continuous delivery pipelines and the way of working if it comes to single piece flow and “work in progress” limits.

Focus upwards to your backlog, but even further to the list with customer features and strategy plans. A focus on flow and preferably single piece flow, all the way to your strategy papers will enable your whole organisation to flow.

Start discovering and challenge the processing time

You don’t know upfront which part of the process is the slowest or what activities hold the biggest bottlenecks. Therefore, continuous improvement is crucial. However, also for continuous improvement you need focus. If you focus on processing time and try to half the processing time every quarter, you will definitely solve bottleneck after bottleneck.

One priority list from senior management

It sounds very plausible since we have so much to do as an organisation, that we have multiple priority 1 issues to work on. Our strategic program consists of several high priority streams and we must realise all of them together. As soon as multiple priorities at the same time have an impact on one team you must revise your priority setting. Teams with more than 1 priority are constantly switching between tasks, depending on others and feeling the pressure to deliver (overburden). Choose one priority and ask the team to finish this first.

Real flow in your organisation starts on your strategic roadmap and priority setting.

Flow and the relation to other aspects.

Flow is not something in of itself. It is entangled in many other aspects of your organisation. To transform your organisation into a high performing organisation these are topics strongly related to flow and will speed up your value delivery:

  • More focus on solving complexity instead of managing complexity
  • Reducing code and architecture complexity will remove waste
  • Measure reality and avoid spreadsheet management
  • Focus with your improvement plans by solving bottlenecks one by one.

Finally, feedback loops are enormously valuable to discover bottlenecks in your organisation. In the next post, I’ll describe how feedback loops are the second principle in the foundation of your high performing organisation.

whatsapp meWil je een WhatsApp bericht ontvangen bij een nieuwe blog?
Stuur dan even een berichtje naar +31645112490

Systemisch Transitiemanagement: een klein tikje, een groot effect

Zal ik even met de deur in huis vallen? Ik heb NIETS met trainingen voor een certificaat, geef niet snel hoger dan een 7 (there is always room for improvement) en neem liever niet deel aan in-je-ziel-roer-trainingen. En dan toch…

Afgelopen week heb ik de training Systemisch Transitiemanagement van Plan-B afgerond. Wat ben ik trots op dit certificaat, blij met de training en zeker de trainers (een dikke 8). Ik heb enorm veel geleerd van mezelf, mijn invloed, en mijn eigen rol in een organisatie en transitie. In deze post een aantal van de vele zaken die voor mij de kern vormen.

Je had er bij moeten zijn

Laat ik daar maar mee beginnen, je had er bij moeten zijn om het echt te voelen, te zien en te ervaren. De theorie is zo eenvoudig gemaakt dat soms het gevoel me bekroop, is dit het dan? Is het soms zo simpel? Als je ervaart hoe complex soms patronen in relaties zijn en bepaalt gedrag een organisatie beïnvloed, dan snap je dat het juist eenvoudige interventies zijn die er toe doen.

Dit maakt het nu juist leuk, als het probleem complex is moet de interventie wel simpel zijn.

De kenmerken die me zo aanspreken

STM gaat er van uit dat gezinnen, teams en organisaties zich gedragen als een systeem of als je dat mooier vindt een organisme. Een organisme dat zich prima voelt bij de status quo. Alles wat deze status quo probeert te verstoren kan uit het systeem worden gewerkt.

De training richt zich op de onderstroom van een organisme in transitie. Deze onderstroom is in veel organisaties onderschat. We veranderen wel een organogram, geven een bewustwordingstraining en dan vinden we het als snel genoeg. We zijn nu veranderd.

Een systeem wijzigen heeft veel meer aandacht nodig in het wijzigen van de onderstroom. Dat wat zich onder water afspeelt. Wat als de ordening wordt verstoord? Wat als nieuwe mensen zich moeten aansluiten en andere juist afscheid nemen? Wat gebeurt er bijvoorbeeld als een aantal spelers altijd maar moeten geven en nooit iets ontvangen? Dit zijn drie aandachtsgebieden die soms nauwelijks opvallen en tegelijkertijd om aandacht schreeuwen om een klein tikje te ontvangen.

Een interventie is als een tikje, ogenschijnlijk nauwelijks impact en uiteindelijk grote gevolgen

Vraag niet hoe het kan, profiteer ervan. 😉

Wat kun jij doen?

Voor mij was de training enorm waardevol. Het heeft mijn gereedschapskist enorm verrijkt. Mijn suggestie voor elke manager, coach, product owner, facilitator of wie dan ook, verdiep je in dit gedachtegoed.

Je kunt natuurlijk zelf de training volgen bij Plan-B of alvast het boek Systemisch Transitiemanagement aanschaffen.

stm_2017

De emotie op laten lopen om de transitie te bevorderen en andersom

Een ander deel van de training was gericht op emoties. Het is soms goed om emoties eerst eens wat op te laten lopen om urgentie te creëren. Urgentie is nodig om de echte transitie in gang te zetten. Zonder urgentie geen verandering.
Continue reading

Workshop Agile Leadership, concreet gemaakt in 3 principes

Met een groep van ruim twintig managers nadenken over Agile Leadership is echt leuk. Als je dan ook nog eens een introductie op het thema mag geven is dat helemaal de hoofdprijs. Wat is nu eigenlijk Agile Leadership? En hoe maak je zo een (hype) begrip nu concreet in de praktijk? Wat moet je doen als je aan de vooravond van een transformatie staat en jij je gedrag wilt veranderen? Wat ga je nu daadwerkelijk anders doen als je met je team van A naar B wilt gaan? Dit zijn een zomaar wat vragen die we in de workshop hebben besproken.

In de workshop heb ik aan de hand van drie (Agile/Lean) principes voorbeelden gegeven over hoe je als manager/leider je gedrag kunt veranderen. Of hoe jij de omgeving kunt veranderen waardoor de transitie naar B in gang wordt gezet. Jou gedrag en het gedrag van de teams bepalen uiteindelijk of je de transitie kunt maken.

De drie principes:
  • Het laten groeien van de autonomie van de teams
  • Het creëren van flow in je organisatie
  • Van sturen naar leiden, van (fake) control naar inzicht

Het laten groeien van de autonomie van de teams

Om teams te laten groeien in autonomie kun je allerlei strategische plannen maken die ver tot in de toekomst reiken. Een andere optie is klein te beginnen en dag in dag uit te verbeteren naar meer autonomie. Niet dat autonomie het doel kan zijn maar wel dat het veel positieve bijkomende effecten heeft. Vergeef me als de statements kort (en) door de bocht zijn.
autonomous-teams

Wat kun je doen:

  • Een belangrijke focus van de manager is het oplossen van de beperkingen/remmingen rondom de teams zoals
    • verkorten en waar mogelijk automatiseren van change management processen
    • risico management simplificeren en waar mogelijk automatiseren
  • Bij de start van een transformatie van een IT organisatie zijn er cruciale metrieken die er toe doen.
    • De frequentie van het aantal releases naar productie deze moet om hoog gaan, en tegelijkertijd
    • Het aantal gemiddeld aantal open staande incidenten naar beneden
  • Veel andere metrieken doen er in het begin niet zo toe:
    • Je kunt ze niet geautomatiseerd meten of
    • Het mondt uit in spreadsheet management (een valkuil voor velen) of
    • Je volwassenheid is nog zo laag dat het er niet of nauwelijks toe doet als je zeer gedetailleerd gaat meten.
  • Het vliegwiel van continue verbeteren op gang krijgen door de coaching van het team en individu is cruciaal
  • Reduceer afhankelijken met andere teams door je technologie (zowel infra als applicaties) zwaar te reduceren
  • Leg meer en meer beslissingsbevoegdheid in je teams (vakantieplanning, reisjes, training, opschalen van je infra)

Het creëren van Flow in je organisatie

Flow is ook zo een mooi principe waar je als leider in een organisatie grote invloed op kunt hebben. Flow heb je in allerlei vormen in de organisatie. Het op gang brengen van flow is niet altijd eenvoudig en tegelijk cruciaal.
flow

Door er voor te gaan zorgen dat je van idee steeds sneller je werkende software bij de klant te krijgen kun je sneller je hypotheses toetsen. Alleen door deze snelle feedback kun je als organisatie leren en gericht beter worden.

Hier een aantal suggesties:
  • Flow ontstaat door alles maar dan ook alles via de backlogs naar de teams te laten gaan, ook het werk dat vanuit de hiërarchische IT of risk lijn komt.
  • Alleen door feedback loops terug de organisatie in richting the hiërarchische IT lijn of HR en Risk afdelingen kun je voorspelbaar worden en zijsturing maand na maand afbouwen.
  • Er ontstaat pas flow in de backlog als er een duidelijke roadmap en portfolio aanwezig is (bij voorkeur visueel)
  • Er ontstaat pas flow in de roadmap als er een duidelijk doel aanwezig is vanuit het bedrijf en product.
  • Als IT manager mee werken aan de roadmap en de cadans van kwartaal/feature planningen verbeter je de flow in de teams
  • Het streven naar single piece flow in de teams, backlog en portfolio zorgt ervoor dat je netto meer gaat leveren en veel sneller in de markt kunt toetsen of je hypotheses waar zijn.

Van sturen naar leiden, van (fake) control naar inzicht

Tenslotte hebben we het uitgebreid gehad over hoe je rol als manager langzaam over gaat in die van leider, coach en ondernemer.

Het bijzondere effect is dat je door technologie en visualisatie van allerlei metrieken veel meer inzicht krijgt in wat er speelt. Waar je vroeger slechts schijnbare controle had door alle voortgangsrapporten kun je nu op elk gewenst moment inzicht krijgen. Hier ten slotte wat voorbeelden.
  • Grip op je openstaande risico’s? Maak het visueel in je Obeya
  • Inzicht in de voortgang op de korte termijn? Ga naar de borden van de teams
  • Inzicht op de lange termijn? Voer het gesprek bij je delivery roadmaps in de Obeya
  • Weten of je transitie niet stagneert? Kijk waar je ben in je Explorer Maps.
  • De status van je applicaties in productie? Kijk naar je monitoring.
Ik kan me voorstellen dat je bij sommige items van de opsommingen wel wat meer achtergrond wilt. Elk statement zou dan een post apart zijn. En dat is in deze post nog niet gebeurt. Het doel was slechts overzicht.

Wil jij ook een workshop op maat?

Wil jij ook een workshop over de hierboven genoemde onderwerpen of andere zaken die langs komen op mijn blog? Ik doe dat graag, informeer naar de mogelijkheden door te kijken op de pagina “Diensten” of stuur een mail naar andreas@ideetotit.nl.

Een fantastische Agile Coach Lab Meetup vol met coachingstechnieken

Wat een fantastische Coach Lab was dat. Het was een optelsom van leuke dingen. Een mooie locatie, de zon, inspirerende mensen, een nieuw netwerk en een geweldig onderwerp vormden de ingrediënten van een cocktail vol inspiratie.

Het was alweer even geleden dat ik een meetup had bezocht maar deze donderdagavond 11 mei was het dubbel en dwars waard. Met zo’n 20 (aspirant) coaches hebben we een avond kunnen oefenen met elkaar. Ik deel graag 4 lessen van deze Coach Lab die mij weer even op scherp zetten.

coachlab

Les 1: Rollenspellen zijn brilliant

Wat is het heerlijk om je even te laten gaan. Even die gefrustreerde manager te spelen die je altijd verstopt. Die Dev Engineer die het liefste maar wil programmeren of thuis wil werken. Een team dat geen team is en een coach die zelf harder werkt dan het object van de coaching. Een rollenspel is brilliant.

Continue reading

4 Fascinerende aspecten van continue verbeteren

Continue verbeteren is iets fascinerends; een soms moeilijke reis naar het onbekende. Al streef je doelen na, de realiteit van elke dag kan je route sterk beïnvloeden. De afgelopen 3 jaar is bij mij de bewustwording voor continue verbeteren gegroeid. En hoe meer je het probeert toe te passen hoe meer je ontdekt dat het zo lastig is om het uit te voeren. Vier fascinerende aspecten springen er voor mij bovenuit:

  1. Je weet niet waar je heen gaat: Improvement Kata kan je helpen
  2. Het mag je wat kosten: Kaizen als ultiem begrip
  3. Het is zo moeilijk: discipline is het enige wat je kan redden
  4. Het is zweven tussen optimisme en realisme: Stockdale Paradox

1. Je weet niet waar je heen gaat: Improvement Kata kan je helpen

Hoeveel plannen je ook maakt en hoe duidelijk je de stip op de horizon probeert te schetsen, een ding weet je zeker, zoals je hem van te voren bepaalt gaat hij zeker niet worden. Een paar jaar geleden schreven we nog dikke verbeterplannen. Vandaag de dag doen we het radicaal anders.We sturen en plannen onze verbeteringen op basis van Explorer Maps. Deze zijn een-op-een afgeleid van de Improvement Kata.

Keynote Open Techday 2017

21 April had ik de eer om een keynote presentatie te mogen geven op de Open Techday. Een nieuwe conferentie gericht op het delen van kennis en informatie rondom het onderwerp Open. Open Source -data -organizations -future zijn zomaar wat topics die deze dag centraal stonden. Met meer dan 550 bezoekers een top event.

De moraal van mijn verhaal op deze dag “You can have great technology available but if you can’t change the behaviour of your organisation it’s worthless.” In de keynote kwamen een aantal lessen langs van organisatie transformatie. Lessen die we hebben geleerd in de journey van de afgelopen jaren.

Hieronder de slides, wat statements uit de speakers notes en wat reacties van een aantal bezoekers.

Hoe je van een “acceptance phase” een “acceptance feest” kunt maken

Of ik het wilde horen of dat ik verkeerd stond afgesteld weet ik niet, een engineer had het onlangs over een acceptance feest. Nadat ik het verifieerde, bleek dat hij het over een “acceptance phase” had. Een periode na de sprint van de DevOps teams waar de acceptant aan de slag gaat. In die phase gebeurt er veel maar het wordt nooit een feestje. Waar gaat het mis?

Waarom die fase alle feestvreugde weghaalt

Hier een aantal redenen waarom het volledig mis gaat bij een acceptatie (test) fase van de software nadat je al klaar bent.
  • De acceptanten beginnen pas na te denken over wat ze willen nadat ze iets krijgen. Het gevolg is dat eindeloze aanpassingen nodig zijn in de volgende sprint.
  • Mensen die bij de demo de acceptatie hebben uitgevoerd, worden overschreeuwt door de mensen die werkelijk accepteren. Het mandaat en pikorde blijken totaal anders te lopen.
  • In de magere jaren waarin software van mindere kwaliteit werd opgeleverd, was een acceptatie test van dagen, zo niet weken, broodnodig om goede software naar productie te krijgen. Dit patroon is nog niet doorbroken.
  • Er is geen verbinding tussen wat in de sprint is gebeurd en wat daarna gebeurt tijdens de acceptatie testen. Dit heeft enorm veel dubbel werk tot gevolg.
  • Er ontbreken duidelijke acceptatie criteria waar naar toe gewerkt kan worden. Het programmeren wordt daarmee bijna een “wild guess”.

Een dubbele domper

Je snapt wel hoeveel frustratie dit bij de engineers oplevert. Deze frustratie is echter geheel wederzijds.
Opmerkingen van de acceptant zoals de volgende zullen met grote regelmaat zijn uitgesproken.
  • Ze snappen me toch niet,
  • krijg ik weer niet wat ik echt nodig heb,
  • waarom heeft dit zolang moeten duren,
  • hoe kan het toch dat ik elke keer weer moet aangeven wat ik echt wil hebben,
  • waarschijnlijk zullen er toch wel weer fouten inzitten.

Suggesties ter verbetering om er een feestje van te maken

Het is eigenlijk vrij eenvoudig om er een acceptatie feest van te maken. Daarbij moet je de fase achteraf wel durven los te laten. Hier een paar kleine suggesties om er een feestje van te maken.
  • Werk aan een wederzijdse overtuiging en drive om het daadwerkelijk anders en beter te gaan doen. Dit is van groot belang om een mini transformatie als deze door te maken.
  • Plaats de acceptant in het team zodat hij kan werken aan de acceptatie criteria voor de user stories in de volgende sprint.
  • Gebruik een testing tool als Concordion of een framework als Cucumber om de Acceptance Test Driven Development mogelijk te maken.
  • Doe de acceptatie tijdens de demo aan het einde van de sprint en daarmee en daarna gewoon door productie. De kwaliteit is goed en afwijkingen detecteer je met monitoring.
  • Creëer een continue groter wordende set aan automatische regressietesten op alle niveaus, van unit testen tot en met GUI testen.

Dag manager, welkom parttime leider

Zijn managers nog nodig als je bouwt aan autonome teams die veel keuzes zelf nemen? Moet er nog veel worden gemanaged als de teams het zelf kunnen?

In een organisatie transformatie waarbij je echt wilt verbeteren neemt het aantal managers af en het aantal leiders toe. Als ik zeg leiders heb ik het niet over een semantische vervanging van het woord managers. De rol verandert en de vraag is of jij een leider wordt.

parttime leiders

Eerst twee concrete voorbeelden om te ontdekken waarom managers afnemen en de leiders toenemen.

Managen van out of control naar leiden in control

Als ik terug denk aan hoe de status van ons “control framework” een jaar of 3 geleden was dan scoorden we in excel netjes groen. Onder de motorkap moest je niet altijd willen kijken. Het hing van geaccepteerde risico’s aan elkaar. Een geaccepteerd risico lost natuurlijk niets op.

Twee jaar geleden vonden we dit niet langer acceptabel en zijn we de dingen echt gaan oplossen. We deden dit met regelmaat nog wel te laat maar de geaccepteerde risico’s werden opgelost.

Hoe meer we de teams verantwoordelijk maakten hoe dieper in de systemen de problemen echt werden opgelost. Vorig jaar scoorden we bijna alles groen en werden risico’s items op tijd gesloten en ook nog eens echt opgelost. We zijn daadwerkelijk veiliger geworden in plaats van dat we de risico’s managen.

Van de positie in control zijn is de volgende stap in control blijven en nog verder verbeteren. Als leider dit vooruitzicht schetsen en doelen duidelijk maken helpt de teams het beter te begrijpen en daar actief aan bij te dragen. Een dagelijkse coördinatie en aansturing is niet langer nodig.

Het managen van het verleden is daarmee niet meer nodig en slechts het schetsen van de toekomst is voldoende om vooruit te gaan.

Managen van voortgangsrapportages voor vandaag naar leiden van de feature planning voor morgen

Hoeveel tijd besteed jij nog aan het opstellen of lezen van voortgangsrapportages om eens wat te noemen? Geloof me dit is echt een verspilling van ieders waardevolle tijd. Je kunt beter werken aan de voorspelbaarheid van je teams op korte en langere termijn. Als je daarnaast ook nog eens vaker het gesprek aan gaat met alle mensen om je heen wat nu werkelijk waarde heeft kun je starten met de feature planning. Continue reading

Transforming an organization at scale, introducing the D.O.T. Model

Many great books are available describing organisational transformation. Each of them has a particular focus from culture, way of working, Continuous Delivery towards waste reduction. Some of them focus on Agile, Scrum, Lean Startup or at the Spotify Model (as some people have named them).

Transforming an organisation at scale is not a simple task. It requires leadership, perseverance and a continual focus on improvement. Not for a month, not even a year, but many years in order to achieve success. Transforming an organisation is like driving on route 66; you have a clear focus but it seems a never-ending road with a lot of dangerous situations throughout the ride.

Many of these changes start with a focus on Scrum, Continuous Delivery or frameworks to slice and prioritise work across multiple teams. The questions I get from time to time are how are all these instruments or hypes are related to each other. What is of value in transforming your organisation? I’ve summarised the most important elements in the D.O.T. Model, a model that gives instruments for Deep Organisational Transformation.

The Deep Organisational Transformation Model

This model does not hold any new instrument but combines existing instruments in a framework of 4 layers, which describe the total scope of an organisation. I’ve learned that if you want to change an organisation, it’s not only the teams that should change. Everyone should bring sacrifices, processes should be simplified and waste must be removed. Only if this is applied from the individual employee all the way to the deep roots of your large company can an organisation can change.


 

Each of the 4 layers require a different focus

The model describes 4 layers:

  • The individual employee
  • The teams with +/- 8 employees
  • The domain with +/- 1200 employees
    The organisation with 1200+ employees.

As you can imagine, each layer has its own focus area. Focusing on simplicity, flow, experimentation and autonomy are some of them. To transform your organisation these are areas you need to constantly focus on. The focus areas are closely related to one another. The items that should be reduced on each level have an enormous impact on the things that you want achieve.

A set of instruments that really matter by transforming your organisation

There are so many buzzwords out there in the Agile world, and also a lot of instruments. If you really want to change your organisation, some of them matter more than others.

On the D.O.T. model, each layer is given 3 of the most important instruments for your transformation. When applying these you’ll discover a slow but steady change of your organisation.

If you need more information about this model, please have a look at the Slideshare above.

Purpose of the D.O.T. model is to give an overview

The purpose of the deck is not to be exhaustively in all the items that are involved in an Agile transformation. It is also not the aim of this blog or the slides to describe a complete transformation. The simple purpose is to give a clear overview of all items that matter during a transformation.

Normally I do publish in Dutch but this time I choose English to reach more people. Other posts will be in Dutch again.

whatsapp meDo you want to receive a WhatsApp message if a new post is published? 
Please send me a message to +31645112490