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.

Advertisements

Flow in an Agile environment.

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

In my previous blog I started with the above paragraph. It triggered questions on what Flow is? Trying to answer this question took too many words for a small reply. So I made a blog in which I describe what I mean with Flow.

Being in “the Flow” means that what I do in that moment of Flow goes ”effortless”, “smoothly” and in a continuous cadence.

When I talk about Flow in a team setting, there are two views:

  • The team is in a mood in which it “effortless” and “smoothly” produces results;
  • The work items run smoothly from left (input queue or Product backlog) to the right (output queue). There are no inventories that block the flow of work, and work does not flow backwards (upwards).

The view on work that flows upstream makes people realize the unnatural aspect of it. Work, like water, always flows downstream. If not, then the (natural) flow is ‘broken’ and waste is created: “effort to bring the water of work upstream”.

So flow in our work environment is the continuous movement of work items in the direction of the customer. Never moving away from the customer. In each step value is added to the work items. We only add value that makes the customer happy. If not we pollute the water, add baggage to the work items that makes the customer not happy, the maintenance more difficult and the change of defects greater.

Flow as well means that the effort for the workers is evenly distributed and not ‘batch-like’. The work steps are in balance. No step is overloaded and no step is starving.

Flow in a kanban system aims to reduce work staying in inventories, as this creates waterfalls. With a real danger of dam busts.

Inventory typically occurs when we hit a bottleneck or constraint. Opposite it means that we avoid waterfalls and inventory by taking away constraints.

the team becomes more stable and predictable in their  deliveries.

So, from whatever view you look at Flow, it is a powerful weapon making your team more fun and more resultful.

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.

 

Predictable & resilient programs

15 November, 2013

Too many efforts get lost in complexity or frustration.

“I wish we had known before, what we know now; we never would have started this project”

“Why don’t they listen to us?” asked the project manager himself about management

Many programs keep their focus regardless changes in the system around them

We live in a world that is dynamic and always in motion. That’s a fact. So, how can we know today, what will be the challenge of tomorrow? The answer is simple: we do not know, unless…

Starting a program is to achieve some goal that was defined yesterday. How do you manage a program that aims to achieve something that may or may not be changed while you do your utmost best to get there? How can you early recognize a changing goal that you targeted?

Organizations need to be able to apply a kind of rocket that is guided to it’s moving target by means of laser. Listen2Change offers this management guidance. We provide the laser beam that the decision maker transfers into an adjusted focus, based on new knowledge of the target and the system.

A program in a system influences the system and is impacted by unpredictable agents in that system and events outside that system.

We visualize the influences and resulting changes on regular basis (daily, weekly, ..). It enables weak signal detection to identify risks or opportunities.

For this we use short anecdotes from all stakeholders in the system. Each anacdote-teller adds predefined ‘tags’ or signifying data to their anecdote. The signification provides navigation through the hundreds of anecdotes. it unleashes understanding detailed changes and impact from the perspective of each participant.

The underlying assumption is that people exchange information via stories. The stories are triggered by open questions and gathered independent from each other.  The complete set of stories provide a true reflection of the  reality. As it is continuous it truly provides your laser beam towards a moving target.

The method provides any program or mission the means to start without a clear understanding of the final result. This result will emerge from the running program and its impact in the system.

 

Giving customers their legitimate place in software development.

26 August, 2013

Being really lean means that only that functionality customers use (and are willing to pay for) is developed and released. That means being so agile, that trends and patterns in customer needs/wishes and problems are continuously understood and drive service/product development and delivery.

For this the ‘voice of the customer’ needs to be continuously monitored. The result of the listening is to be analyzed and integrated in the development life cycle (e.g. product backlogs).

As not all new functionality or innovations originate from customers, also the ‘voice of the internal-experts needs to be continuously monitored. This knowledge, experiences and ideas is integrated in the development life cycle as well.

In earlier blogs I wrote in Customer Sensor Networks. Being the same subject, it lacks the natural place in the present developments in agile software development methods. By lack of a better word I use in this blog the term CusDevCus which stands for Customer-Development-Customer. With Development I mean the complete development lifecycle including Marketing, Sales, Product Management, Development, Release and Operations, ect. I am open for any better term.

Core elements of CusDevCus are:

  1. Integrated customer feedback (or external expert feedback) into the development life cycle loop to create integrated feedback,. Integrated feedback
    1. is unlimited in size, the larger the amount of participants, the more effective the next release,
    2. gains insight in trends and weak signals for present and future functionality,
    3. is generated in the form of testing developed functionality as well as new (unrelated) ideas.
  2. Integrated employee (as internal experts) feedback with the same aspects explained under the integrated customer feedback and
    1. open to all employees, continuously…
  3. The feedback combines both quantitative and qualitative information.
  4. Each feedback is signified by the feedback provider. This provides navigation through large amount of feedback.
  5. The Product Owner analyses the feedback-patterns. The combined quantitative and qualitative information enables both a deep understanding of the explicit functionality-feedback and the high level patterns.
  6. Because the feedback is integrated in agile development methods (like Scrum, Kanban, OpenUP, ..) experimentation of new functionality is possible in a semi-real environment using real customers.  This seriously reduces R&D and Sales and Marketing effort and optimizes organizational learning.
  7. CusDevCus fully builds on devOps, BusDevOps lean startup and other agile evolutions.
  8. CusDevCus is based on open feedback in the form of narratives. That means there are no preformatted testforms or questionnaires for feedback.
  9. Of course the open format feedback does not eliminate the need for professional testing!

10. CusDevCus focuses on different user groups. Different user groups have different needs. They reveal different uses (or no use) of functionality.

In my view the above described next step in agile (software) development is a natural one. The main question is whether companies are able to make the mental shift to integrate the customer as described in the software development lifecycle.

Human Sensor Networks

13 March, 2013

Michael Cheveldave from Cognitive Edge wrote a blog on human sensor networks. It is excellent reading material. This blog contains the highlights of Michael’s explanation, with references to Agile IT development and DevOps.

By changing human sensor networks into customer sensor networks, I merely focus on the application of CSN in IT Agile development life cycles. You may easily argue to keep human sensor networks, as also own employees or other relevant stakeholders provide feedback using the CSN system.

Michael explains the role SenseMaker® plays in delivering organizations the value of human sensor networks.

… by engaging a large number of people in the process of making sense of their everyday experiences and observations, and allowing meaning to be effectively layered on such experiences we stimulate a network of agents in the systems to make sense of the system themselves.

By integrating different customer groups in functionality definition we will

  • easier and sooner understand real customer needs
  • build a fruitful relationship with the customer-base
  • create pro-active sponsors at the customers of the product
  • enable the customer-base to better understand their needs, and innovative possibilities that the organization can provide
  • better understand which private betas to be tested by which user group type
  • better understand collected quantitative data by means of this qualitative data

… think about how traditional approaches often emphasise the value of external experts or selectively privilege a small team within the company on such strategic decisions.

The decision making process which functionality to build and release

  • focusses more quickly to that functionality actually needed by customers
  • enables, together with feature flags, different features to be released to different customers types (based on their needs)

Sales and marketing collect valuable information on their targeted customer groups. Information is achieved cheaper, faster and more reliable then based on traditional marketing research.

The approach (a human sensor network AK) allows for the executive team to tap into the distributed cognition, intelligence, scanning, and knowledge of a broader network in a way that effectively informs key strategic decisions.

Reading experiences, ideas and frustrations from actual users, exposes product management, marketing managers and developers to the impact of their initial ideas on what functionality is needed. When well guided, the team will quickly and easily understand existing patterns and needs. Future releases are more effective and efficient.

The ultimate result is a learning organization. People from different organizational silo’s co-interpret and co-decide based on both trends and contextual information. This leads to an organizational wide understanding of and believe in the business goals and opportunities.

Customer Sensor Networks

12 March, 2013

Agile software development has 2 major positive attributes: the short release cycle and the possibility to integrate release-feedback rapidly in the product backlog. In this blog Customer Sensor Networks (CSN) are explained as a mechanism to integrate the Agile software development life cycle with customer feedback effectively.

CSN enables insight in what functionally is needed or wanted. To understand customer needs can be a challenge. In many cases customers do not have any idea what is possible in terms of functionality.

What is possible is in the heads of the developers, architects., analysts or product managers. But what is technically possible is not always wanted or needed by the customers.

The short feedback loop with a short time to market, enables product management to ‘test’ how features are accepted by (parts of) the customer-base. Implementing CSN lets the organization understand effort- and cost-effectively what functionality customers are willing to pay for. It is a good idea to involve the marketing strategy in the development life cycle.

Which customers to select is based on their expertise or area of interest. A variety of customer-types increases the variety of feedback. Innovators will appreciate other aspects then customers in the early or late majority groups. Which profiles you select, will be based on the business and business objectives.

Customer Sensor Network

Figure 1: Customer Sensor Network implementation.

The CSN explained here is based on Sense Maker® software of Cognitive Edge.

The CSN uses an online collector website which pre-processed the information for the product owner and the DevOps teams. Pre-processing is done by the CSN and based on the information provided by the customers.

The Feedback analysis consists of functional evaluation and an emotional aspect. The functional aspects cover things like how features are used or what is missing. The emotional aspect lets product owner en DevOps team members understand what (missing) functionality does with customers. The emotional evaluation is important to understand and support marketing aspects of the product.

Techniques like private beta’s or feature flags enable teams to manipulate releases to different test- or customer groups.

Figure 1 also shows typical takt times in a CSN system. Takt time and wait time lets the DevOps team and product owner optimize flow and adjust overall throughput time with the expectations of the different test groups. This example shows a sprint of 3 weeks. The test period is set for 1 week. Then the feedback is evaluated 2 weeks after the DevOps team finished work. Depending on the expectations of the customer test groups, the waiting time for the customer groups to learn what the effect of their testing has been, might be too long.

Using customers in the development life cycle presents some challenges to the organization. Aspects to take into consideration are incentives and how they (in)formally integrate in the communication plans. Incentives may differ per customer type. For example, for innovator’s their name can be listed on the product website as contributors, or they are invited on some regular basis to the development site to discuss with the DevOps teams and product owners. The early and late majority groups can be given a free license of the product.

CSN provides an effective organizational and team learning mechanism. New idea’s can be tested rapidly and (cost-)effectively. CSN triggers a business approach to Agile development. Developers, maintenance people, product management and marketing all learn as a team what it is that makes their customers happy or dissatisfied.

Applying customer sensor networks (CSN) in Lean Startup and DevOps teams

7 March, 2013

The Lean Startup movement addresses the issue to match product functionality to market demand. For this a contextual external customer feedback loop needs to be implemented. A customer sensor network using SenseMaker® provides online, real-time and continuous contextual feedback, closing the feedback loop.

SenseMaker uses an online collector website that lets customers provide feedback by means of narratives. Each narrative gets a title. The customers also provide additional meaning to their narrative. The system categorizes feedback based on the meaning given by the customers. This avoids overhead during analysis for the organization. The SenseMaker analysis software supports the evaluation of the feedback. Enabling effective and short evaluation time. This feedback mechanism enables evaluation of large amounts of feedback from different customer or user groups.

The analysis software provides both quantitative and qualitative evaluation. The quantitative aspects provide insight if functionality acceptance level. The qualitative aspects provide deeper insight in innovation opportunities. For example alternative or unforeseen use of the functionality. On the other side of the same scale, the feedback points to a risk or threat. For example that the new functionality is not well accepted by early innovators.

Customer sensor networks integrate with Lean Startup pilot experiments and DevOps private beta’s. It also provides for DevOps implementation the needed internal and external feedback for development. The internal feedback from operations to development is useful in case when the DevOps consists of multiple team in different locations.

CSN makes it possible that for some types of development, product management joins DevOps teams to form ProDevOps. This really reduces overhead and transition costs. It enables a whole new approach to app development in a true Agile manner.

 

SenseMaker is a Cognitive Edge product linking micro-narratives with human sense-making to create advanced decision support, research and monitoring capability in both large and small organisations.

 

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 to avoid the Lean/Agile introduction blues

6 January, 2013

Introducing a new way of working fails dramatically in most cases. Why? Because we fail to understand that what works in one open system, does not automatically work in another open system.

We all remember moments when we started working in new company or department. We start to work the way we were used to, but learn quick that we need to adapt. We do this naturally and without thinking. In 2 weeks time our new way of working feels natural.

Perhaps a more ‘natural’ approach in an organizational environment works as effective in our personal environment. Unfortunately, our traditional introduction approach is still widely applied. This leads to the ’introduction-blues’.

When I visit companies introducing Lean/Agile techniques, I recognize the same ‘introduction-blues’ as when I supported companies introducing CMMI practices.

When introducing CMMI practices, the most common failure was the way in which the different practices were introduced without understanding the why of the practice, the impact of the practice into existing way of working and the connectivity of the practices with other ‘CMMI-practices’. Because of this, other existing processes were not aligned with the CMMI-related process improvements or CMMI-related process improvements on the same subject were introduced at several locations in different flavors, leaving users in distress.

Introducing CMMI-with-your-eyes-shut is not a successful strategy. The same holds for introduction of Lean/Agile/Scrum or any other new methodology in that manner.

To apply our personal approach into an organizational approach we use a continuous safe-2-fail approach in which we take small steps, learn and then take another step. The successful steps are enlarged, those that fail are changed or stopped.

But how do you now what works and what not? Which are the first steps? These safe-2-fail probes are supported using SenseMaker®. A busy MT is not able to listen continuously to all stakeholders in the system. Building an effective SenseMaker system is crucial. With this tool all stakeholders provide their feedback and signify their feedback. The feedback is generated by short narratives.

The tool provides for effective categorization of the feedback and visualization tools to create a helicopter overview on trends and theme’s. On the same time it enables the decision makers direct access to the narratives, giving them the necessary context to take appropriate measures.

The process steps: 1) bring stakeholders together in a workshop 2) use a SenseMaking method to analyze the present and identify possible next steps 3) construct a SenseMaker system 4) take the first steps and trigger feedback 5) collect & analyze feedback 6) define following next steps.

Using this system, any organization can effectively introduce any new methodology in a step-by-step, cost-effective manner, while keeping all stakeholders involved, happy and more willing to adapt.