Agile transformation is all about the willingness to change, but let me tell you a secret: not everyone or every organization embrace that change

For many years we have heard about the good things that will happen if organizations start increasing their agility, if projects become more agile, and if old habits are replaced with an agile mindset. The evidence is convincing. There are plenty of white papers, reports, research etc. that will support the viewpoint that the higher organizational agility the shorter lead times, faster time-to-market, higher customer and employee satisfaction.

In other words, ‘going agile’ seems like a no-brainer, and many companies do the attempt. However, many of those that try, are failing miserably. Not because they are different. Not because the agile method/framework could not work. Not because it’s particularly difficult. So why do they fail?

No management support – no significant agile change

To be blunt it does not matter what method you choose. It will not work if there is no management support and clear leadership, if the culture is bad, the behavior stinks, bad habits are accepted, and change is not welcome.

I know that there are “method fundamentalists” that firmly believe, that if only you use their method, everything will change automatically, but I must disappoint you. Nothing changes automatically, and no method will save you from failure, but a method can indeed help you succeed if you use it as intended.

Change feels dangerous and creates…. FEAR!

‘Going agile’ results in transparency, and it often means that people have to change working habits that are 5-10-20 years old. That’s not easy, and it may affect their self-perception. You may be a current-state-champion but will be a novice just like everybody else when new agile principles are introduced. You may have been a command-and-control type manager, and it may feel like an attack on you, when servant leadership becomes the new norm, and the bearing idea of self-organizing teams is introduced.

Such changes may trigger fear, but not until you get beyond that fear will agile change be possible. But of course, it is possible.


What happens in the real world?

I don’t suggest that my experiences are the only valid experiences, but after having lead a number of agile transformations in both big and small companies, public and private, and having coached many managers and teams on how to transform from classic silo thinking to agile systems, I have experienced the importance of management support again and again. If it’s there, magic may happen, if it’s not you cannot release the improvement potential that lies right in front of you.

It may be easy enough if you are a new company, that have made the decision to work agile from the very beginning. You can just insist that anyone that wish to be employed must work according to agile principles, or else they cannot work in your company.

It’s a very different matter to turn around a super tanker, that has been working according to non-agile principles for many years. Old habits must change. Both on the individual level and the organizational culture on the whole. That’s hard work! And it takes time and persistence.

You also need to determine how you will react if individuals start opposing the new agile structures and mindset. What will you do, if all agree to the rules that everyone should play by, and then you see colleagues neglecting or even obstructing those rules? What will you do if people refuse to be transparent and visualize what they are working on? What if inappropriate behavior and mindset remains unchanged?

These are not examples, that I just imagine might happen. I see them every day, and this has made me realize that unless you have strong management support and sponsorship, you may see minor improvements, but they may not even be worth the investment and the disruption that the agile transformation has caused.

Don’t despair and don’t drop your agile ambitions

Agile change is worth the while, and of course you can make it work, but first you need to ask yourselves:

  • What do we want to gain from an agile transformation?
  • How can we make sure we choose the right method that fits our context?
  • How will we plan the transformation and how will we implement? (Yes! Agile implementations can be planned)
  • What will we measure, and how will we determine if we are on the way to reaching our goals?
  • What will we do to those colleagues that cannot accept our new agile ways?
  • How can we ensure that continuous improvement does indeed become continuous?
  • How can we prevent ourselves from falling asleep, when we reach a certain level?

Once you have answered those questions, you are ready to start your agile journey. Full speed ahead!

Want to know more about me and Xvoto? Check us out here:


Posted in Adopting agile, Agile, Agile failure, Agile implementation, Agile management, Agile transformation, Change Management, Organizational agility, Uncategorized | Tagged , , , | Leave a comment

How lack of real management support can kill agile ambitions

These days agile is the new black, and thanks for that! Having been an IT Project Manager for around 30 years, I have seen too many classic-style projects fail, because the budget or the time allocated to do the project did not match the scope, because of late or poor decision-making from the steering committee, or simply because the competencies to do the project were not available.

A lot of wishful thinking was forming our projects, and if you protested, you often got a direct order to go and fix the unfixable. You were the Project Manager, after all… I’m thankful that I had my crystal ball and magic wand, since I was often asked to be a magician 😊

_MGL1399 - Annette with crystal ball

Did these bad things go away with agile approaches?

Well, the answer is a definite maybe!

If we look at the Cynefin framework (By Dave Snowden) below, I guess that anyone with project experience can agree that we are usually in the complicated and/or complex area, sometimes even in the chaotic area, but seldom in the simple area where everything is perceivable, predictable and repeatable.

Therefore, we can forget the idea that the command-and-control style of management will work in these scenarios or insisting that as long as we plan long enough or try to standardize complexity – which by the way is impossible, we will achieve project success.

This has been experienced by many organizations, who have started to transform in a more agile direction. Usually they start up agile teams believing that their problems will then go away. Well, they may – but only if you are willing to pay the full price. Agile systems are not a team-thing only. They require a different management style too.

Cynefin Framework by Dave Snowden

3 ways that managers obstruct agility

When you move in an agile direction you will indeed see improvements. Mainly due to:

  • Increased transparency
  • A more frequent dialogue with your customer = earlier feedback

However, the big-scale improvements you were looking for, remain a dream only until you fix what impedes your agile system. Often the biggest impediment is the lack of real and consistent management support of your agile ambitions based on sound decisions.

  1. Mid-level managers do not really want to delegate decision-making authority to agile teams. Are they not managers after all!
  2. Both top- and mid-level managers return to “good old” waterfall habits as soon as difficulties arise. Even if experience shows that waterfall will not give them the results they seek
  3. They pick the agile elements they intuitively like but leave out what they don’t. This way your agile recipe will never work as intended

Changing your management style based on a shallow understanding of agile is not likely to happen. You must dig deeper!

For many years I have been coaching, training and working with organizations, large and small, to plan and execute their agile transformations so the new ways could turn into new good habits that stick.

We may as well face it: There is no easy fix. Again, look at the Cynefin framework. We are working in complicated or complex circumstances with known or even unknown unknowns. How could there be an easy fix?

“Going agile” is a change project that introduces paradigm shifts in the way you collaborate, manage and support agile teams. This requires effective, continuous communication and training at all levels in the organization.

Yes! Managers, even top-level managers, must be trained too. How else would they know how to best support their agile teams? This also sends a strong signal: “We believe in this transformation, it will not go away, and we are willing to change too”.

Scratching the surface is not enough. E.g. looking at the Scrum process which fits nicely to one single piece of paper, could never give you a deep understanding of the prerequisites to making Scrum work. The apparent simplicity of Scrum has generated numerous waterfall managers in disguise. They may use agile words, but they act as they always did.

Knowing this, we should recognize that:

  1. Changing old habits is a big thing that will not happen overnight. We need to be pragmatic and patient
  2. Many managers may intuitively feel that that they have more to lose that to gain working in agile systems. We must be able to explain what’s in it for them
  3. Old ways offer a false sense of security. They don’t work too well, but are known and feel comfortable. We must prove that agile systems are more predictable and more fit-for-purpose in complicated/complex scenarios

Analyze what agile framework or method is the best fit. Don’t forget Kanban. It is the alternative path to agility that works even where there is a lot of unpredictability.

Allow time to practice and make agile collaboration become a good habit. Then you will see benefits that will just keep growing

Posted in Adopting agile, Agil implementering, Agil realisme, Agile, Agile implementations, Agile management, Agile transformation, Change Management, Good practice, Management, Organizational agility, Transparency, Uncategorized | Tagged , , , , , , | Leave a comment

Lad os få realismen tilbage omkring Scrum. Glem Spotify. Glem “Scrum Nirvana”

Jeg har i efterhånden 10 års tid arbejdet med agile transformationer fra diverse vinkler. Jeg blogger, jeg underviser i Scrum og Kanban, holder foredrag om agile, coacher agile teams og rådgiver de ledere, som også må lægge deres ledelsesvaner om, hvis de skal kunne spille godt sammen med deres agile teams.

Ude i virkeligheden hos kunder, kursister m.v. hører jeg meget tit noget i denne retning:

  • “Jamen jeg har hørt at Spotify gør sådan og sådan, det vil vi også gerne”
  • “I Spotify fungerer selvorganisering perfekt! Sådan skal vi også være”
  • “Nogen, der arbejder for Spotify siger eller gør dit eller dat”

Det er ikke fordi, jeg vil være en æggeknuser, en party spoiler eller bare småirriterende. Men nogen er nødt til at sige det højt:

Vi kan ikke alle være som Spotify. Kun én organisation kan, og det er Spotify selv.

Scrum Nirvana findes ikke – jeg har i alle tilfælde aldrig set det…

Glem Scrum Nirvana – det findes alligevel ikke. Og hvis det skulle gøre i enkelte tilfælde, så er det fordi, man har arbejdet benhårdt på at komme derhen.

Scrum, Kanban m.v. er ikke en gratis omgang. Det kræver hårdt arbejde med virksomhedskulturen, medarbejdernes – og ledernes – mindset, at man tager de agile værdier til sig og arbejder efter dem. Og selve metoden? Den skal naturligvis følges, hvis man skal have noget ud af at bruge den. Sådan er det bare, og det er da bare almindelig sund fornuft.

Det jeg ser mange steder, er ledere og såmænd også medarbejdere, der tror, at man bliver agil sådan nærmest af sig selv. Men der findes desværre ikke en agil skjorte, man kan tage på en dag og BUM så er man agil. Sådan spiller det agile klaver desværre ikke. Hvis det gjorde, ville jeg gå ind i manufakturbranchen 🙂

Men det er ikke ens betydende med, at man ikke skal tage skridtet mod en agil samarbejdsform. Tvært imod, så er det noget af det smarteste man kan gøre, hvis man vil have mere gennem pølsemaskinen samtidig med at folk bliver mindre ophængte og stressede. Men man skal gøre det med omtanke og man skal have et formål og en plan med det.

Vigtigst af alt, så skal man være realistisk. Ingen organisation, der er siloorganiseret (krydret med personsiloer), har arbejdet vandfaldsagtigt i mange år, har mange tværgående afhængigheder og mere i den boldgade, vil kunne komme fra dette ståsted over til et nyt agilt fra et øjeblik til det næste. Man må indse, at der nemt kan gå et par år, før de nye vaner og tankesæt er blevet en del af organisationens DNA. Uanset hvad man ellers måtte love jer. (Mange lover lidt rigeligt).

De 3 vigtigste grunde til at agile transformationer tager tid

  1. Når man skifter til en agil arbejdsform, kan man ikke bare skifte organisationen ud samtidigt. Man har de medarbejdere, man har. Nogle er topentusiastiske, nogle kan ikke se, hvad agile skal til for, og andre er et sted midt imellem. Det er et forandringsprojekt, der tager tid, når alle skal med på den agile vogn. Modsat Spotify, hvor man slet ikke kan være, hvis man ikke er vild med at arbejde agilt
  2. Etablering af nye vaner tager mere tid, end mange har tålmodighed til at vente. At gå fra vandfald til agile er et paradigmeskift. Både for medarbejderne og for lederne. Måske især mellemlederne, som pludselig mister noget beslutningskompetence, som nu delegeres nedad.
  1. Mellemlederne og projektlederne er dem, der – i hvert fald med Scrum – bliver ramt hårdest af skiftet til agile. Jeg oplever jævnligt at blive modarbejdet af disse to grupper. Langt fra altid i det åbne – det kunne jeg forholde mig til. Topledelsens evne til at håndtere denne vigtige medarbejdergruppe er afgørende for, hvor godt en agil transformation lykkes og hvor længe den tager.

Tilbage til starten: Selv efter et par år er man næsten med statsgaranti ikke i nærheden af at ligne Spotify på den agile front. Men man kan med god planlægning og fokus på, hvor man vil hen og med en god portion vedholdenhed rykke sig skridt for skridt i en mere agil retning.

Agile metrikker

Jeg kan også kun anbefale at måle jævnligt, hvor meget I rykker jer, og hvor langt I er kommet. (Nu får jeg nok nogle stykker på nakken). Ja, jeg sagde måle! Man må gerne måle sine agile teams, og hvornår ville I ellers foretage en investering uden at se efter, om I får noget ud af den?

Vil I vide mere om, hvordan I får styr og retning på jeres agile transformation, så kontakt mig endelig på 51519297 eller skriv til Jeg svarer altid i løbet af nul-komma-fem.

P.S. Agile virker, så tøv ikke med at gå i gang. Men gør det først, når I ved, hvor I vil hen

Posted in Agil god praksis, Agil implementering, Agil modenhed, Agil realisme, Agile, Agile målinger, Agile transformationer, Agilt mindset, Forandringsledelse, Kanban, Ledelse, Organisatorisk agilitet, Scrum, Scrum Nirvana, Uncategorized | Tagged , , , , , , , | Leave a comment

PMI EMEA 2018 – here I (and Kanban) come!!

Nu har jeg fået fornøjelsen af at tale på PMI EMEA 2018 Conference i Berlin. Juhuuu!!! Mit foredrag, som jeg glæder mig meget til at gøre knivskarpt, hedder: “Improve Organisational Flow and Performance by Climbing Kanban’s Maturity Ladder”.
Det bliver så godt at rykke fra at tale om det, der foregår på team-niveau op til det strategiske, som i virkeligheden er dér, hvor man kan få tingene til at rykke og skabe vedvarende forandring. Ikke for forandringens skyld, men for at skabe hurtigere og bedre resultater = flere $ og større arbejdsglæde.
Det er blevet mere og mere tydeligt for mig i de efterhånden mange agile transformationer, som jeg har været en del af, at ledelsens aktive medvirken – eller det modsatte – er det, der får en transformation til:
1. at lykkes
2. at sande til eller
3. at køre direkte i hegnet.

Hvorfor kører agile transformationer i hegnet?

At en transformation kører i hegnet, har intet at gøre med den agile metode, f.eks. Kanban. Det har kun noget med viljen til forandring, lysten til transparens, og evnen til at kigge indad at gøre. Hvis dette mangler på ledelsesniveau, ja, så vil tingene sande til, lige så sikkert som at 2+2=4.
Og så har det selvfølgelig også noget at gøre med den agile coach’s evne til sammen med ledelsen at skabe struktur og retning for transformationen, så de forskellige teams ikke stikker af i alle mulige retninger. Det er beklageligvis noget, som mange glemmer i begejstringen over selvstyrende teams, og tværfaglighed. 2 ting, som i parentes bemærket, ikke bare kommer af sig selv.
Jeg arbejder løbende med at skabe balance mellem selvstyring og governance, som jo faktisk er en integreret, men lidt glemt, del af alle agile metoder. Vi har jo stadig en vare, der skal leveres.
Annette Vendelbo - dependency board
Men alt det vil jeg komme ind på i mit foredrag i Berlin, hvor jeg vil vise, hvordan Kanbans modenhedsniveauer giver klare anvisninger og retning på, hvordan man rykker sig fra et ofte (for) primitivt team Kanban board til det strategiske niveau, hvor man har styr på og balance i sin portefølje. Og så er det ikke engang særligt besværligt, når først man har sat sig for at gøre det. Det kræver bare min hjælp i nogle dage og lidt løbende coaching.

Undgå de værste fejl og book mig til et foredrag om f.eks. Kanban, Ledelsens ansvar i agile transformationer eller Sådan klarer I skiftet til agile med succes

Hvis nu du ikke skal til PMI EMEA konferencen i Berlin den 7-9 maj, men er blevet nysgerrig efter, hvordan Kanban gør dig og din organisation mere agil, så kan I booke mig til at holde dette foredrag – eller et særligt tilpasset til jer – hos jer. I kan altid kontakte mig på, så er jeg på vej.

P.S. Kanban kan bruges overalt, hvor man leverer services. Det er ikke kun en IT-ting.

P.P.S. Hvis I bruger Scrum, men synes, at det er svært at få det til at virke, så skift til Kanban. Alle de teams, jeg har arbejdet med, har været i gang i løbet af nul komma fem og har skabt overbevisende resultater!
Posted in Adopting agile, Agil modenhed, Agile implementation, Agile transformationer, Kanban, Ledelse, Ledelsesansvar, Organisatorisk agilitet, Transparency, Uncategorized | Tagged , , , , | Leave a comment


At gå fra en klassisk arbejdsform til en agil er en stor forandring. Man skal ændre vaner, der måske er 5-10-20 år gamle, og agile er ikke intuitivt. Mange undersøgelser beskriver gevinsterne ved agile, og på et enkelt A-4 papir kan man se, hvor simpelt det agile system er skruet sammen, men man kan hverken proppe Scrum eller andre agile metoder ind i en organisation og regne med at det virker, uden følgende forudsætninger er opfyldt:

  1. Man skal vide, hvor man vil hen med sin agile transformation
  2. Organisationen skal være forberedt på denne forandring
  3. Organisationen skal være moden til den

Lyder det som en ”no-brainer”? Jeg kan kun sige, at mine erfaringer fra mange års arbejde som agil coach og underviser viser, at:

  1. Mange virksomheder kaster sig ud i agile initiativer uden at gøre sig klart, hvad man vil opnå
  2. De færreste gennemtænker konsekvenserne for organisationen, og hvordan forandringen skal håndteres
  3. Systematik findes på personniveau, men sjældent som team-disciplin. Modenheden tænkes ofte højere, end den er i virkeligheden

At tænke modenheden op sker ikke fordi, man er urealistisk som sådan, men fordi man kun har sin egen organisation at spejle sig i og måle sig op imod. Man mangler sammenligningsgrundlag, og man ved ikke, hvad det er, man ikke ved.

Mange teams er ikke vant til at arbejde bevidst inden for rammerne af en metode. Ens projektleder kommer bare og udstikker aktiviteter og deadlines. Dette står i skærende kontrast til f.eks. Scrum hvor projektlederen er væk og teamet har stor autonomi.

Det betyder, at de enkelte teams evne til at tage ansvar og føle sig forpligtede for sine leverancer, kvaliteten og hinanden, vil være afgørende for, om jeres agile tiltag vil flytte jer særlig meget.

OG glem ikka, at en ændret tilgang til ledelse faktisk også en nødvendighed.

Det er lidt krævende, men lad det ikke stoppe dig. Agile betaler sig

Agile er hverken kontur- eller rammeløst, men man glemmer ofte bagsiden af ”selvorganiseringsmønten”, som er den styring, der skal til for at synliggøre, hvor organisationen bevæger sig hen og om den agile investering kaster noget af sig. Det får I ved at sætte netop de rammer og målinger op, der viser, om I rykker jer og er på rette vej ift. det, I gerne vil opnå.

Jeg har aldrig oplevet et nyt agilt team, der af egen drift sætter den slags målinger op, men jeg har bestemt set teams, hvor det bliver en sport at jagte forbedringer baseret på deres måleresultater.

Sætter I overordnede rammer på tværs af agile teams, får I en vis standardisering plus et sammenligningsgrundlag. I får større transparens og dermed basis for de justeringer/optimeringer, der giver størst resultater.

Små forandringer giver små gevinster. Tilfældige forandringer giver næsten ingenting

At agile metoder virker og giver øget produktivitet og kvalitet er for længst dokumenteret.

Alligevel vælger man ofte at plukke det i metoden, man synes bedst om og som nemmest glider ned. Man fravælger det besværlige – f.eks. det, der handler om ledelsesprincipper, samarbejdsform, adfærd og gamle/dårlige vaner.

Dette gøres med argumentet: ”Vi er helt anderledes hos os, så derfor vil ”princip X” slet ikke virke her. Her må jeg altid skuffe folk og sige, at nej, de er ikke en pind anderledes end andre organisationer i samme branche, hvor de stryger afsted på den agile bølge.

Nøjes I med at plukke enkelte dele ud, vil I alligevel se forbedringer. Typisk får I lidt større transparens og tættere dialog mellem team og kunde. Det alene betyder, at I rammer rigtigere i.f.t. jeres kunders behov. I bruger måske nogle nye begreber, men gør ikke for alvor op med jeres gamle ledelsesform og silotænkning. I kommer derfor ikke i nærheden af det optimeringspotentiale I har, men lidt sker der da.

Det kan blive værre: Lader I jeres nye agile teams køre uden styring og retning, og har I ikke tilknyttet en Product Owner, som virkelig kender de forretningsmæssige behov og udfylder rollen, så vil det være helt tilfældigt, hvor jeres teams bevæger sig hen, og I vil ikke vide, hvad der kommer ud af jeres agile initiativ, hvilket tit er ingenting.

Der findes desværre ingen hurtige genveje til organisatorisk agilitet

Lad mig opsummere: Når I går igang med jeres agile transformation:

  1. Gør jer klart, hvad I vil opnå
  2. Sæt nogle pejlemærker op, så alle ved, hvor I vil hen
  3. Mål om tingene går den rigtige vej
  4. Accepter, at denne forandringsproces er kompleks og tager tid

Men hvordan kommer vi igang med alt dette? tænker du måske. Her er svaret:

Kontakt mig på, hvis I vil have adgang til en velafprøvet vej mod organisatorisk agilitet inkl. målinger. Så sparer I besværet med at opfinde dem selv.

Posted in Agil god praksis, Agil modenhed, Agile, Agile implementation, Agile transformationer, God praksis, Ledelsesansvar, Organisatorisk agilitet, Projektmetode, Uncategorized | Tagged , , , , , , , | Leave a comment

I HATE Transparency!!!

When I work with clients to help them transform towards higher organizational agility, I get lots of negative reactions to agile key principles. To many, these principles seem counter intuitive to their current way of working. But what disturbs the agile opponents the most is the need for transparency, which is one of the fundamentals in e.g. Scrum and Kanban. And, by the way, a prerequisite for improvement.

Even if most buy in to the idea that if you cannot see what happens in your system, i.e. your project, your department, your team, etc., you do not have a baseline for improvements and you cannot react sensibly and timely to whatever is disturbing the flow (=progress) in your system. I often experience that people resist to show what they are working on and how. This happens at the individual, the team, and the managerial level. But why?

Well, mainly out of fear of making it visible that:

  • All – managers too – make mistakes
  • We may not handle dependencies very well
  • We do things that don’t really make sense
  • Some are not as busy as they should be (and pretend to be)
  • We are not in control of our processes
  • We do not produce the results we could

To cut a long story short, many don’t want to know, and are afraid of discovering what is really going on. When you can see the “bad stuff” in your system, it will most likely point to something you or your team could actively do something about. Transparency makes it difficult not to react on what you discover and just let the “bad stuff” continue. It’s much easier to pretend that everything is OK.

Where does fear of transparency come from?

Well, 3 answers apply:

  1. Culture
  2. Culture
  3. Culture

If errors are not accepted in your company, you will most likely want to hide your mistakes. Transparency makes that impossible.

If top-down management is the norm in your company, you are not expected to question the orders you get. Even if you can clearly see that they will lead in the wrong direction. Managers that thrive on this management style will work against transparency, as this would put a big finger on the sore spots of their decisions, strategies etc.

If it is (silently) accepted in your company that not all employees are equally busy, and that some do not assume responsibility or show leadership, then your not-so-busy colleagues will oppose to transparency. They don’t want to be “found out”.

If any of these three situations apply, agile will probably not be the right choice anyway, so don’t waste your time and money.

The Spice Girl Question: “Tell me what you want, what you really, really want!”

If, on the other hand, you have decided that you do want improvements in:

  • productivity
  • time-to-market
  • employee satisfaction
  • customer satisfaction
  • quality

which are examples of good things that an agile approach usually brings, you need to carefully think about and understand what is driving your wish for higher agility. It might be one or more of above examples.

And WHEN you know what is driving the decision, you need to decide what method and approach can best get you to the desired end-point.

Agile looks deceivingly simple, but….

Whether you will succeed in making e.g. Scrum, Kanban, or SAFe work in your context will depend on whether you and your colleagues succeed in changing the company culture, old habits, and – not least – your mindsets.

You don’t put on an agile shirt on Monday morning, and “bang!” you are agile. Changing behavior is a big thing, and affect people on the personal level. You might need to change habits that are 5-10-20 years old. This does not happen overnight. It takes practice, will, courage, and time.

Once you know why you want higher agility and how you intend to get there, you need to train people. No matter how simple Kanban, Scrum, or SAFe looks on the surface, they are all quite complicated systems. Getting a new method to work requires training at all levels in the organization.

Don’t fall into the trap of educating only a few Scrum Masters or Product Owners, or sending a few on a Kanban or SAFe training course. A few people don’t stand a chance when it comes to changing a company’s culture, habits etc.

Agile systems only work when managers know how to interact with their agile teams, when business people understand the need for their availability for prioritization, direction, etc., and agile teams know what is expected from them.

Going agile requires investments, stamina, and time. But the investments will be paid back many times, if only you have a bit of patience.

So to sum up: Do ‘go agile’ – it really works! – but do it consciously!

Posted in Adopting agile, Agil god praksis, Agil modenhed, Agile, Agile implementation, Agile transformation, Change Management, Good practice, Management, Organizational agility, Transparency, Uncategorized | Tagged , , , , | Leave a comment

Debunking 3 big myths about Kanban

Yesterday one of my guest post was published on the Kanbanize blog. The post was inspired by some real-life experiences I have had working on agile transformations for various clients but certainly kick-started by an incident on the private level.

At a small birthday party we all had to present ourselves and what we were doing professionally. When it was my turn, I told the other guests that I was writing a book about Kanban. One of the guests being an IT professional said:

“But how can you write a whole book about Kanban – surely this must be a very thin book!”.

That made me think about the many misunderstandings about what Kanban is and the lack of knowledge of what it can do to improve service delivery. It also made me think about the myths that I have had to debunk over and over again during my Kanban training and coaching activities.

I decided to focus on the 3 biggest myths that I have been presented to over the years:

  1. Kanban is just a few columns on a whiteboard where a lot of sticky notes are moving back and forth at random.
  2. Kanban only works in small support teams.
  3. Kanban is not “real Аgile”

You can find my guest post here: Debunking 3 big myths about Kanban and read about why these three myths are…. only myths.


Posted in Adopting agile, Agile implementation, Agile transformation, Kanban, Uncategorized | Tagged , , , , , | 2 Comments

Hvorfor ”leger vi agile”, hvis der ikke for alvor er et ønske om forandring?

I de seneste år har jeg arbejdet med agile transformationer og projekter. Både store og små. Min baggrund for at gøre det, er 10 års praktisk erfaring med agile metoder. Jeg underviser i Scrum og Kanban og coacher, så man vitterlig får en agil implementering og ikke bare vandfald i forklædning.

Siden jeg startede Xvoto, har jeg nørdet i det, jeg havde mest lyst til, nemlig agile metoder og systemer. Vi samarbejder bl.a. med Lean Kanban Inc. og PMI som agile eksperter, så selvom Xvoto ikke er en af denne verdens McKinseyer, så oplever jeg bred anerkendelse af vores faglighed. Det man nørder med, bliver man tit god til…

Jeg skriver artikler, holder foredrag og tør stikke snuden frem. Det gør jeg for at udvikle mig og holde mig helt ude på forkanten.

Og hvorfor fortæller jeg så det?

Det gør jeg, fordi jeg igen og igen oplever, at på trods af den erfaring og ekspertise jeg bringer med til dem, der har bedt om – ja, faktisk købt – min hjælp, så slås der mange krumspring for at undgå at foretage de ændringer, der skal til for at få en agil transformation, der giver de mærkbare gevinster, man er ude efter.

Er det ikke ulogisk?

Sund fornuft og sund praksis følges ikke altid ad

Nej, det er ikke så ulogisk endda.

På ledelsesniveau læses rapporter og statistikker, udgivet af diverse analyseinstitutter, flittigt. F.eks. dokumenterer Standish Group, PMI m.fl. entydigt, at agile virksomheder klarer sig bedre end andre. I Scrum- og Kanban-verdenen har man målt optimeringsgevinster på flere hundrede procent.

Hvem vil ikke gerne have det? Det vil enhver ledelse da! Og ”de tunge drenge” siger jo, at det virker!

Når de så samtidig kan se, at både Scrum, men især Kanban er ret simpelt at komme i gang med, så starter man, uden at vende den agile mønt for at se, hvad der står på bagsiden.

På bagsiden står bl.a.:

  • Adfærdsændringer er nødvendige på BÅDE ledelses- og team-niveau
  • Tillid og en vis fejltolerance, er en forudsætning
  • Nedbryd siloer og undgå suboptimering
  • Nye ledelsesprincipper og ofte færre ledere
  • Vigtigt! Der står TRANSPARENS i flammeskrift

Med en agil transformation igangsætter ledelsen noget, der dels kan save den gren over,  de selv sidder på, og dels sætter spotlys på de dårligdomme, der er i systemet. Altså det system, de selv har stået i spidsen for, måske i årevis.

Det kræver mod og selvindsigt og kan naturligvis virke skræmmende.

Det gælder også på team-niveau.

Man skal vitterlig være interesseret i organisationens bedste, for uden betænkeligheder at gå ind i eller stille sig i spidsen for et agilt initiativ.

Langtfra alle har det fornødne mod, og dét er en væsentlig grund til, at sund fornuft og sund praksis ikke altid følges ad. Det er for skræmmende og 100 gange lettere at fortsætte, som man plejer.

Det gør ikke ondt

Det føles trygt

Det er bare ikke sådan man skaber forandring, forbedringer og innovation

Man får ikke det hele for det halve

Som nævnt: Agile organisationer klarer sig bedst. ”Going agile” er således en klog og rationel beslutning. Og det betaler sig!

Derfor er utallige virksomheder i gang med agile transformationer. Mange gør det bare, uden at ville betale prisen. Man kan ikke bare pege på sine medarbejdere og sige: ”Kunne I ikke lige blive lidt mere agile?” samtidig med man på ledelsesniveau fortsætter som hidtil.

Er det sådan, man tænker ”agile”, så får man:

  • Lidt mere transparens. Det er fint, men det alene giver ingen agil organisation
  • Mere af det, man havde før – bare med nye mærkater
  • Frustrerede medarbejdere. Altså dem, der forstår agile
  • En undskyldning for at sige: ”Vi er SÅ anderledes – det er klart, at agile ikke virker her”
  • Hvis man får ekstern hjælp, et alibi for at sige: ”Vi arbejdede med eksperterne – ikke engang de, kunne få det til at lykkes”

Det er bekvemt, nemt og meget letkøbt.

Jeg lægger ikke igen ryg til halvhjertede agile tiltag

Jeg bliver frustreret og stresset af at være en del af noget, jeg ved, ikke kan fungere, så jeg har taget en beslutning:

Hvis man ikke ved, hvad man vil opnå med sin agile transformation eller vil uddanne sin organisation, så den står klar, når det agile tog kører, eller hvis man vil ”tilpasse agile” til ukendelighed, så siger jeg pænt nej tak til at være med.

Jeg spilder min tid og virksomheden deres penge på noget, der alligevel aldrig kan lykkes.

Men de organisationer, der er ægte interesserede i at optimere deres processer, systemer eller arbejdsform v.h.a. agile, med DEM vil jeg med største glæde og entusiasme dele alt hvad jeg ved efter 10 år med næsen i det agile spor.

Er det jer, så ringer I bare! Nummeret er 5151 9297. Jeg står klar! 😊


Posted in Adopting agile, Agil god praksis, Agil modenhed, Agile, Agile implementation, Agile transformationer, God praksis, Kanban, Ledelsesansvar, Organisatorisk agilitet, Scrum, Uncategorized | Tagged , , , , , , | Leave a comment

It’s all about change and change is here to stay

Happy New Year and welcome 2017 with all the change that it may bring!

2016 has gone almost too quickly. I have been absorbed in a couple of big organizational agile transformations, and change has certainly happened there. Going from a traditional mindset to an agile is a paradigm shift, and the step is quite a big one. But it can be done, and it doesn’t have to be so difficult.

It’s all about managing change

Resistance to change

Fear of change

Unwillingness to change

But fortunately, there are also frontrunners, and people who are curious about what good things agile might bring. They are your helpers.

But why is the shift from the classic to an agile mindset so difficult? Agile methods are supposed to be simple!!

Just looking at the Scrum guide, or papers about Kanban might tempt you to thinking that being agile is piece-of-cake. I don’t want to spoil anybody’s dreams, but this particular dream is only wishful thinking.

Work with Scrum or Kanban is based on the assumption that teams and organizations live by a set of values. Here they are:


But can we assume that people readily buy into or understand the value of transparency, commitment, respect, focus etc.? No, of course not! Actually, I have seen teams acting quite the opposite to these values and yet believed they were very agile.

They were doing mechanical Scrum or proto-Kanban, but had no real understanding of how agile systems work. Thus, the real benefits did not emerge.

The change of mindset is just as difficult for managers, many being strongly opposed to agile. They may support the shift in words, but in actions they work against it. Though there is massive evidence of improved service delivery or success with projects in agile organizations, they are not tempted to let go of their power. Even for the greater good.

Old organizational hierarchies are working against agile principles e.g. team self-organization, and delegation of decision power. Getting from the old ways of control-and-command to a real pull-system is not trivial. You must genuinely pursue this change, or it will not happen.

Meet team members Grumpy, Skeptical, and Know-it-all

I am currently writing a book about Kanban, and my angle is practical. What do you do, when reality is far from the wonderful picture of the competent team, the always-available Product Owner, the motivated individuals, the supportive managers that e.g. the Scrum guide tries to paint?

What happens when the prerequisites for making Scrum or Kanban work are not meet? Does it mean that you should give up? No, of course not, but you must be realistic about what can be achieved, and you must articulate the end goal.

Agile methods cannot change a bad culture, solve problems or remove complexity, but they sure put the spotlight on those. Then it is up to the organizations/teams how they want to react on the findings. To do nothing is also a choice. Probably a bad one.

The top-5 reasons for not wanting to embrace agility

In my work with customers I have met team members like Grumpy, Skeptical, and Know-it-all. Fortunately, a good many positive people too. But from the three first-mentioned you will typically hear the following reasons for resisting to become agile:

  1. We are SO different. Agile will never work for us
  2. Are you saying that what we have done for the past many years is wrong!!!
  3. We already have the optimal process in place. Agile will make things worse
  4. We are educated people, we have already figured out the best way for us
  5. We have worked with visual boards for ages – you can teach us nothing

I could write a lot about how to react to this, but it sums up to the 3 of them not having understood that they are part of a system that is greater than themselves, and that sub-optimization is bad for productivity.

More “dictatorship”, more action. less talk

Since there are as many opinions about agile as there are members in an organization, it’s likely that you will never reach consensus about your agile approach. Therefore, the people in charge of the change must articulate what they want to achieve.

Together with an agile specialist, they must determine where they want to go and the approach to getting there, and then insist that everyone follows that path. On the change journey, there will be plenty of time to explain how the values fit the approach, how good agile practice will lead to continuous improvement etc.

P.S. A hint: where Scrum is often disruptive and harsh on an organization, Kanban is the humane path to agility. With Kanban you look at the work, and seek to balance supply and demand.

PPS: My Kanban book will give you many more details

Posted in Adopting agile, Agile transformation, Change Management, Good practice, Kanban, Management, Organizational agility, Project efficiency, Scrum | Tagged , , , , , , | Leave a comment

Agile transformationer skal være i øjenhøjde med organisationen

Projekter skal hurtigst muligt skabe værdi for kunden. Det sikrer agile metoder . Men de virker kun optimalt, hvis hele organisationen taler det samme sprog og ledelsen er med på den agile vogn

Projekter, der er for længe undervejs. Time-to-market på nye produkter eller services, der er længere, end den behøvede at være. Produkter, der ikke opfylder brugernes behov. Lyder det velkendt?

I kan sikkert nikke genkendende.

De teknologiske fremskridt går så hurtigt, at det vil være de organisationer, der hurtigst kan omstille sig til ændrede markedsvilkår, der vinder.  Ville det så ikke være smart at gøre noget ved det?

I klassiske projektmetoder stiller man alle krav til produktet fra start, d.v.s på det tidspunkt, hvor man ved mindst. I den agile tilgang beskriver man – uanset hvad projektet skal levere – ikke alle detaljer fra start. Kunden beskriver det, der med sikkerhed er behov for, og så kommer detaljerne på senere. Man fremviser produktet undervejs i tilblivelsen, så kunden løbende kan verificere, at han får det, han virkelig har brug for og ikke det, han troede han havde brug for ved projektets start. I agile projekter er man klar til at håndtere ændringer i takt med at kunden bliver klogere på, hvad der kan lade sig gøre.

Kunden skal meget tættere på – så kom bare nærmere!

Mange organisationer er vant til at køre projekter efter de klassiske metoder. De har udviklet et fælles projekt-sprog og mener, at der er et solidt fundament for at drive projekter. Men ofte udebliver resultaterne, og så opstår ønsket om at ændre sig i en mere agil retning, men hvordan starter man en agil transformation?

Når organisationer arbejder agilt, er kunden og andre interessenter tættere på projektteamet hvilket giver den korteste vej fra behov til beslutning og eksekvering. Det skaber fokus. De traditionelle hierarkier giver for lang ventetid og for mange tilbageløb. Det er det spild, der skæres væk, så projekternes gennemløbstid kommer ned.

Det agile mindset er et paradigmeskift


Det agile mindset skal spredes til hele organisationen. Ikke kun i projektteamet. Agile metoder fungerer kun, når ledelsen bakker op, og der er faktisk tale om et paradigmeskift.

Agile er ikke bare en simpel proces, der kan rummes i et A4-ark. Det er et sæt nye værdier og en ny kultur, der skal indarbejdes, hvor topstyring ikke virker. I agile systemer uddelegeres mange beslutninger til de forretningsansvarlige og projekt-teamet, og det nytter ikke noget at være fokuseret på at undgå fejl, da det agile tankesæt netop handler om at prøve sig frem så man finder den bedste løsning.

Agilitet i øjenhøjde

Når jeg rådgiver virksomheder, der gerne vil være mere agile, så bruger jeg mit koncept, som hedder “kontekstbaseret projektledelse ®”. Med det som udgangspunkt ser vi på:

  • Hvor projektmoden virksomheden er
  • Hvor forandringsparat organisationen er
  • Hvilke problemer man gerne vil have has på
  • Hvordan governance-modellen ser ud

Der findes ikke en model, hvor ’one size fits all’. Projekter og kompetencerne hos projektlederne er jo forskellige, organisationer og projektteams er forskellige. Det handler om at vurdere hvor virksomheden er, hvor den gerne vil hen, og hvilke udfordringer vil man gerne have løst. Så arbejder vi med det, der gør mest ondt først, så tager vi det næste, osv. På den måde skabes de løbende forbedringer, som virkelig flytter noget, og gør det varigt.

Agil transformation – fra tanke til implementering

  1. Find ud af, hvor din organisation er i forhold til agil parathed.
  2. Afklar hvilke problemstillinger organisationen ønsker at gøre op med?
  3. Start op i et pilotteam, og brug erfaringerne til at afgøre, hvordan der kan rulles ud i større skala.
  4. Få styr på hegnspæle og råderum, keep it simple – og gå så bare i gang!

Har I også brug for at præstere mere uden at blive flere, så lad os sammen kigge på, hvordan I kan blive mere agile. Det er faktisk ikke særlig svært eller særlig dyrt at komme i gang. Det kræver bare lidt vedholdenhed 🙂

Kontakt mig på 5151 9297, så finder vi den nemmeste og bedste vej for jer.



Posted in Adopting agile, Agile, Agile implementation, Agile project management, Agile transformationer, God praksis, Organisatorisk agilitet, Uncategorized | Tagged , , , , , , , | Leave a comment