Feedback loops will radically change your improvement cycle

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. 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.

Feedback loops will radically change your improvement cycle

While we were young kids we learned to give feedback instead of having a fight if we disagreed. We’re grown up and it seems the older we get, the more we forget to apply this crucial principle in our work. We do not so often give feedback to each other or expect feedback from the systems around us.

This is strange because feedback between young kids will teach them to adjust their behaviour and improve in the system they are living.

In our environment outside our work there are many feedback loops built in. They have shaped our behaviour and the things we do. We have learned that a red light means we must stop. We have learned that if we see fire we know the candle or the gas cooker is too hot to grab. We see when our kids are ill or when our partner is angry. Feedback is all around us.

Some concrete examples

discoverSo, let’s go back to work. You are working somewhere in IT, in the business or in a company who already united both. What are the typical feedback patterns you should recognise? What is feedback in a large organisation? And what to do with this?

Feedback loops from your IT systems to your (DevOps) teams

This is an easy one, however, not used by many teams. Monitoring of your IT systems to receive useful information and insights in the behaviour of your system. Most of the time, teams have low level monitoring in place. Memory, CPU and disk space are carefully monitored. This is great because these insights can already help avoid the first wave of incidents which are fatuous.

To radically change your improvement cycle and stability of your systems you must go one step further. Measure the functional usage of an application. Can you monitor during the day and predict if the nightly batch will run successfully? Can you predict the number of users during the day, week or month and scale your systems accordingly? By understanding the impact of the users on the system you can design, develop and improve your systems based on what is really happening.

Feedback loops in the teams

This is probably the most obvious improvement cycle. However, this is hard to implement. Team who take themselves very seriously and want to improve take feedback amongst each other seriously. Stable teams and the confidence to say things out loud are crucial. A retrospective can be a useful instrument to have very frequent organised moments of feedback.

In their daily work, teams can give feedback to each other. When they are reviewing code, have a standup or simply discussing a new strategy. If trust is in place, feedback can flow and a conflict for the better is of great value.

Feedback loops from your backlog into your organisation 

What if you discover that there are too many different items requested at the same time? This will lead to a lot of switching between activities and dramatically drop the energy and productivity. Is there a feedback loop in place in your organisation? For example, every three weeks at the end of a sprint, or every quarter during a planning session?

Providing your stakeholders with the fact that the diversity impacts your productivity is very useful. It creates the opportunity to accelerate if they understand that simplicity and order in the backlog is very powerful.

Feedback loops from teams towards senior management

This is probably the most difficult one. Feedback loops to senior management are not so visible and are difficult to get in place. Years of absence have been preceded by this. Possible fear can hold you to experiments with this. If you want to improve your predictability you should avoid that time after time the management is pushing work into the team on a short notice.

An organisation who is not used to this behaviour must learn this. Teams have a big stake in this. They must give the feedback, push back and ask for more structure.  Management teams must learn to become more predictable too and send their requests much more openly.

The argument that teams in an Agile organisation should be able to switch time after time is nonsense. It says only something of the inability of the management to come up with a stable strategy.

This is why feedback loops are important

ideaThey are the foundation of the continuous improvement cycle.

It is very easy, if you believe continuous improvement is crucial to survive in the long run and adapt in the short run, then you need feedback loops. How would you determine what needs to be improved if a feedback process is not in place? You would be like a headless chicken not knowing where to go. If you have an area in mind, find a feedback loop that helps you to determine where to improve.

They help to visualise the bottlenecks

We have seen the importance of flow in systems. For example, continuous delivery pipeline orchestrators or production monitoring systems visualise where the problems are. You constantly see where the problems occur and what the weakest link is.

If your teams are making use of team boards or if you are working with an Obeya room <link> you see immediately where the bottlenecks are. Cards hanging there for days, or weeks should alarm you. This is crucial feedback, you must go, see and ask why this is happening. Coach teams to identify these bottlenecks and they will start to improve.

They provide insights in the systems behaviour

Can you imagine a team who is performing very well after intense coaching and they fall back as soon as the coaching stops? There is most probably a lot of things going on around these teams that influence them. They are even forced to go back into their old behaviour.

Do you recognise the pattern of management choosing a reorganisation to change their organisation? Go to the shop floor and ask if the work has changed, the collaboration, the way people speak, act or behave. I assume most of the time on the shop floor nothing will change.

Diving into an organisation from this point of view will provide you totally different feedback. Stop coaching teams and ask for feedback first. What is holding them today from tripling their performance? Teach yourself to observe and listen first.

They stimulate conversations based on data

If you have the ability to set up feedback loops based on real data your conversations will change dramatically. Our touchy feelings will be pushed back a little bit and you will move into a scientific approach of continuous improvement.

Most of the time we are clueless whether a certain improvement or decision will improve our organisation.

How to set up feedback loops

footsteps_icon_smallIf you want to improve your organisation in different ways and places you must apply different techniques to receive the crucial feedback. A software system requires different technology compared to a management team. You probably ask yourself the question where to start? My suggestions are to start at one place (keep the principle flow in mind), however, do not go very deep at every topic. Setup feedback loops from many places so you know where to start your improvements based on the ones that add most of the value.

Start using technology to build feedback loops

There is so many great software products available to provide you with valuable feedback. Systems to monitor your software in production is probably the most easy one. You operations engineer can simply install these tools, your developer can write the scripts if needed and there you go. Google around and you’ll discover the latest ones. At this moment the combination of Elastic, Logstash and Kibana (ELK) are used often. Splunk or Stackstate are also perfect capabilities to dive into the performance metrics of your systems.

Start small and simple, monitor your technical behaviour first like usage of CPU and Memory usage. After you have this in place, dive into the amount of concurrent users, parallel processes and finally, the level of business processes.

Go and see

To identify bottlenecks in teams the visual boards of teams can often tell you so much.

Let’s do a little exercise.

Imagine you are standing in front of a huge whiteboard with many post-its. You remember the last quarterly planning wherein all of you have decided to work on strategic change. The green post-its represent stories and features related to the strategic change. The yellow ones are for the legacy systems and the red ones are incidents that pop up.

You see the board, and observe chaos in the first place. Many items say “work in progress” at the same time, many different topics at the same time and last but not least, many items are marked with a sign saying “waiting for others.” You rarely see any green post-its, which represented the strategic change.

Alarms start ringing and you feel an upcoming panic attack, HELP! This is not going into the right direction.

The good news is you can see and feel it. You see the outcome of a certain process. Now is the time for the next step. The main question is what is causing this apparent chaos?

Ask why and listen

First of all, do not judge too early. Observing something does not mean you understand what is going on. Start asking questions and listen carefully. It’s almost like doing a root cause analysis. The first answer isn’t the real answer. Dive deeper, listen carefully what they say and ask “why” again. Is the first answer we have a capacity problem? Do not extend the amount of people, but identify the real reason. Most likely with a little order in the backlog, or with a reduction of technical dependencies, you can double the speed easily.

If you’re able to listen carefully you can identify what’s under the surface. By using this feedback you’re able to do an improvement that goes way deeper.

Create formal rhythms and structures to it make improvement easy

Continuous improvement is crucial to transform your organisation. To stimulate the continuous improvement cycle, feedback between people is an elementary principle. Trust, collaboration and transparency between people must grow time over time. Teams who can setup formal structures to share this feedback are teams who will become powerful teams.

If you apply scrum or are working in a stable devops team you will most likely execute a retrospective every 2 or 3 weeks. A fixed moment where you reflect on the way of working, but also on personal qualities and behaviour, gives valuable input for improvements.

Since a management team is also just a team, I can highly recommend to set up these structured rhythms for them also. Support with explorer maps (read more) will be very powerful.

Feedback loops and the relation to other aspects.

Setting up feedback loops or having benefits from them is something that is part of a bigger picture. Only creating feedback loops is not enough. These are some thoughts that are strongly related to them:

  • Spreadsheet filled manually are not equal to dashboards, most of the time they only satisfy the management while the reality is different
  • Feedback loops can stimulate the need to do weird experiments and go out of the box, for example by experimenting with new technology, a new product offering or going into a whole new way of collaboration between business and IT.
  • Gather feedback from the limitations of the secondary processes. If you can remove these, all teams can go fast forward.

In a lot of transformations, it is not the primary goal to improve the secondary processes. And this is very strange. Secondary processes like risks, finance and HR often impact all your teams and people. Improvement in this area solves a lot of barriers.  In the next post, I’ll show how crucial it is to improve secondary processes.

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

Agile Coach Labs: hoe oefenen met retrospectives op de vloer voor een andere dynamiek zorgt + downloads

Hoe is het mogelijk dat je na een drukke dag je toch nog een avond vol energie kunt hebben? Dat kan als de randvoorwaarden maar goed zijn. En dat was het deze Coach Labs opnieuw. Hoe kan het ook anders met 34 deelnemers die graag iets willen leren, twee totaal nieuwe oefeningen buiten je comfort zone, een perfecte organisatie door Wemanity en een mooie locatie met eten en drinken bij ING.

logo_coach_labsMet deze vier ingrediënten heb je de basis te pakken voor een geslaagde avond. En voor mij was het opnieuw een geslaagde avond. Hoewel ik de oefeningen al kende vallen er zoveel dingen op, worden er scherpe vragen gesteld en omdat je met veel ervaren coaches bij elkaar bent ga je wel twee spades dieper. De ervaringen zijn niet te vangen in een dure training, conferentie of webcast. En daarom speciaal dankjewel aan Maarten Tomassen die dit voor de 8e keer heeft georganiseerd.

Wat er gebeurt met een vloeroefening

Hoe vaak doe je een veilige retrospective allemaal weggekropen aan een andere kant van de tafel? Of met post-its waarbij gevoel en emotie in 3 of 4 woorden gevangen moet worden? Dit kan teams enorm vooruit helpen in de verbetering van hun proces en de basis samenwerking. Maar wat als je als team door wilt stoten? Wat als je wilt groeien naar diepere volwassenheid?

Een retrospective op de vloer waarbij je dingen gaat zien, voelen en ervaren omdat je veel te dicht bij elkaar staat kan dan best lastig zijn. En juist dit hebben we geoefend tijdens deze coach lab. Op basis van de transitie fasen van systemisch transitie management hebben we geoefend met wie waar staat, wat je ziet, en vooral wat je hoort als je in gesprek gaat. Sommige blijven achter in de transitie omdat ze simpelweg de urgentie niet voelen. Andere stuiteren vooruit op weg naar fase creatie.

Zomaar wat inzichten:

  • Een vloeroefening maakt (soms pijnlijk) zichtbaar wat we altijd al dachten maar niet durven te zeggen
  • Door mensen soms op een andere fysiek op een andere positie te zetten en ze van daaruit te laten kijken kan er al veel veranderen
  • Het is soms nuttig dat die scheiding van te tafel even tussen ons uit is, we komen dan fysiek dichter bij elkaar.

oefening

Observeren en luisteren is soms van meer waarde dan nuttige adviezen

Continue reading

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.
Continue reading

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