Archive for the ‘process change program’ Category

Agile opschalen met Kanban

11 May, 2018

Wanneer één team op een agile manier werkt heeft dit slechts een beperkt effect op de verbetering van de hele waardeketen. Sterker, lokale optimalisatie leidt vaak tot een verslechtering van de hele waardeketen en daardoor tot frustratie van de teams.

Wat zie je als een team agile werkt: Dit is een team dat nauw samenwerkt en zich continu de vraag stelt hoe het slimmer en beter kan. Zij nemen verantwoordelijkheid en starten experimenten om te zien welke aanpassingen voor hen werken. Het is een team dat metrieken gebruikt om inzicht te krijgen in de eigen capaciteit en om deze te verbeteren. Zij begrijpen hun rol in de volledige waardeketen en betrekken anderen indien nodig.

Een agile team krijgt vanuit management de ruimte en het vertrouwen om zich continu te verbeteren. Zo worden zij ondersteund om proactief met anderen in de waardeketen zelf verbeteringen te initiëren. Natuurlijk komt er meer bij kijken, maar wanneer deze aspecten niet aanwezig zijn, moet het team en het management zich de vraag stellen of zij werkelijk agile willen werken.

Wil je dus dat de hele waardeketen meer en sneller oplevert dan moet je naar de hele waardeketen kijken en het agile werken opschalen.

Opschalen van agile is simpelweg teams uit de waardeketen op een agile manier laten samenwerken. Dit gebeurt in 2 richtingen: verticaal tussen teams op verschillende organisatie niveaus en horizontaal tussen verschillende waarde toevoegende teams of personen.

Agile samenwerken betekent dat teams gezamenlijk bekijken op welke manier werk eenvoudig en effectief door de waardeketen kan stromen. Mogelijke vragen:

  • Zijn de werkzaamheden in de verschillende stappen juist op elkaar afgestemd?
  • Waar bevinden zich (mogelijke) bottlenecks?
  • Beschikken teams op het juiste moment over de juiste informatie?
  • Welke (waardeketen externe) afhankelijkheden zijn er en wat is het effect van de afhankelijkheden op de waardeketen?
  • Onderschrijven alle teams hetzelfde doel en visie?
  • Worden er continu (kleine safe-2-fail) experimenten gestart om de waardeketen continue te versimpelen en verbeteren?

Ook voor agile samenwerken geldt, dat er veel meer voor nodig is dan alleen het bovenstaande. Maar deze mentale houding levert de benodigde omgeving waarin alle teams zich kunnen ontplooien.

Er bestaat niet één model of framework dat 1-op-1 op een organisatie past. Agile samenwerken wordt pas succesvol als je de eigen organisatie en cultuur als uitgangspunt neemt. Het werkt niet als je een model kiest en probeert te implementeren omdat een concurrent dit (succesvol) doet.

De waardeketen teken je uit dmv alle belangrijke waarde toevoegende stappen achter elkaar te tekenen. Simpelweg ziet dit er zo uit:Slide1

Daaraan voeg je dan de invoer, uitvoer, bestaande feedbackloops, werk- en wachttijden en belangrijke afhankelijkheden in de waardeketen.

De ervaring is dat alleen dit visualiseren en verder duiden van bestaande kenmerken van de keten, al direct eerste verbeterpunten oplevert.

Raar maar waar, blijkt een eerste visualisatie vaak niet te kloppen! Als je vanuit verschillende perspectieven (rollen, bestaande verantwoordelijkheden) naar de eerste versie kijkt, blijken er verschillende ‘versies’ van de waardeketen te zijn. Dit inzicht, dat er verschillende interpretaties mogelijk zijn, is een belangrijk beginpunt voor een dialoog. Het laat zien dat in de loop van de tijd een situatie is ontstaan die maakt dat werk (en informatie) niet meer ‘als vanzelf vloeit’, maar dosis-gewijs wordt gestuurd.

Het actief sturen gebeurd onbewust en (vrijwel altijd) vanuit een goede intentie. Daarom is een goede dialoog over welke van de verschillende versies, de kern van de waardeketen is, van vitaal belang, en vaak een eerste stap in het opschalen van een agile manier van werken.

Kanban is een methode die perfect is toegesneden om de agile transitie te realiseren. Immers Kanban gaat uit van het visualiseren van de waardeketen en beoogt Flow van werkitems te verbeteren.  Opschalen is het schakelen van meerdere kanban systemen.

Over Kanban: Kanbanis een visueel signaal (kaart, boord). Een Kanban systeemis een manier om werk op basis van (virtuele of fysieke) kanbans, de flow van werk items te beheersen. De Kanban methodeten slotte, is het definiëren en verbeteren van kanban systemen. Een complete Kanban uitleg vindt je hier.

Je stemt Kanban systemen op elkaar af door de flow van werk en informatie te analyseren. Hiervoor gebruik je metrieken die de flow kwantificeren. Je zoekt naar de onbalans tussen bijvoorbeeld de hoeveelheid werk die een systeem inkomt en weer verlaat. Als je de invoer van een kanban systeem aanpast op de capaciteit ervan, zal het systeem snellere opleveren (de doorlooptijd neemt af), en de hoeveelheid werk en kwaliteit toenemen.

Okaloa Flowlab crossteamsimulaties vormen een perfecte start voor het afstemmen van kanban systemen over meerdere teams. De simulatie staat het toe de werkelijkheid van elk type werk te simuleren. Teams ervaren wat het effect is van een systeem dat niet in balans is en hoe systemen op elkaar af te stemmen. Overigens maakt het in dit geval niet uit of een team wel of niet Kanban gebruikt. Ook teams die volgens een Scrum methode werken kunnen de werkzaamheden in een ‘Flow’ krijgen.

Hieruit volgt ook direct het inzicht, dat het afstemmen van werk tussen 2 teams in een waardeketen met bv 10 teams, een gevaarlijke deeloplossing is.

Bedenk namelijk dat deze 2 teams meer werk leveren en aankunnen. Het effect is dat én het volgend team plotseling meer werk ontvangt (dan ze aankunnen) én dat het voorgaande team in de waardeketen, plots meer werk moeten leveren dan zij kunnen. Er ontstaat onbalans in het systeem.

Kortom, wanneer je naar een methode zoekt om de agile manier van werken op te schalen, overweeg dan de kanban methode eens. Bijkomend voordeel is dat Kanban uitermate geschikt is om verschillende type van werkzaamheden of werkproducten, in één systeem te integreren.

Arno Korpershoek,
Co-chi
Rotterdam,
mei 2018

Advertisements

Effectief beheersen van transities door onzekerheid om te vormen tot kracht

1 July, 2017

Als ik om mij heen kijk, zie ik vele agile initiatieven. Iedereen in een agile transitie verkeert op enig moment in extase (ziet een mogelijke toekomst), verwachting (van een direct resultaat), of (veelel grote mate van) onzekerheid (“waar zijn wij/zij in hemelsnaam aan begonnen!”).

De transitie teams zijn zeer wel in staat om extase en verwachtingen te managen. Het omgaan en effectief gebruiken van onzekerheid is iets wat de meeste transitie teams (nog) niet beheersen.

In deze blog ga ik in op welke manier je onzekerheid tot kracht kunt omvormen.

Onzekerheid
Onzekerheid komt in vele gedaanten. Het is ook een belangrijke oorzaak waarom transities in meer of mindere mate falen. Het kost energie en tijd. Denk bv aan al die momenten waarop mensen met elkaar in gesprek gaan over de transitie en hun perceptie ervan. Deze gesprekken en eruit volgende ideeën en mentale modellen, frustreren en zorgen voor onrust en tegenwerking. De energie loopt bijna letterlijk weg.

De frustratie komt onder andere voort uit het feit dat (het lijkt) dat het transitie team de gevoelde impact van de transitie en de mentale gevolgen hiervan, niet lijkt te zien, niet lijkt te willen zien, of (mogelijk nog frustrerender) er niets aan te willen doen.

Het transitie team heeft ook veel onzekerheid. Immers, zij hebben een complexe organisatie, die zij op een juiste manier, anders willen gaan laten werken.

Er bestaan voor deze transities geen best practices. Voor iedere organisatie wordt succes bepaald door andere factoren. Geen organisatie is hetzelfde, heeft dezelfde processen en veeeeeel belangrijker, geen organisatie bestaat uit dezelfde mensen!

Dit heeft tot gevolg dat het transitie team wel verschillende mogelijke manieren van aanpak heeft, maar het niet in staat is op voorhand te bepalen, welke aanpak tot welk resultaat zal leiden.

Dus misschien ligt de grootste onzekerheid wel bij het transitie team. Simpel en alleen omdat iedereen wel verwacht dat wat zij doen, het (enige) juiste is.

Alhoewel het transitie team feitelijk zou moeten zeggen,

wij weten het ook niet, wij hopen met deze aanpak het beste resultaat te bereiken, maar zeker zijn we er niet van”, 

zeggen zij

Wij hebben goed nagedacht. Onze aanpak is de enige juiste. Als jullie je best doen en precies doen wat wij zeggen, komt alles goed”

Over onzekerheid gesproken!  Hopelijk lezen zij deze blog ook ….

Onderliggende problemen
Onduidelijk doel
In agile transities is het doel nogal vaag. Meer flow, meer responsiveness, De business gaat ook ‘scrummen’ zijn niet bepaald termen wat voor een ieder helder is wat dit in de praktijk betekent.

Geen vertrouwen in de transitie het het transitie team
Door het ontbreken van vertrouwen zal er weinig feedback zijn mbt de ingezette transitie. Hierdoor heeft het transitie team geen of onvoldoende mogelijkheid de ingezette transitie aan te passen en genomen besluiten zodanig te vormen naar de zich veranderende werkelijkheid op de ‘transitie-werkvloer’. Er dreigt dus een (gapend) gat tussen de transitie leidinggevenden en de mensen op de werkvloer.

Mentale modellen
Veelal werkt de organisatie die de verandering in gang zet al jaren op een min of meer succesvolle waterval aanpak. De hele organisatie is ingericht de falende aspecten van de waterval aanpak (veel her-werk; silo-vorming, zware governance teams, etc) voortvarend te lijf te gaan. Deze groepen worden met Agile aanpak deels overbodig, of gaan in de teams/projecten op. Ongeloof, onzekerheid en tegenwerking borrelt langzaam maar zeker op.

Heb ik nog een baan straks?
Doordat agile manier van werken vaak betekent dat er minder afdelingen en mensen nodig zijn voor betere kwaliteit en meer opleveringen, ontstaat vanzelf onrust. Heb ik straks nog een baan? en zo ja, hoe ziet mijn nieuwe rol er dan uit? Ga ik minder verdienen? Moet ik meer uren maken? Hoe en waar ga ik dan op worden afgerekend? Ben ik voldoende opgeleid?

Mijn management Agile? laat me niet lachen!
In een organisatie die groot is geworden met command en control structuren, en nu een Agile transitie start, is de vraag zeker gerechtvaardigd, of het huidige management de verandering wel aankan. Zijn zij in staat de agile mind te verinnerlijken. Zijn zij in staat verantwoordelijkheid en autoriteit die daarmee gepaard gaat lost te laten en naar lagere niveaus over te laten?

Omgaan met de onderliggende problemen
Door de mensen een kanaal te geven hun ideeën, ervaringen en bezorgdheden te uiten, pakken we hierboven beschreven onderliggende problemen aan. Door deze uitingen serieus te nemen en input te laten zijn voor de transitie aanpak, ontstaat vertrouwen in de transitie. Maar nog veel belangrijker is dat de mensen, zich gehoord voelen en daardoor zichzelf deel gaan laten uitmaken van de transitie.

Dit kanaal noem ik Oneteam.

De aspecten van het omvormen van de organisatie, het loslaten van oude patronen en het inslijten van nieuwe (agile gebaseerde) practices, laat ik in dit blog buiten beschouwing. Kern van het succes is de mensen die de transitie serieus te nemen. Deze mensen ervaren namelijk op dagelijkse basis het (onbedoelde) effect van ieder besluit.

Oneteam
Oneteam verzamelt ervaringen van mensen op een continue basis. Dit maakt dat wanneer je een idee hebt, of ergens last van hebt, je dit direct kunt delen. Het delen gebeurt door het vertellen/opschrijven van korte anekdotes. Wanneer blijkt dat het transitie team deze input, jouw input!, gebruikt om de transitie aan te passen, voel je je zekerder. Er ontstaat vertrouwen naar beide kanten. Er worden méér ervaringen van de werkvloer gedeeld, én de besluiten zijn constant in directe relatie met de feedback van eerdere besluiten. Er ontstaat een versterkende lus.

Door deze symbiose ontstaat een ware agile transitie. Door de constante Inspect & Adapt cycle groeit de organisatie naar constant nieuwe vormen. Iedere nieuwe vorm past net iets beter dan de vorige. De organisatie wordt lerend.

Oneteam opzet en resultaat
Oneteam bestaat in 2 vormen.

Richt je je eenmalig op een team, of een aantal teams, kun je volstaan met workshop(s).

In de workshop deelt het team ervaringen en ideeën. In een aantal vervolgstappen worden de persoonlijke ervaringen geanonimiseerd. Gedurende de stappen ontstaan thema’s waaraan acties worden gekoppeld. De acties worden in de transitie backlog geplaatst. doordat iedereen kan deelnemen is iedereen ook eigenaar van het resultaat en de acties.

Bij grote en langdurige transities is een tool effectiever. via een website en app kan iedereen in de transitie continu zijn of haar ervaringen en ideeën delen.

Zo ontstaat een rijke bron van relevante en continu veranderende beelden uit de transitie.

De feedback wordt óf door een separaat team óf in (grote) workshops geanalyseerd. Beide vormen maken het mogelijk gegevens vanuit verschillende perspectieven van betekenis te voorzien. Hiermee kan het transitie team bv bepalen welke welke impact bepaalde besluiten hebben. Voorbeelden van perspectieven: alle positieve anekdotes na een bepaalde datum door een bepaalde groep betrokkenen, of alle verbeter ideeën vanuit scrum teams. of alle negatieve feedback van externen. Doordat men de achterliggende anekdotes kan lezen, worden de analysis scherp en de vervolg acties pragmatisch en met een directe impact.

Succesvolle transities
Betekent dit dat met Oneteam iedere transitie succesvol wordt? Ik hoop van wel. Maar natuurlijk ligt het succes in de (verander)kracht van de organisatie, en in de competenties, daadkracht van de mensen in de transitie.

Wat Oneteam wel voor een transitie betekent:

  • een continue bron van rijke, relevante en betrouwbare informatie over de gang van zaken op de werkvloer
  • anonieme anekdotes, wat maakt dat mensen vrij zijn te delen wat zij willen. Ervaring leert dat deze anonimiteit nooit misbruikt wordt.
  • transparantie: van werkvloer naar het transitie team, en van transitie team naar de werkvloer
  • de mogelijkheid om mensen in een moeilijke, persoonlijke en onzekere tijd, hun gevoelens, ideeën en ervaringen op een zinnige manier te delen
  • onmisbare ondersteuning voor ieder transitie team
  • het voorkomen van ‘blind’ moeten navigeren tijdens transities
  • het uit kunnen voeren van experimenten; door de snelle en korte feedback lijnen, kan er kort op de bal worden gespeeld

Van onzekerheid tot kracht
Deze experimenten zijn in feite de kern en de manier waarop het transitie team onzekerheid omvormt tot kracht.

Agile betekent het onzekere omarmen en door middel van een aantal (liefst parallelle) experimenten, de organisatie snel te laten leren.

How to create flow.

24 March, 2017

Flow is the new buzz. Each of us knows exactly what flow is. And how it feels. It feels great! You probably have even experienced it yourself. Great!

But flow in relation with work?  That is something else. It needs planning,  and changing work habits.

But we can create flow in our work environment. We are able to let work items or information flow through our work processes. Just look at the car manufactures. Their assembly lines are a perfect example of flow. But it took them many years and hard work.

The good news is that we can also implement flow in creative work places. Whether we create fancy apps or provide services. In HR departments, DevOps teams, back office, marketing teams, they all are able to create flow in their delivery process

Below I explain how you can start to implement flow.

Visualize your system to identify your bottleneck

    1. Identify Bottlenecks/constraints.
      • Draw a value stream map (VSM) to  visualize your system.
      • The VSM creates a common language to engage your stakeholders in your endeavor.
      • The value stream shows you the constraints. Probably you already knew the constrain (or had a good guess). But it is like handling risks, once they have been documented, they become somehow more real. This is also true for constraints.
        • Also good to realize is that you handle constraints with care. Even with more care then porcelain. It involves people. and the tricky thing is that people who are part of the constraint, became the constraint due to the system. Not of what they did or did not do!
  1. Eliminate constraints (not the people!)
    1. Exploit the constraint.
      • Let the constraint only work on the flow-impeding work.
      • Reduce the amount of incoming work using WIP limits to the level that the constraint is able to chew.
    2. Increase the constraint capacity.
    3. Find the next constraint.
  2. Ability to manage stakeholders that impact the constraint.
    1. The demand of work is defined outside your responsibility level. So in order to balance the demand with the available capacity, takes some diplomacy and persistence.
    2. Further downstream stakeholders are in need of your work items. They will claim your capacity is not fully used.
    3. Invite your stakeholders to some flow experience
      • Involving your stakeholders in a short Flow simulation workshop, combined with theoretical explanation on queuing theory may just do the trick to at least allow you to do an experiment with manage the work through WIP limts and other queuing theory techniques. (The Okaloa Flowlab simulations offer a range of different simulations that address all aspects of flow).

Some additional advice.

Start with flow simulations with some key stakeholders. They first need to understand the basic concepts of flow, queuing theory and WIP limits. This also let them experience the impact of WIP limits on the speed and reliability of their delivery requests.

On team level  create a stable input of work. Ensure that the teams grow into a stable delivery cadence. Use the team simulations to allow the team to experiment and experience flow in their own environment. You can use the actual work environment of a sprint to experiment with reducing WIP and allow the team to  become more stable and predictable in their  deliveries.

Next step is to let multiple teams that work to create flow of their combined teams. Run the cross team simulation as a start to have teams and product management experience and experiment addressing aligning capacity differences to a smooth delivery cadence.

Upstream, product management  (program or value stream level) implements a Kanban system that adheres to the same principles of flow as on team level. But here is one additional focus point.

Internal product management use WIP limits to effectively deliver a constant flow of work requests for the downstream teams.

From the perspective of the downstream teams product management takes care they have at all times sufficient work requests (options) available. This ensures that product management is never overstressed in producing sufficient work for the downstream delivery teams (quality, instable workloads up- and downstream). For the downstream  teams this means they have at all times sufficient work on their incoming backlog.  They are able to maintain a stable cadence.

For more information on  simulations  look at the available workshops in Europe on Okaloa. On May 19th we offer a public workshop  on the Okaloa Flowlab simulations in which we  specifically address implementing Flow or Kanban systems in SAFe environments and other scaling approaches.

 

Cynefin en Kanban == niet planbaar met optimaal resultaat ==

30 January, 2013

Meer en meer worden Cynefin en Kanban met elkaar in verband gebracht. En dat is niet zo gek. Immers, beiden zijn een manier om naar complexiteit te kijken. In deze blog ga ik in op de gecombineerde kracht van beide. Gecombineerd geven zij een organisatie een niet-planbaar-optimaal resultaat.

De kern van Kanban is het inzicht krijgen in de capaciteit van waarde leveren aan de klant. De hele keten wordt hierbij betrokken. Door de deel-performantie van de verschillende stappen op elkaar af te stemmen, ontstaat een optimale doorstroming op organisatie niveau.

Dit inzicht en manier van werken vormt vervolgens het uitgangspunt voor continue verbeteringen en aanpassingen. Het (gevisualiseerde) inzicht bij alle betrokkenen geeft het continue verbeterproces een natuurlijk karakter.

Cynefin is een model dat 5 probleem domeinen definieert: obvious, gecompliceerd, complex, chaotisch en disorder. Ik verwijs naar http://en.wikipedia.org/wiki/Cynefin voor een meer gedetailleerde uitleg.

Proces verbeterprogramma’s of de implementatie van Lean/Kanban in een organisatie zijn beide typische voorbeelden van complexe problemen. Complex betekent dat er geen directe relatie bestaat tussen oorzaak-gevolg. Het resultaat is niet planbaar en is alleen terugkijkend verklaarbaar. Dit in tegenstelling tot een probleem in een gesloten systeem (gecompliceerd en simpel). Daar zijn oorzaak en gevolg door analyse of categorisering te voorspellen.

De Cynefin aanpak voor complexe problemen is door gebruik van de gecombineerde kennis van experts, inzicht te krijgen in de mogelijke oplosrichtingen. Deze vormen de basis voor de volgende stap. Het starten van safe-fail `(niet fail-safe) probes. Door een continue en real-time feedback loop wordt de impact van elke probe zichtbaar. Succesvolle probes worden versterkt en uitgebreid. De niet succesvolle probes worden gestopt. In een zich ontvouwende werkelijkheid wordt een (niet gepland) optimaal resultaat bereikt.

De gecombineerde kracht zit in de opbouw van kennis over de capaciteit van de organisatie en het begrip van de mate van complexiteit van de taken (zowel in bouw als management). Het leiderschapsteam kan op basis van deze kennis en begrip de organisatie stimuleren tot continu leren en verbeteren. Het vormt de basis voor de strategie en de continue aanscherping van deze strategie.

How SenseMaking creates learning organizations by effective change programs.

8 June, 2012

The natural approach for effective change programs is full involvement of and guidance by all involved key-players. Combined with a natural learning approach this leads to effective continuous change programs and a learning organization.

What is different related to old-fashioned centrally and top-down managed change or improvement programs is the emerge of the outcome during execution of the change program. Based on the learning path, new nearby objectives are defined.

Sensemaking creates learning organizations in just 6 steps.

1    Entry criteria
Use the 6 steps only if your problem belongs to the complex domain. Obvious and complicated problems are bests solved by using standard solving techniques. See the Cynefin model for background information on the different problem domains.

2    SenseMaker design
SenseMaker® facilitates continuous, small and large scale, fine-tuned listening to all stakeholders (clients, employees, external (non-)experts). The design of SenseMaker is essential for a successful change or improvement program. A correct design ensures that the right information is distilled. An incorrect design provides not the information that the next steps need in order to be effective. It leads to frustrated stakeholders as their voice, thoughts and ideas are not heard or implemented.

3    Initial workshop
The initial workshop both validates the SenseMaker design and generates a vision of possible solutions. These possible solutions provide the first steps towards learning. Typically a Cognitive Edge method like Future Backwards is used to facilitate the workshop.

4    Experiment definition
The outcome of the initial workshop is used to define a first set of low-key-low -profile experiments. The costs and duration of each experiment is kept to a minimum. None of the experiments is expected to provide an ultimate solution to the problem.

Each experiment is described in the form of actions and indicators for feedback-signals that indicate positive or negative change. By generating additional context information, management is able to understand early (weak) signals. In this way initial actions that show promise are extended while negative indicators trigger recovery actions and choose of alternatives approaches.

5    Learning by experimentation
The initial experiments provide learning opportunities. Learning is generated both from the experiments participants and by the feedback loop continuous and real-time generated by all stakeholders using SenseMaker.

6    Emerging change
Outcome of each experiment is evaluated both by means of it’s direct outcome or delivery and by means of the feedback mechanism. Those experiments that both deliver on outcome and receives good feedback are re-evaluated for strengthening and to be continued. Those experiments that fail to deliver are stopped. Notice that learning may trigger new experiments.

Step 5 and 6 is a continuous loop. New problems or emerging insights will most likely trigger new experiments. A learning organization is created.

The above figure below shows a graphical view on experimentation in a learning organization. In the emerging process of learning, more and more practical knowledge is generated. This enables more stable experiments. By reducing the risks of failing experiments, the size (€) and duration (T).