“Agilewashing”: An expensive way to achieve hardly anything

Let me start by introducing you to my new concept: “Agilewashing”. (At least I have not heard or seen anyone else use the concept yet). “Agilewashing” most likely does not happen consciously, but probably because the understanding of agile systems is lacking. To me it means the following:

  1. Organizations work “Scrumish” or “SAFe-like”. They pick a few (easy) elements out and leave the rest. Often, they work in timeboxes (not always of the same length), and call them “Sprints or PIs”, they name a Product Owner, and maybe a Scrum Master, but they leave out the important stuff.
  2. People use a (messy) task board and call it Kanban. They use none of the 6 Kanban practices, they don’t measure lead times to manage flow, they don’t work with upstream options and downstream commitments. Again, they leave out the important stuff.
  3. Organizations and/or teams believe they are agile, although there is no evidence of agility. Nothing is being measured that can give proof of actual team or organizational performance, predictability, or improvements. Value creation often happens at random, and goals are rarely met.

If you pick and choose only the elements of a method or framework that are easy to implement in your organization, you will not get what you are after, i.e., higher agility. You will probably get a bit more transparency, but other than that you will get what you always got but call it new names.

However, working this way often makes organizations and teams feel agile. But feeling something is not the same as knowing. Feeling agile is not the same as being agile.

Why do agile initiatives often end like this, and what can you do about it?

To answer those questions let us look at why organizations want to become agile in the first place. When I talk to managers, they tell me that they want:

  1. More deliverables completed quicker with the same people. I.e., faster time to market
  2. To be able to see who is doing what. I.e., more transparency
  3. Higher predictability. I.e., they want their teams to deliver what they commit to

That fits very nicely with the results presented in the State of Agile report from 2021. Below are the top 6 reasons for wanting higher agility:

  1. Enhance ability to manage changing priorities (64%)
  2. Accelerate software delivery (64%)
  3. Increase team productivity (47%)
  4. Improve business and IT alignment (47%)
  5. Enhance software quality (42%)
  6. Enhance delivery predictability (41%)

These reasons have not changed much compared to previous years’ reports, but they have sometimes changed places.

Having read the State of Agile report, I took a trip down memory lane to the days when I was working as a Project Manager (PM) at Digital and got my first PM certification (the PMP). That was back in 1999. Those days, more than 20 years ago, the goals were the same.

The message from Digital headquarters was: “We want you PMs to be more predictable when you deliver projects. We want fewer delays and failures, your projects must be delivered quicker, and in better quality. Therefore, you must all be certified”. In fact, that was an order. Digital wanted to streamline the way we project managers worked, they wanted more predictability and improved results. For good reasons.

Of course, these were and are goals worthwhile pursuing, but just like the classic PM methods were not the fail-safe success-booster that many hoped for, it does not look like 20-25 years of use of agile frameworks and methods has given the wanted results either. People are still pursuing the same goals.

Although the agile wave has rolled for more than 20 years (in 2021 Scrum celebrated its 25th anniversary), and still more companies are working with Scrum or SAFe, (the latter has been on the market for + 10 years), the problems with unpredictability, failed projects, etc. have not been fixed.

At this point, I would like to mention, that it is of course better to have a shallow, but somewhat methodical approach instead of nothing.

‘Agile’ is supposed to be so efficient, so why do we not always see significantly improved results?

I have been involved in many agile initiatives as a consultant, trainer, and coach. I have worked with many agile teams and trained them in Scrum and SAFe, to optimize the way they worked.

I have concluded that unless you work with very disciplined and mature teams or organizations, these initiatives are likely to be only moderately successful. But before getting deeper into this, let us look at what the State of Agile 2021 says:

Top 6 challenges to reaching higher agility:

  1. Inconsistencies in processes and practices (46%)
  2. Cultural clashes (43%)
  3. General organizational resistance to change (42%)
  4. Lack of skills and experience (42%)
  5. Absence of leadership participation (41%)
  6. Inadequate management support and sponsorship (40%)

Again, this fits well with my own experiences. Working with Scrum or SAFe requires quite a bit of organizational and team maturity, and an appetite for change to make them work and be successful. Both frameworks are quite complex, and there is no magic button to press, and POW! everyone knows what Scrum and SAFe are all about. They are neither easy nor intuitive.

No method, framework, or standard can change (bad) behavior, culture, or low maturity, and they cannot fix a lack of skills and experience. Only strong leadership can facilitate such changes, and it takes time. There is no easy fix or a shortcut to agility.

As points, number 5 and 6 above indicate, strong leadership, which is a prerequisite for making the needed changes towards new ways of working, is often missing.

If teams are undisciplined and immature, you can coach Scrum and SAFe practices day and night, you may have all the good arguments, but many will still resist change because they are perfectly happy with the way things are. Many feel that they have more to lose than to gain.

Many like working as individuals in groups instead of in teams, and are not as excited about transparency as their managers may be. Managers, on the other hand, like to make decisions and are not always happy to delegate that power to others.

If you dig a little below the surface, you will see that both Scrum and SAFe are very complex. Particularly SAFe.

Sitting at your desk or being in a training session it’s easy enough to talk about team goals, cross-functional teams, T-shaped people, a lean-agile mindset, agile behavior, agile leadership, values, inspect and adapt, etc., but how to make it all work in real-life scenarios?

Businesses are full of specialists that like being just that. There are often many systems (including legacy). All the teams that I have met support more than one single product/system, so how can you organize them around one single product or value chain?

How can you have one single Product Owner for a team handling multiple systems for several organizational entities? And do you really want cross-functionality when it comes to legacy systems? Would it not be OK to have only one single specialist knowing a certain legacy system in and out?

And last but not least, how will you make Scrum or SAFe work in immature teams (there are more of those than you would expect), that do not really see the need for consistent processes and practices, that lack discipline, and maybe skills too? Teams, that become defensive if you suggest that there might be improvement opportunities to be found?

You may reorganize everything according to Scrum or SAFe guidelines, but reorganizing will not fix all the above obstacles to making Scrum or SAFe work as intended. It is more likely to create disruption and confusion, and you are also likely to have cut so many corners that Scrum and SAFe have become an illusion. I.e., “Scrumish” or “SAFe-like”.

I have now mentioned some of the main reasons why organizations will not get the improvements they were after when they decided to implement Scrum or SAFe. They will not see significant, measurable improvements even though they have gone through an expensive transformation, often led by external consultants and agile coaches.

Agilewashing in action

This is where it becomes difficult and where the agilewashing often begins. If you have spent millions on transforming your organization and reorganizing it in the hope of making it more agile, you are probably not very tempted to announce that you gained almost nothing from it. People may feel that it was a success, but they don’t measure success.

As mentioned, most organizations will get a higher level of transparency when they “go agile”, and sometimes also higher employee satisfaction, and that is good. But when it comes to predictable deliveries, and teams delivering what they commit to in the right quality, the results are not overwhelming. Most teams that I meet do not measure their results, and they prefer not to. Therefore, they don’t know if they are improving or not.

I have yet to meet an organization that can show data from “the before and after” their agile transformation and objectively knows if it has been worthwhile doing. I have seen no data showing what actual improvements have been made.

You may wonder why I, an agile consultant, coach, and trainer would point out this dark and well-hidden side of agility? I do that because I am ambitious on behalf of the organizations I work with and want them to get more than “feel-good-agility”. I want them to get real, evidence-based agility, and fortunately, that is not an impossible ambition.

How to get past “feel-good-agility” to evidence-based agility?

Well, there are several ways. I would never say that Scrum or SAFe cannot work – I just say that it is more difficult than people usually think. If you are lucky enough to work in a mature organization with mature teams, you will always find a way to make any framework or method work. If you don’t, you should lower your ambitions.

When working with immature teams, it pays off to be very clear about what you want them to achieve and be realistic about what you can expect them to achieve both short- and long-term. You must set a clear direction because they will not figure it out by themselves. Not always because they don’t want to but because they lack the skills and experience. (See point 4 above).

But independent of your teams’ maturity, you should measure their productivity and predictability, so you know where they are and what to improve. You need data to do that.

However, the best you could do instead of trying to fix the unfixable would be to look in a different direction and use the Kanban method instead. Kanban works independent of maturity level, it works for all kinds of knowledge work, and it scales.

The best part is that you do not have to reorganize or introduce new roles that are difficult to understand. You simply start with what you already do and improve from there. Therefore, it is so much simpler and cheaper to introduce Kanban as your path to agility.

David J. Anderson defines the Kanban Method this way:

“Kanban is pragmatic, actionable, evidence-based guidance”

The pragmatic part is important because it means that it is not “all or nothing”. Immature teams can start with a few of the simplest practices and make evolutionary improvements. More mature teams can go all-in and apply more or even all the Kanban practices and principles. Thus, you respect the organization and the teams for where they are, and you don’t expect the impossible.

With Kanban, you simply infuse realism into the agile equation, and you don’t need a bus full of consultants or hire a lot of coaches to make it work.

The evidence-based part is extremely important too. Out with vanity metrics and in with measuring lead times. Lead times tell you precisely what you have been able to achieve by looking at historic data. They are not guesswork or wishful thinking. Lead times are reality.

You may not like what you see, but even if your lead times prove to be inexplicably long, now at least you know, and you can analyze where in your system the obstacles to flow can be found. Then you can begin to fix the system.

Knowledge about lead times is the only metric you need if you want to know precisely how your teams are performing. They will show you what improvements to go for to make a significant difference in delivery speed. Kanban is data-driven and takes you away from crystal balls and gut feelings.

As an opposite, a metric like velocity only tells you if you have stability, but not if you are stably poor, stably medium productive, or delivering value stably fantastic. It may feel good to have some kind of stability, but it does not tell you much about actual performance. Therefore, why not combine velocity with lead time?

The conclusion

Organizations (of course) want higher agility but often jump into agile waters without analyzing what it takes to make the different agile frameworks or methods work. Therefore, people often choose a path that is not fit for purpose in their situation and context, and they don’t get the wanted results.

Instead of working “Scrumish” or “SAFe-like”, take the safe bet and go for the Kanban Method instead. This will lead to agility. Slower for immature organizations and teams and quicker if the maturity is higher.

The Kanban Maturity Model (KMM by David J. Anderson and Teodora Bozheva) provides you with concrete guidance concerning what next steps to take to move to the next level of maturity and agility.

If you don’t do it already, start to measure. Lead time is the strongest metric of them all. It gives you hard evidence of team performance. Vanity metrics may make you feel good, but do not lead to much improvement.

Be realistic about what your organization or your teams are capable of and choose an agile path that fits. Anyway, reality always wins.

This article was written by Annette Vendelbo. She is an agile specialist and realist working as a consultant, coach, and trainer via her company Agile Agenda

Posted in Adopting agile, Agile implementation, Agile management, agile realism, Agilewashing, Enterprise agility | Tagged , , , , , , , | Leave a comment

Agil dit og agil dat – agil ”buzz buzz” – agil mig her og der… Den usminkede sandhed om ”agile” set gennem en agil coach’s øjne

Jeg vil lige starte med at lufte min glæde over at være kommet igennem den hårde akkrediteringsproces for Kanban coaches (AKC) for et par dage siden! Jeg blev akkrediteret af den internationale organisation, Kanban University, der kører de nok mest kradsbørstige uddannelsesforløb inden for det agile felt, som man kan finde på kloden. Det kan måske overraske, hvis man er en af dem, der tænker, at Kanban bare er en opgavetavle. Det er det så langt fra, og jeg er stolt af at være kommet igennem nøglehullet. Det er nemlig ret snævert.

Dér stod jeg så med min AKC, og så var det, at jeg kom til at tænke på en række avisartikler og LinkedIn opslag, som har gjort nar af, at alting skal være åh så agilt i dag. I en af artiklerne får vi oven i købet at vide, at ordet ”agil” er gået hen og blevet et bandeord. Og flere kendisser har harceleret mod begrebet efter at have læst et jobopslag, hvor ordet var gentaget igen og igen og igen. De syntes, at brugen af ”agil” i jobopslaget – og i det hele taget – tangerer kvalmegrænsen og er blevet latterligt. Man bruger begrebet i sammenhænge, hvor det ikke giver mening overhovedet.

Måske bliver du overrasket, men jeg er faktisk tilbøjelig til at give disse debattører ret i nogle af deres synspunkter. Det, der på den anden side ærgrer mig, er, at denne skeptiske holdning til alt, hvad der lugter agilt, kan gøre det svært for agile nørder som mig selv. Lad mig uddybe hvorfor:

Jeg er agil ekspert, underviser, coach, konsulent, foredragsholder og forfatter. Jeg lever af at hjælpe virksomheder med at få sat skub til deres agile ambitioner og finde den vej, der er bedst, enklest og billigst for dem. Derfor kan jeg ikke komme udenom at bruge ”A-ordet”. Hvad skulle jeg ellers kalde det?

De sidste mange år har jeg brugt det meste af min vågne tid og en ordentlig sjat penge på at uddanne mig og sætte mig dybt ind i, hvordan agile systemer og de mest anvendte metoder virker, og hvad der skal til, for at de overhovedet kan virke. Denne støvsugning af ny agil viden stopper aldrig, for jeg kan ikke lade være! Dét er til mine kunders absolutte fordel.

Jeg afskyr enhver form for agilt plattenslageri. At arbejde agilt er hverken let eller intuitivt, og enhver, der påstår, at det er ”bare lige” at ændre DNAet i en organisation og gå fra en klassisk til en agil eller for den sags skyld fra én agil til en anden agil arbejdsform, burde smides på porten.

Hvad betyder det egentlig, at være agil?

Lad mig lige give dig en definition på, hvad agilitet er: ”Agilitet er at levere det rigtige stykke arbejde på det rigtige tidspunkt”. Det lyder da meget fornuftigt, ikke? Det lyder måske ligefrem som logik for burhøns, men det er beklageligvis alt andet end nemt. Det er bl.a. fordi, de fleste virksomheder er organiseret på en måde, der i stor stil spænder ben for at arbejde på en måde, hvor man rent faktisk leverer de rigtige ting til den rigtige tid.

De fleste organisationer er bygget som siloer med afdelinger, teams eller projekter, der får lov til at suboptimere på livet løs: ”Så længe det går godt hos os, så pyt med, hvad der sker i de andre teams eller projekter”. Man gør det ikke, fordi man er ond, eller ønsker noget dårligt for sine kolleger, man gør det af gammel vane og fordi, der slet ikke er nogen incitamenter til at tænke på tværs. Der måles ofte på en måde, hvor man kan blive straffet på sin egen økonomi, hvis man tænker på tværs, og så er man jo nærmest idiot, hvis man gør det alligevel. Også selvom man selv kan se, at det ville være for det fælles bedste. ”Money talks”, som man siger.

Selv et agilt framework som Scrum belønner i udgangspunktet ingen for at tænke ud af sit eget team. Man fokuserer på sit eget teams mål og ikke, hvad der sker til højre eller til venstre for ens team. Det er godt nok meningen, at man ”by-the-book” skal være krydsfunktionel, og at man i sit team skal kunne lave alt fra start til slut. Men velkommen til virkeligheden. Det er nemt på papiret, men sådan foregår det sjældent. Jeg tør ikke skrive ”aldrig”, selvom jeg aldrig selv har set eller hørt om andre, der har set sådan et team med deres egne øjne. Der skal jo nok sidde et enkelt team eller to derude et sted, som faktisk er lykkedes med at blive krydsfunktionelle.

Så længe der ikke er styr på, hvordan man får en opgave eller et projekt hele vejen igennem, fra det tidspunkt, hvor en eller anden får en lys ide, til han eller hun står med resultatet i hånden, så vil man løbe ind i myriader af forsinkelser. F.eks. når en opgave skal overleveres fra det team, som er færdige med deres del, til det næste team, der ikke er klart til at tage imod og arbejde videre med opgaven. Eller når man skal bruge ham Peter fra den anden afdeling, som ikke har tid lige nu.

Det er typisk et vilkår, at man er afhængig af flere teams’ bidrag til festen, og bl.a. dér ligger en stor hund – formentlig en Grand Danois – begravet. I snitfladerne, hvor halvfærdige ”dimser” ligger og venter – eller endnu værre – sander til. Eller aller værst: aldrig bliver brugt. Det giver et vanvittigt spild af tid og knappe ressourcer, og det værste af det hele er, at det kan undgås.

Ikke ved at ”disrupte” (et andet modeord) sin organisation, og omorganisere den til ukendelighed – det giver utryghed og forvirring, og kommer sjældent til at virke ordentligt. Simpelthen fordi det ikke føles som en logisk måde at arbejde på, selvom det måske ser logisk ud ved første øjekast, når man sidder og kigger på modellen ved sit skrivebord.

Tag i stedet et grundigt kig på Kanban-metoden, som ikke kræver, at man laver noget som helst om i udgangspunktet. Man interesserer sig udelukkende for, hvordan man arbejder med sine aktiviteter, og har fokus på at minimere risici. Bl.a. ved at kigge aktivt på tværgående afhængigheder og interessere sig for, hvordan nye ønsker systematisk og aktivt disponeres og prioriteres i et ”upstream” system. Det sikrer nemlig, at man udnytter sine specialister og andre knappe ressourcer optimalt. (Upstream Kanban er muligvis et nyt begreb, men mere om det en anden gang 😊). Kanban tænker med andre ord i end-2-end systemer.

At organisationer ønsker at blive mere agile og dermed bedre til at ”levere det rigtige stykke arbejde på det rigtige tidspunkt” er vel meget forståeligt. Ville man det modsatte, så ville det først være mærkeligt. Problemet i den sammenhæng er bare, at de færreste virksomheder er klar over, hvad der står på det agile prismærke. Lad mig nævne 2 af de absolut vigtigste ting:

Accept af transparens

Du bliver måske overrasket, men det er langt fra alle – hverken chefer eller medarbejdere – der er vilde med transparens. Det er hamrende svært at skjule dårlige beslutninger, tossede processer, arbejds- og beslutningsgange, eller for den sags skyld dovenskab eller manglende kompetencer og disciplin, i et transparent system. (Alle disse dårligdomme findes både i offentlige og private virksomheder. De private virksomheder har bare et større incitament til at gøre op med dem. De kan nemlig risikere at måtte dreje nøglen om, hvis de ikke er effektive nok.)

Transparens er til gengæld helt afgørende for at kunne foretage de løbende forbedringer, som jo også er en del af det agile DNA. Men man får så ikke kun de velpudsede og nydelige ting at se, man får også alt det, der er mindre kønt – endda decideret grimt. Men at skjule det, man ikke er så stolt af, er en rigtig skidt ide. Man kan nemlig ikke forandre eller forbedre det, man ikke kan se. Punktum!

Accept af at have eksplicitte regler

Det er nemt nok at sige, men tænk lidt over, hvor meget autonomi der ryger sig en tur, når man pludselig skal være helt enige om, hvilke spilleregler der gælder i ens virksomhed. F.eks.:

  • Hvordan skal man prioritere og arbejde med sine opgaver?
  • Hvordan bryder vi tingene ned, så vi kan være sikre på, at vi har fået det hele med?
  • Hvordan kan man fastholde fokus på det, man har igang, så man undlader at shoppe rundt imellem de mange aktiviteter på ens to-do-liste?
  • Hvordan skal man visualisere, hvad der foregår?
  • Hvordan sikrer man kvaliteten i det, man laver?
  • Hvordan arbejder vi med afhængigheder og flaskehalse?
  • Fortsæt selv listen – den kan blive lang!

I sådan et system, kan man ikke bare vågne op om morgenen og spørge sig selv: ”Nå, Annette, hvad har du så lige lyst til at arbejde med i dag?”. Det er nemlig fastlagt på forhånd af de regler og (nye) vaner, der omkranser det agile system.

Her mens jeg er i Kanban-humør, så lad mig lige i forbifarten gentage mantraet ”Stop starting – start finishing”. Hvis dette princip var synligt fra ens skrivebordsstol, så ville det pirke til ens tilbøjelighed til at task switche, hvilket de fleste gør hver dag og hele tiden, selvom det er verdens dårligste ide.

Nu har jeg nævnt 2 helt konkrete ting, som jeg ved, notorisk er svære at tage til sig, med mindre man da arbejder i et miljø med høj tillid, forandringsvillighed, stor fejltolerence, uddelegering af ansvar, aktivt lederskab og ansvarlige medarbejdere. Oven i det kommer så alt det bløde med vaner, mindset og værdier, som faktisk er det sværeste af det hele. Fordi vi er mennesker og forskellige.

Prøv at tænke over virksomheden, hvor du er nu eller grav i dine erfaringer. Hvornår har du arbejdet i en organisation, hvor man har kunnet sætte hak ved selv få af disse ting?

Det er bestemt muligt at blive mere agile, og det virker forrygende. Det er bare ikke en gratis omgang, og det er man nødt til at se i øjnene, hvis man skal lykkes med det.

Hvad synes du selv, og hvordan synes du selv, at det går?

Mine kunder siger, at de snakker med mig, fordi de ved, at jeg ved, hvad jeg taler om, og fordi de får rene ord for pengene. Selv har jeg taget en aktiv beslutning om aldrig bare at snakke mine kunder efter munden og give dem det, de tror, at de har brug for. Det mister jeg somme tider opgaver på, for hvem vil ikke gerne have et ”easy fix”? Der er bare det ved det, at der ikke findes noget ”easy fix”. At blive mere agil kræver ”De 3 V’er”:

1. Vilje

2. Vedholdenhed

3. Vaneændringer

Selv når det gælder Kanban, som er den simpleste vej til den agilitet, som så mange stræber efter, så kræver det en anden og mere struktureret OG disciplineret måde at arbejde med sine aktiviteter på. Altså ikke det man konkret gør. Det siger Kanban selvfølgelig intet om, men det system, som man lægger ned over sine aktiviteter, kræver tilvænning. Men nul ændringer giver nul forbedringer.

Jeg har indimellem haft diskussioner med andre agile coaches, der synes, at jeg ’styrer’ for meget, og at forandringer skal opstå spontant i teams eller hos ledelser. Men hvordan forestiller man sig, at nogen skal regne ud, hvad der forventes af en agil medarbejder eller leder, som måske har mange års erfaring med at arbejde på en helt anden måde?

Det er ikke alle i kongeriget, der gider eller har tid til at nørde med agile metoder m.m. Det er som regel heller ikke det, folk blev ansat til. Derfor bliver det langsommeligt, ineffektivt og dyrt, hvis man skal vente på, at vaneændringer og forandringer opstår spontant. Det kræver et blidt skub i ryggen. Lidt ligesom da man skulle tage kørekort, hvor det trods alt var rart, at der var en kørelærer til stede.

Mange ville i øvrigt helst være fri for at arbejde agilt, hvis de selv kunne vælge. Det kræver nemlig en vis anstrengelse at forstå, hvad det skal være godt for, og hvis man oven i købet selv synes, at ”det går da meget godt”, så kan man slet ikke se, hvad alt det agile pjat skal til for.

A close up of a sign

Description automatically generated

Derfor er jeg tilbøjelig til at anvise alternativer og facilitere, at der kommer fart på forandringen, men i en hastighed, hvor folk får sjælen med. Jeg er den største fan af evolutionær forandring (Kanban igen), for den slags forandringer sætter sig som nye gode vaner. Revolutioner sander til.

Jeg vil naturligvis gerne høre, hvordan mine kunder selv synes, at det går, hvad de gerne vil have skal ske og, hvilke ideer de har. Derefter fortæller jeg, hvordan jeg ser på verdenen med den viden og de erfaringerer, som jeg har i bagagen, og så finder vi vejen frem sammen. Det er vel det, man har en ekstern agil coach til.

Hvordan ser man forskel på en halv- og en helstuderet agil røver?

Nu skal jeg pibe lidt: Et af de problemer, som jeg og andre kvalificerede agile coaches har, er bl.a. at enhver halvstuderet røver kan kalde sig agil coach, og det er der også mange, der gør. Men…

  • Hvordan kan man kende forskel på de agile coaches, undervisere og konsulenter som virkelig ved noget og dem, der kun har kradset lidt i overfladen? D.v.s. dem, der måske kan de rigtige agile ord, men ikke forstår agile begreber og systemer i dybden, og derfor får trukket deres kunder eller deres organisation i en dårlig og dyr retning.
  • Hvis “agil” bare er blevet et meningsforladt buzz-word, hvordan skal man så kunne tro på, at der virkelig er noget at hente f.eks. i Kanban-metoden, som jeg selv er vild med, fordi den forandrer og forbedrer uden at ødelægge, og desuden er så langt fra buzz og så tæt på sammenpresset sund fornuft, som man overhovedet kan komme?
  • Hvad når de fleste hellere vil dejse om end at sige: “Næh, vi er faktisk ikke særlig agile”, og i stedet siger: ”Vi er skam vældig agile” uden at være det? Så bliver det at være agil pludselig noget alle kan være, hvis bare de selv synes, at de er det, og det er jo noget vrøvl

Her fristes jeg til at bruge et citat, som jeg virkelig elsker tårnhøjt – jeg mener, at det var Peter Plys, der sagde:

Man kan ikke vide det, man ikke ved!

Godt sagt, Plysbjørn, men hvad har det med ‘agile’ og Kanban at gøre? Det skal jeg fortælle dig:

Hvis man som kunde skal undgå at købe varm agil luft, hvis man skal kunne se forbi alt buzz’en og undgå at blive en del af den lemming-effekt, som desværre er omsiggribende, så kræver det, at man søger viden og sætter sig lidt ind i, hvad ”agile” er for en fisk. Men det burde jo ikke være så meget anderledes end når man skal købe enhver anden vare, hvor man sætter én, der ved noget om den slags varer til at vurdere, hvilken der vil være bedst at investere i.

I stedet for bare at gøre det, som naboen eller konkurrenten gør, og håbe at de har tænkt rigtigt, så skal man aliere sig med én, der kan fortælle, hvad der er op og ned i det agile landskab og fortælle ærligt, hvad det kræver af en organisation at blive agil. Så kan man nemlig træffe nogle langtidsholdbare beslutninger og valg, der passer til ens organisation og kontekst.

Det er i alle tilfælde vigtigt, at man fra starten erkender, at en agil implementering vil være en stor forandring for mange. Formentlig de fleste. Og folk ”regner den ikke ud”. Man skal være virkelig eksplicit omkring, hvad man ønsker, at folk konkret skal gøre anderledes i deres hverdag. Det er ikke nok at sige, at: ”Ja, nu skal du så være med i et selvstyrende team”. For hvad er dét lige? Selvstyrende hvordan? Selvstyrende hvor meget? Hvad betyder det, at den enkelte skal gøre?

Der bruges uhyggeligt mange penge og busser fulde af konsulenter på ”at blive agile”. Jeg er ked af at måtte sige det, men det er ofte skønne spildte kræfter, for de agile initiativer sander ofte til, så snart konsulenterne forlader butikken. De sander til, fordi den vej, man har valgt, simpelthen er så voldsomt anderledes og kompliceret, at den ikke kan holdes i live uden kunstigt åndedræt fra en masse (dyre) konsulenter.

Den valgte metode kan også føles så kontra-intuitiv, at man straks vender tilbage til ”plejer”, så snart man kan slippe afsted med det, og fokus har flyttet sig et andet sted hen. Derfor skal man gå efter en metode, som man selv synes lyder enkel og logisk. Den som man bedst kan se sig selv i, og som ikke ødelægger alt det gode, som man selvfølgelig også gør. Det kræver, at man undersøger, hvad der i det hele taget findes derude, så man kan vælge rigtigt i første hug. Forkerte valg koster kassen, og resulterer i, at man får kastet gode penge efter dårlige, hvis man stædigt holder fast i en metode, som bare ikke kan virke i éns virksomhed p.g.a. kulturen, adfærden, konteksten m.v.

Heeeelt ærligt! Er det ikke en konsulent, der snakker?

Måske tænker du: ”Jamen, hvad med dig selv? Du er da også agil konsulent. Er du måske gratis?”, og ja! Jeg er agil Konsulent med stort K, og nej, jeg er selvfølgelig ikke gratis. Jeg skal jo også have løn. Men konsulenter som mig har kun én dagsorden. At finde den mest gangbare agile løsning til de kunder, der vælger at samarbejde med os. Dét er vores drivkraft.

Jeg er ikke gift med andre end min mand. Jeg har ingen virksomhed bag mig, der hvisker i mit øre, at jeg skal huske at sælge mine kolleger ind. Jeg har kun én vare på hylderne og det er mig selv, og jeg skal ikke stå til ansvar for andet end min egen integritet, og den er høj.

Så for at vende tilbage til starten om ’agil mig her og der’ og ’agil buzz buzz’, så bliver jeg på samme tid voldomt irriteret over, at der bliver gjort grin med agile, for jeg ved, at ”skidtet virker”, når man griber det rigtigt an. Det giver enorme gevinster hele vejen rundt. Det er ikke noget jeg tror, det er noget, jeg ved, for jeg har selv haft hænderne i bolledejen så mange gange.

Men på den anden side, så kan jeg også selv blive træt af, at man bruger ordet agil i flæng. Alt kan og skal ikke være agilt. Det er meningsløst, og for at sige det ligeud – noget forsimplet fis. At forstå agile systemer er en færdighed, som man må bruge energi på at lære sig. Ellers får man kun mere af det, man hele tiden har haft. Bare med nogle andre navne.

Nu er det snart nytår, så hvis jeg kunne få et par nytårsønsker opfyldt, så ville det være, at folk kun brugte ordet agil, når det var relevant, og lod være med ukritisk at hoppe på den agile vogn, før man har undersøgt, om den kører den vej, som man gerne vil bevæge sig hen.

Til slut en lille test til dem, der har lyst

Du har måske opdaget, at jeg har fremhævet de ord, hvor ”agil” indgår i en eller anden form. Jeg har forsøgt at undgå ordet mest muligt, men det er hundesvært, når nu man gerne vil fortælle om fortræffelighederne ved den måde at tænke og arbejde på. Dette på trods af de mange negative vibes, der har været omkring ”agile” på det seneste.

Jeg har talt, at jeg har brugt en eller anden form af ordet 42 gange. Det er trods alt ikke helt så slemt som det jobobslag, som de førnævnte kendisser harcelerede imod.

Hvis jeg nu har talt forkert, selvom jeg har talt efter flere gange, og du kan fortælle mig, at 42 x agil ikke er det rigtige tal, så skriv det, du mener, er det rigtige tal i tråden på Facebook (eller LinkedIn for den sags skyld). Du må også gerne give mig ret i, at ordet står 42 gange. Det er bare for sjov.

Til gengæld vil jeg så tilbyde dig at være med til en premiere til ren indbrudspris. Jeg er nemlig også Akkrediteret Kanban Træner:

Kom med på mit første Team Kanban Practitioner kursus i Danmark den 21/1-20. Din pris er 4.800 kr. excl. moms men inkl. al forplejning OG certificerings-omkostninger. Normalprisen er 6.800 kr. excl. moms, så lige nu kan du springe på et akkrediteret Kanban-kursus med 30% rabat. Jeg oplyser dig din unike rabatkode, som du skal bruge, når du melder dig til. Du kan læse mere her:
Team Kanban Practitioner 21-1-2020

Kurset afsluttes med en internationalt anerkendt certificering fra Kanban University, og du vil stå med rigtig Kanban viden, som du straks kan tage i brug plus et styrket CV.

Alt det her bare fordi nogle havde set sig sure på ”agile” 😊

Posted in Agil implementering, Agil modenhed, Agil realisme, Agile, Agile transformationer, Forandringsledelse, Kanban, Ledelse, Ledelsesansvar, Uncategorized | Tagged , , , , | Leave a comment

“Doing agile or being agile”? Fra agile robotter til proaktive flow managers

Kan du forestille dig, at der i disse dage er nogen virksomhed med respekt for sig selv, der vil sige: ”Nej, her hos os er vi overhovedet ikke agile, og vi overvejer heller ikke at blive det”? Nej vel! Det er ikke særligt sandsynligt. At arbejde agilt – hvad man end måtte lægge i det – er efterhånden blevet standardtilgangen.

Men hvad betyder det egentlig? Det kan faktisk være meget forskelligt, fordi der findes ikke et agilt facit, der har to streger under. Der er mange forskellige måder at gå til det agile på. Der er forskellige metoder og frameworks at vælge mellem, forskellige ambitionsniveauer, forskellig organisatorisk og agil modenhed osv.

Det er nemt at forstå, hvorfor man jagter højere agilitet, for hvis man kan få det agile til at spille, kan man skabe ganske overvældende positive resultater. Problemet er bare, at selv de mest populære agile systemer er meget komplekse (og dyre) at komme i gang med (især SAFe), og agiliteten opstår altså ikke, blot fordi man ændrer sin organisation og giver folk nye titler.

Som agil rådgiver, coach og underviser med +10 års praktiske erfaringer i bagagen fra en perlerække af teams og organisationer, står det helt klart, at der nogle mønstre, der går igen ”derude”. Desværre er der tale om anti-patterns, og det er uanset om valget er faldet på Scrum, Kanban eller SAFe. Disse mønstre trækker i den stik modsatte retning af agil effektivitet.

Det er ærgerligt, dels fordi der bliver brugt enorme summer på (mislykkede) agile transformationer, og dels fordi det giver kæmpe frustrationer over hele linjen, når den store forandring, man har været igennem, ikke giver de resultater, man var ude efter.

Hvad er det så, der går galt?

Det er der flere ting der gør, men her kommer de vigtigste:

  1. At arbejde agilt medfører, at man skal tænke projektarbejde på en temmelig anderledes måde. Men ofte er hverken medarbejdere eller ledere forberedte på den forandring, som en agil implementering fører med sig. Viljen til forandring er heller ikke altid til stede.
  2. Ledelsen sætter sig ikke grundigt nok ind i, hvad det kræver at dreje organisationen i en mere agil retning. Man vurderer primært ”mekanikken” i metoden: Hvilke møder skal vi holde, hvilke roller har vi osv. Erkendelsen af, at det handler om at ændre kultur og vaner – også i ledelsen – mangler. At lave organisationsændringer skaber i sig selv ingen agilitet
  3. Der findes en agil lemmingeeffekt. Det betyder, at de fleste vælger det, de andre gør eller det, der lige nu er oppe i tiden. Der bruges ikke tid nok på at forstå de forskellige agile systemer, så man kan vælge den agile vej, der er det bedste match til ens organisation og det, man arbejder med. Mange vælger simpelthen forkert
  4. Man er ikke helt parat til at forlade den måde man plejer at arbejde på. I de fleste organisationer er ledelsen stadig mere optaget af, at alle medarbejdere er fuldt udnyttet end på at skabe flow i værdikæden. Man fastholder sin governance-model fremfor at skabe en ny, der understøtter det agile. Man har ikke helt tillid til, at de agile principper og teknikker kan virke.
  5. Arbejder man inden for IT, så er der i udgangspunktet stor kompleksitet. Denne kompleksitet forsvinder ikke, fordi man begynder at arbejde agilt. Hvor skulle den forsvinde hen? På overfladen ser de mest populære agile modeller besnærende enkle ud, men går man et enkelt spadestik dybere, vil man se, at det er de ikke. Det har man bare ikke erkendt, og forventer derfor det umulige

“Doing agile og being agile?”

Om man er agil eller ej bliver ofte en strid om, hvorvidt man bruger den ene eller den anden metode eller framework, man lad os glemme religionskrigene. Skåret ind til benet handler agilitet om at levere den rigtige vare i en ordentlig kvalitet til sine kunder og gøre det så hurtigt, man kan.

For at kunne vide om man arbejder ”så hurtigt man kan”, bliver man nødt til at måle på, hvor effektivt man leverer.

Forestil dig, at du skal købe en eller anden vare. Det er ligegyldigt, om det er et par nye bukser, du køber på nettet eller en ny vaskemaskine, en cykel eller hvad det nu er. Som kunde (i hvert fald hvis du ligner mig) vil du især være interesseret i, hvor lang tid der går, fra du har lagt din ordre til du står med varen i hånden. Det er det, man kalder gennemløbstiden (på engelsk: lead time).

I agile sammenhænge er gennemløbstider ekstremt vigtige. Hvis man vil undgå forsinkelser og skabe forudsigelighed, er det faktisk helt afgørende, at man kender sine gennemløbstider. Så kan man nemlig begynde at analysere, hvor i ens arbejdssystem, der opstår forsinkelser. På den måde kan man optimere systemet og forkorte sine gennemløbstider – til kundernes store begejstring.

Ser man på de gængse agile systemer, er det kun Kanban, der har benhårdt fokus på at måle. Særligt gennemløbstider. Kanban er et flow-system, der ikke dikterer en bestemt organisering. Scrum og SAFe er samarbejdsmodeller med bestemte roller, møder m.v., og man skal arbejde i sprints.

Der kan pudsigt nok være stor modstand mod at måle effektivitet. Særligt i mere umodne teams og organisationer, hvor man ser det som en ny form for kontrol fra ledelsens side, så de kan holde øje med om man bestiller noget. Det er selvfølgelig ikke det, der er meningen med det hele.

Meningen er at få folk vænnet af med at være agile robotter, der pænt går til en række møder, fordi metoden dikterer det, og i stedet blive proaktive flow-managers, der bestandigt vurderer, hvorfor der opstår afhængigheder, hvorfor aktiviteterne går i stå, hvor lang tid de ligger stille, hvad man kan gøre for at forhindre det osv. De har fuldt fokus på, hvordan man kan bringe sine gennemløbstider ned og blive mere forudsigelige, så man kan love sine kunder noget, der også holder i virkeligheden.

”Agile” er ikke et ”easy fix”

Virker de agile systemer? Ja, absolut! Hvis altså man bruger dem, som det er tænkt. Ellers får man bare mere af det, man hele tiden har haft, selvom man kalder tingene og rollerne noget andet.

Nogle agile metoder og frameworks er voldsomt komplicerede, mens andre er nemmere at gå til. Nogle kræver stor forudsigelighed for at fungere. Andre kan håndtere uventede situationer. Derfor er det så vigtigt at vurdere, hvilke arbejdsopgaver man løser, om der opstår mange uventede ildebrande, om man har mange individualister og personsiloer m.m., før man vælger sin agile vej.

Skal man lykkes med sit agile initiativ, er det også vigtigt, at man fra starten har gjort sig klart, hvad man gerne vil opnå. Det gør det muligt at planlægge implementeringen og sætte en konkret retning.

Med andre ord kan et grundigere forarbejde sikre, at man ikke vælger en agil tilgang, som aldrig vil kunne fungere under de givne omstændigheder.

Sidst med absolut ikke mindst skal man erkende, at det er en kulturforandring af de større, man kaster sig ud i. Det tager tid, og lederne skal gå forrest, for den slags forandringer opstår ikke nedefra. Men hvis man holder fast, vil resultaterne vise sig.

Posted in Agil god praksis, Agil implementering, Agil ledelse, Agil modenhed, Agile, Uncategorized | Tagged , , , , | Leave a comment

Lad os give det agile et realitetstjek

Væk med skønmalerierne. Lad os i stedet plante fødderne solidt i den virkelige virkelighed

Lad mig starte med at stille dig et spørgsmål. Har du nogensinde hørt nogen sige: ”nej, i vores virksomhed er vi bestemt ikke særlig agile, og vi har heller ikke nogen ambitioner om at blive det.”. Nej vel?

De fleste er allerede godt i gang med at arbejde agilt, og mange ser på, hvordan de kan komme med op på den agile vogn. Det agile er i den grad oppe i tiden.

Der kan være mange gode grunde til at folk vil være mere agile. Her får du et par stykker af dem jeg næsten altid støder på, når jeg er ude som rådgiver og coach:

  1. Man ved ikke rigtigt, hvad folk går og laver. Man kan godt se i sit store Excel-ressourceark, hvor folk burde være, men virkeligheden udspiller sig tit anderledes, og man ved ikke rigtigt hvorfor. Derfor vil man gerne have mere transparens, så man kan se, hvad der foregår
  2. Man vil have mere fart over feltet. D.v.s. ”hurtigere værdiskabelse”, hvad det så end er. Det er jo en af de fordele, der altid peges på, når man snakker om agile metoder/frameworks
  3.  Man vil have færre forsinkelser, mere forudsigelighed og budgetter, der holder. (Dét kan jeg godt forstå, for det er mere undtagelsen end reglen, at projekter leveres til aftalt tid og budget).
  4. Man vil have mere direkte involvering fra ”forretningen”, så man får udviklet nogle løsninger, der faktisk kan bruges. D.v.s. man vil etablere det berømte link mellem forretning og IT

De ambitioner er meget forståelige, og så vidt så godt.

Nu tager vi lige et tænkt (men hyper-realistisk) eksempel

Det er måske trukket lidt stærkt op, men…

Lad os lege, at det er vores virksomhed, der har de 4 ønsker ovenfor, og nu vil hoppe på enten Scrum- eller SAFe-vognen. Det er jo det, de fleste andre gør, så dét må jo være det rigtige, ikke? (Det er her, lemmingeeffekten kommer ind i billedet).

Man læser måske Scrum-guiden eller nogle af de mange solskinshistorier, der findes på nettet, og tænker ”dét der skal vi bare – hvor svært kan det lige være?”. Måske går man på SAFe’s hjemmeside, og tænker ”Wow, det er vel nok gennemført!” – hvad det også er. Men ofte opdager man ikke det, der står mellem linjerne.

De to frameworks (Scrum og SAFe) er i virkeligheden tomme skaller, som man selv må udfylde. De definerer en række roller, ansvarsområder og bestemte møder, man skal afholde i en bestemt sekvens. Der er også fokus på at arbejde med et ”lean-agile mindset” og iht. agile værdier, og man skal have tværfunktionelle teams. Men hvordan man lige udmønter det i praksis, melder historien intet om.

Man indser som regel, at hvis man skal have en chance for at lykkes, så skal nogen på Scrum- eller SAFe træning. Ofte sendes nogle stykker afsted, og efter få dage på skolebænken forventes det, at disse frontløbere tager implementeringsstafetten – evt. i samarbejde med nogle eksterne konsulenter. Naturligvis med fuld ledelsesopbakning. Intet mindre!

Du tænker måske, at det lyder meget fornuftigt, og det gør det umiddelbart også, men når man kradser lidt i overfladen, bliver billedet bare et andet.

Kompleksiteten bliver ikke mindre fordi man arbejder agilt

Mennesker vil gerne have lette løsninger på svære problemer, og det vil de ledere, der gerne vil have mere gennem pølsemaskinen på en mere forudsigelig måde også gerne. Sagen er bare, at den slags løsninger sjældent findes. Alting har en pris – også det at arbejde agilt.

Prisen for Scrum og SAFe er, at man ændrer sin organisation markant, og den måde, man plejede at arbejde på, forsvinder. Væk med projekter – nu skal man tænke produkter. Og projektlederne sender man på porten. (Eller også får de en af de nye roller, som jo alligevel skal udfyldes, når nu man skal køre på den nye måde.)

Nu er det bare sådan, at mange mennesker godt kan lide det job, de allerede har. De laver det, de blev ansat til og føler sig hjemme i det. De er måske oven i købet vældig gode til det, og kun de færreste har et brændende ønske om forandring. Mange stritter faktisk imod. Det gælder i særklasse også ”forretningen”, som skal stille med Product Ownere, Business Ownere m.m.

Med Scrum- eller SAFe-vejen, er der bare ingen vej udenom – organisationen skal ændres. Men det, der ser nemt ud på papir, er hundesvært i virkeligheden. Det er selvfølgelig ikke svært at lave organisationen om, men det er svært at ændre vaner og virksomhedskultur, og det er svært for de enkelte medarbejdere at finde ud af, præcis hvad de skal gøre anderledes.

Derfor får mange af de virksomheder, der er hoppet på det agile tog, ca. de resultater, de hele tiden har haft. De har godt nok indført nogle nye roller, møder og begreber, der får dem til at føle sig mere agile, men den følelse er sjældent bakket op af kolde fakta og data.

Hvis man i et stille øjeblik prøvede at se det hele lidt udefra, kunne man spørge sig selv:

  1. Hvorfor skulle en organisationsændring og nogle nye roller og titler i sig selv skabe bedre resultater, end dem man hele tiden har haft?
  2. Når man ændrer organisationen, får man så ikke bare skabt nogle andre siloer, end dem man havde i forvejen? Hvis man gør, fungerer de så bedre? Og hvordan måler man det?
  3. Hvordan skal nogle få – tit menige – medarbejdere kunne drive en stor agil forandring efter blot få dages kursus og uden at have konkret praktisk agil erfaring?
  4. Når et nyt agilt mindset er helt afgørende, hvor skal det så komme fra? Det kommer i alle tilfælde ikke af sig selv, og der er ikke bare en mindset-knap, man kan trykke på.
  5. Er man parat til at tage livtag med den kultur og de vaner – inklusive ledelsesvaner, der er i organisationen. Og er organisationen i det hele taget forandringsparat og moden nok?

Jo, jo, jo! Agile systemer virker faktisk. Nogle bedre end andre

Hvis du nu synes, at det lyder som om, at jeg (der lever af at være agil konsulent og underviser), er ved at tale agile frameworks og metoder ned, så kunne intet være mere forkert. Jeg er vild med det agile, men forsøger bare at smide noget realisme ind i den agile ligning.

Er man ikke parat til at investere store summer i at ændre organisationen og bliver det for tungt at arbejde med kulturen og veletablerede vaner, så kan man næsten lige så godt lade være at tænke Scrum, SAFe eller for den sags skyld Spotify-modellen. Disse kræver også tit en god del ekstern assistance og løbende coaching. Det kan med tiden blive temmelig dyrt.

I stedet kunne man bruge noget at sit krudt og sine penge på at få den metode, man allerede bruger, til at fungere. D.v.s. give den en ordentlig saltvandsindsprøjtning.

Eller man kunne vælge en agil vej, som ikke kræver en større omkalfatring af ens organisation, nemlig Kanban, som tager udgangspunkt i det eksisterende og skaber evolutionær forandring. En vigtig forskel er, at Kanban styrer aktiviteter, ikke mennesker, og at der er fokus på flow.

Med andre ord, hvis aktiviteterne i de forskellige teams, afdelinger m.v. flyder i en lind strøm, og der leveres værdi i ekspresfart, så kan man jo være fløjtende ligeglad med, hvilket mindset folk har, eller hvilke møder, de holder.

Det gælder med andre ord om at vælge den vej, der kan virke bedst i ens organisation, og der findes ikke en one-size-fits-all. Det er konteksten, der bør afgøre hvilken, man vælger, og vælger man rigtigt, er der kæmpe gevinster at hente! I modsat fald kan ens investering nemt være spildt.

Det, man tit glemmer

På falderebet vil jeg nævne en sidste vigtig ting. Værdiskabelsen – uanset hvad man arbejder med – sker i de agile teams. Og uanset hvilket agilt framework eller metode, man har valgt, så bruger man enten Scrum eller Kanban (eller en kombi) på team-niveau.

Det vil sige, at selvom organisationskulturen ikke kører på den helt store agile klinge, så kan man alligevel opnå markante resultater, hvis ens teams har ordentligt styr på Scrum og Kanban. Det betaler sig virkelig at sætte ind her, for det er absolut ikke intuitivt.

Hvis du vil fordybe dig i detaljerne omkring agile transformationer og metoder, så vil jeg lige nævne min seneste bog ”Agile transformationer i praksis”. Her kan du også læse om min 6-trins implementeringsmodel, som er grundigt gennemprøvet af virkeligheden. Jeg kalder som altid en spade for en spade, og tegner ingen skønmalerier.

Bogen finder du her: https://agilagenda.com/agiletransformationeripraksis/

Posted in Agil god praksis, Agil implementering, Agil modenhed, Agil realisme, Agile transformationer, Agilt mindset, Kanban, SAFe, Scrum | Tagged , , , , , | Leave a comment

Fewer feelings and more facts in agile systems, please!

It has become almost an adopted truth that so-called agile teams are more productive than non-agile teams. I write “so-called agile teams” because many of the teams I have worked with during the past 10-12 years as an agile coach, were in fact not very agile in the way they worked.

Most agile teams use Scrum, but in many cases in a very superficial way. Very often using Scrum only means that organizations have introduced new roles, artifacts, and events. They have Scrum Masters and Product Owners instead of Project Managers, and they work from a backlog instead of a requirements specification, and they hold a series of meetings because “Scrum says so”. (I know that I am simplifying things a bit, but I have seen this so often that it looks like a pattern).

However, changing organizations and giving people new roles will not result in agile improvements. On the contrary, it often causes anxiety, confusion, and uncertainty. Focusing mainly on the way people are organized will not facilitate increased productivity. Changing behaviors and habits will, but of course, that is not as easy as making organizational changes.

As a side-track, I came to think about the time where it became modern to change small offices for 1-4 people with big open-space offices, where sometimes hundreds of employees would sit almost glued to each other. The point was – at least from an academic point of view – that it would increase efficiency as it would be easier to exchange information and keep oneself up to date.

This dream did not come true, because the big open spaces made it impossible to concentrate on your work as there was a constant noise from people talking, walking, coughing, laughing, etc. The result was frustration, stress, and lower productivity.

I wonder if the same is not the case when it comes to agile methods and frameworks? They look deceivingly simple and sitting behind your desk it may seem compelling and easy enough to go agile. You “just” need to make a few changes, e.g., introduce a new set of roles and responsibilities and adjust your processes. But when you try to do it in practice it becomes obvious, that it is extremely difficult.

Agility is not a thing, and it does not happen automatically.

How to achieve evidence-based agility?

Understanding the way, the method or framework works is the easy part, but changing the more intangible parts such as work habits, behavior, values, and mindset not to mention accepting to be transparent is a different matter.

Unfortunately, these not so tangible elements are the real drivers of agile improvements, and they are often neglected. Therefore, teams and organizations end up doing mainly the mechanics which may make them feel agile, as they can see the obvious:

  • We have a board
  • We are having standup meetings every day
  • We work from a backlog
  • We have introduced all the roles indicated in the method/framework
  • We hold all the meetings we are supposed to

So, we must be agile, mustn’t we?

But holding e.g. a set of prescribed meetings changes nothing until you focus on the quality of those meetings. They may facilitate a feeling of agility, but do not in themselves bring any evidence of it.

The evidence of increased agility will only be established when you start measuring. The metric that will give you the most accurate information about your efficiency and the progress achieved over time via continuous improvement initiatives is lead time. Lead times present you with the hard facts.

Below you see an example of what you should be focusing on when you measure lead times, namely the tail.

(Source: Kanban University, Kanban Maturity Model, Understanding Lead Time)

Knowing precisely where you stand in terms of lead times will indicate whether there is an urgent need for improvement. What you should be striving for is to optimize the way you work, so you over time will see your lead time distribution tail “move left ”towards an increasingly thinner tale.

Achieving such results will be clear evidence of success with changing the improvement drivers mentioned above: habits, behaviors, values, work processes, etc., many of which are “people things” that should be incorporated in the everyday work and be openly discussed.

People are different, but don’t let that stop you from finding common ground

People are different, they think differently about the same things, and each has their own perspective. That’s why it is necessary to agree on a common set of rules for the way your team should work and be explicit about what e.g. “quality” or “done” means.

It’s also necessary to discuss more sensitive topics such as: “do we have the right behavior?”, “do we incorporate agile values in the way we work?”, “do we work with openness and respect for each other and our customer?”, etc.

If those are the discussions you have at your meetings, then you have gone beyond the mere mechanics of just holding a meeting because the framework tells you to. You have started to talk about things that matter and will result in real change.

And if you measure the effects that behavioral changes, new habits etc. have on your lead time distributions, then you have achieved evidence-based improvements, and have moved from feelings and beliefs to facts.

Send a one-time donation to Annette today
I am passionate about my work as an agile consultant, trainer, and coach. Via my customer projects I experience things that work well and not so well. This and much more is what I share on my blog.

If you like what you are reading and it inspires you in your own work, I would be very grateful for your support.

Choose an amount


Or enter a custom amount


Your contribution is much appreciated.

Posted in Agile, Agile maturity, agile realism, Agile transformation, Good agile practice, Kanban, lead time, Transparency | Tagged , , , , , | Leave a comment

Derfor er transparens så voldsomt vigtigt i agile systemer, og derfor er det så svært at opnå

Jeg har arbejdet med mange forskellige agile teams i de seneste 10-12 år. Der er mange, der bruger Scrum, nogle bruger SAFe og Kanban. Men uanset hvad der er ens egen favoritmetode, er der et nøgleprincip, man ikke kan vælge fra. Det er transparens.

Hvorfor er transparens nu så vigtigt?

Hvis man er ude efter at øge agiliteten i sin organisation, sin afdeling, sit team eller projekt, og hvis man vil have løbende forbedringer og blive mere effektive, så er man nødt til at kunne se, hvad der foregår. Det kræver transparens i den bredeste forstand.

Her får du en række eksempler på områder, man bør have helt op i lyset:

  • Er det nemt at se hvem, der laver hvad?
  • Kan man se om aktiviteter er blokeret, hvorfor de er det, og hvor længe de har været det?
  • Er fremdrift ift. jeres sprintmål, projekt, produktmål m.v. visualiseret?
  • Er jeres arbejdsprocesser krystalklare?
  • Er jeres regler og politikker eksplicitte og synlige?
  • Er jeres backlog synlig og let at forstå for andre end jer selv?
  • Brydes aktiviteter ned, så det er tydeligt, hvad der skal til for at gennmføre dem?
  • Måler i gennemløbstider (lead times), og holder I styr på fordelingen af dem?
  • Måler I i det hele taget noget som helst?

Listen kunne fortsættes, men den vigtigste pointe er, at transparens er så meget mere end bare at have en aktivitetstavle (fysisk eller i noget software). Det er kun et meget lille skridt på vejen til fuld transparens.

Der er nogen, der ikke kan fordrage at være transparente

Når jeg diskuterer transparens med teams og det faktum, at transparens er en forudsætning for forbedringer, så får jeg mange forskellige reaktioner. Jeg har mødt ganske mange, der slet ikke kan se fidusen ved at være transparente.

Her får du nogle af grundene til den holdning:

  1. Nogle mener, at det kan være helt ligegyldigt. De argumentere med, at de arbejder med deres ting helt uafhængigt af de andre i teamet. De kan ikke dele deres opgaver med andre, så hvorfor dog være transparente?
  2. Nogle kæmper imod transparens med næb og kløer. Ofte er det folk, som ikke får helt så meget sved på panden, som deres kolleger. Det vil de gerne skjule. (Ja, de folk findes – du har sikkert også mødt dem).
  3. Nogle bryder sig ikke om at vise eller fortælle om deres fejltagelser
  4. Endelig er der nogen, der bare slet ikke kan se formålet med at være transparente, og ingen argumenter – selv de mest rationelle ellerrr metodekorrekte – bider på dem.

Sagen er, at man ikke kan gemme sig i et transparent system. Det kan være intimiderende for nogen. Men hvis man er gået “all-in” på at arbejde agilt, så vil man også være en af dem, der synes at det er helt naturligt at være åben og dele informationer med andre. Man deler bl.a. egne fejltagelser som noget helt naturligt,

Først når man har fået de knap så entusiastiske ombord på transparenstoget, bliver det muligt at få det fulde billede af, hvad der foregår i ens agile system. Har man ikke det, så kan man heller ikke vide, hvad der bedst kan betale sig at optimere.

Man kan ikke forbedre noget, man ikke kan se

Løbende forbedringer er et fundamentalt princip i alle agile metoder og frameworks, og når nu man ikke kan forbedre ting, der er usynlige, så må man gøre, hvad man kan for at få disse skjulte ting og sager ud i lyset. Transparens er helt fundamentalt.

En af de væsentligste grunde til, at virksomheder vælger den agile vej er, at man ønsker at effektivisere og sikre hurtigere “time-to-market”. Hvis det skal ske, er man nødt til at fokusere på flow og gennemløbstider.

Det betyder, at man holder øje med, hvordan opgaven flyder gennem de forskellige dele af organisationen, fra det tidpunkt nogen får en ide, som man vælger at forfølge, indtil det øjeblik hvor man står med varen i hånden.

Set fra fra et time-to-market synspunkt er det eneste interessante, hvor lang tid det tager, at udvikle eller producere den nye vare fra ende til anden. Om et enkelt team i værdikæden er hamrende effektivt, betyder ikke særlig meget for gennemløbstiden, hvis resten eller dele af værdikæden ikke er.

Når man kender sine gennemløbstider, så ved man, hvor effektiv man er. Gennemløbstider er ikke baseret på mavefornemmelser, krystalkugler eller vilde gæt. De viser virkeligheden baseret på konkrete data.

Med andre ord, så er gennemløbstider det mest meningsfulde, man kan måle på, hvis ellers man ønsker at vide præcis, hvor effektiv man er. Og det gør man selvfølgelig, hvis man vil være mere agil.

Når man begynder at måle sine gennemløbstider, så får man som regel nogle uventede overraskelser. Her får du nogle typiske eksempler:

  • Du og dit team er måske ikke helt så effektive, som I gik og troede
  • Mange aktiviteter bliver blokeret af mange forskellige grunde. Det forstyrrer jeres flow
  • Jeres arbejdsprocesser virker ikke optimalt, og understøtter ikke det I arbejder med
  • Mange har nogle kedelige vaner. De multi-tasker og hopper mellem forskellige opgaver. Det koster dyrt på jeres gennemløbstider
  • Mange flaskehalse resulterer i lange ventetider og (igen) længere gennemløbstider

Sådan er det faktisk mange steder, men nu har I v.h.a. den styrkede transparens mulighed for at vurdere, præcis hvor det bedst kan betale sig at sætte ind og forbedre det, der ikke virker optimalt.

At måle giver transparens over team-effektivitet

Når jeg diskuterer metrikker med agile teams, så er et af de argumenter, som jeg hører igen og igen dette her: “Vores chefer vil jo have, at vi estimerer, og når nu vi gør det, så er der jo ingen grund til også at måle gennemløbstider”.

Intet kunne være mere forkert, og jeg kan simpelthen ikke lade være med hver eneste gang at spørge dem: “OK, men er jeres estimater altid så præcise, at I kan stole på dem?”. Uden undtagelse, så svarer de: “Nej, aldrig”.

Jeg kan sagtens forstå, at det er nødvendigt at have en indikation af, hvor lang tid det vil tage at gennemføre et bestemt projekt eller producere en “klump værdi”, men jeg synes, at det er svært at forstå, hvorfor man bliver ved med at bruge dage og timer på at estimere, hvis ens estimater alligevel altid rammer ved siden af.

Gennemløbstider er ikke et “bulls-eye”, det er en fordeling. Når man har målt sine gennemløbstider selv over en kortere periode, så begynder man at kunne give nogle relistiske løfter baseret på evidens med basis i kolde data.

Når man ser på, hvad man tidligere har præsteret, vil man se noget i denne retning: Hvis intet forstyrrer fremdriften, kan man gøre en given aktivitet færdig på X dage. Hvis alt driller, tager det Y dage. Man kan også regne sig frem til, at med 85% sandsynlighed kan man være færdige på Z dage. Det giver en ganske robust prognose.

Det vil føre for vidt at tage aktivitetskategorier, serviceklasser m.v. op her, men jeg håber, at princippet om at bruge evidensbaserede gennemløbstider i stedet for krystalkuglebaserede estimater står klart frem.

Der er andre ting man kan måle på for at skabe transparens. F.eks.:

  • Gennemløb (hvor mange aktiviteter har man gjort færdige i måleperioden)
  • Flow-effektivitet (hvor mange timer/dage arbejder vi aktivt på aktiviteten i forhold til den tid det tager at gennemføre den fra start til slut)
  • Blokeringer (hvor mange er der, hvorfor opstår de, hvor længe er aktiviteterne blokeret)

Disse målinger fortæller en masse om både team-effektiviteten og hvor effektiv organisationen arbejder på tværs af teams. Og så er det ikke engang særlig besværligt. Men hvis man kun skulle måle en enkelt ting, så er det gennemløbstider.

Der er flere forhindringer for at skabe transparens

Selvom de fleste nok kan blive enige om, at transparens er en nøglefaktor i agile systemer, så betyder det ikke, at det er nemt at opnå. For det første kræver det et vist mål af disciplin, f.eks. i forhold til at følge de agile processer, overholde de regler, man selv har været med til at lave, og ikke mindst følge op på fremdrift. Den disciplin er bare ikke altid til stede.

Disciplin er faktisk altid en naturlig ting i modne teams og organisationer, for hvordan skulle man ellers vide, hvor man var, og hvad der kan forbedres. Det er bare ikke en naturlig ting i mindre modne teams m.v., så det skal der arbejdes med.

Hvis man arbejder med udisciplinerede teams, så er man nødt til at fokusere på at ændre de eksisterende mønstre og vaner, så man kan indarbejde nogle mere modne af slagsen.

Det jeg har set fungere bedst er, hvis man kan blive meget eksplicit omkring, hvad man forventer af folk. Fortæl dem præcis hvad de skal gøre anderledes, hvorfor de skal gøre det, og hvad de selv får ud af det. Det er nemmere at forandre noget, man kan forstå.

Transparens kommer desværre ikke automatisk, men det er noget man skal jagte målrettet. I et transparent system er det nemlig helt indlysende, hvor der ligger forbedringer, der bare venter på at blive samlet op.

Disse forbedringer fører til højere agilitet, og var det ikke det, der var meningen i første omgang?

Posted in Agil god praksis, Agil modenhed, Agile målinger, Agile teams, Agile transformationer, effektivitet, Organisatorisk agilitet, Transparens, Uncategorized | Tagged , , , , | Leave a comment

Agile teams hold the key – the method is secondary

In my work as a self-employed agile trainer and coach, I have worked with numerous agile teams. Some used Scrum, some Kanban, some worked in a SAFe setting. These days the “Spotify model” (which to my knowledge they never fully applied themselves) is growing increasingly popular.

There is much fanaticism when it comes to agile methods and frameworks. I have even met people that got upset if others did not use the terminology “method” and “framework” correctly. But I have to ask: does it really matter? For the sake of simplicity, I will only use the word “method” in the rest of this article.

I have also come across quite a few zealots who would claim that the only real agile method was the one that happened to be their favorite. If the results when using the method were not as positive as expected, they would argue that this could only be because people were using the method incorrectly. Suggesting that there is not a “one-size-fits-all-method” was almost seen as a provocation.

But why this fanaticism, and why so emotional? At the end of the day, we are all striving to get more successful projects, less economic waste, and more efficiency in whatever way possible. I might add that this was what we were striving for too back in the days before “agile” entered the scene.

I find it counter-productive when people are more interested in the form rather than concrete results. I find it discouraging when people are fighting a “war of the methods” rather than accepting that there will always be prerequisites for making any method work.

This brings me back to the agile teams

One of the main prerequisites for making agile methods work as intended is having teams that understand what is expected from them, and what they need to do differently when they ‘go agile’.

And not only that – they also need to be motivated for making those changes. What would be their motivation for change if no one can explain why they should change and what is in it for them?

Agile teams will typically work with Scrum or Kanban, (some in combination with XP). But neither of them are intuitive or easy.

Scrum introduces new roles and responsibilities that introduce significant changes to the work processes. You need to let go of a lot of old habits, just as behaviors must change according to the Scrum values.

You might say that in Scrum the responsibilities held by the good old Project Manager are now split between the Scrum Master, the Product Owner, and the Development Team.

Even though Scrum does not fancy Project Managers, the tasks they used to do around planning, communication, stakeholder management, risk, and financial management, etc. will not disappear just because you work in a Scrum Team.

Looking at Kanban, you do not need to change your organization and introduce new roles and responsibilities, but you must for instance start to limit work in progress, and measure lead times. Kanban is data-driven, so if you don’t measure, you will not know what to improve.

Both methods require transparency to inspect and adapt and avoid guesswork. But I have found that it is not at all easy to convince people that they should be more transparent. Some find it almost intimidating, some believe that it is their management wanting to control them even more, some don’t think that it is anybody else’s business what they work with. And the list goes on.

To get successful agile teams you, therefore, need to overcome the resistance towards some of the built-in prerequisites for making agile methods work, such as transparency, and also make the teams embrace the values that are built into the method.

This is easy to say, but hard to do. Many habits have been formed over 5, 10, 20, or even more years. Such old habits are difficult to break, and it will not happen overnight. However, if you are not persistent they will not change at all.

“Nothing is easier than keep on doing what you always did. Changing requires conscious thinking and energy”

Continuous improvement is the path to higher agility

It is quite simple: If you do not see any evidence of continuous improvement, your teams are not agile. Continuous improvement is the path to higher agility, and fortunately, continuous improvement can be planned.

I have seen so many examples of teams that feel they are agile simply because they have introduced new titles, attend certain meetings, and work from a backlog.

Just like I have met teams that strongly believe they work with the Kanban method because they have made a task board, and meet in front of it every day.

Changing your organization or having stand-up meetings in front of a board will not make you more agile. It does create a bit of transparency, but no continuous improvement and thus no increased agility.

If faster value creation is important – and it usually is – the only way to achieve it is to improve your agile teams’ efficiency by facilitating an increased focus on continuous improvement. This could e.g. be to:

  • Start measuring lead time, throughput, flow efficiency, etc., so decisions can be backed up by data
  • Increase focus on blockers – how many, how long, why they occur, and what can be done to minimize the negative effects
  • Increase focus on dependencies and bottlenecks. I.e. anything that disturbs the flow
  • Stop multitasking, and thus minimize the cost of task switching
  • Improve work and decision processes
  • Improve collaboration both within the team and with stakeholders

Most of the above points have to do with behavior and habits. Some have to do with the way your company works, but any team interested in improving agility can decide to immediately start working actively with the improvement opportunities that they can control themselves.

Agile teams that plan continuous improvement tasks into their daily work are more successful than teams that don’t. It is not very difficult, but it is very powerful.

The key to higher agility is in the hand of the agile teams. Independent of which agile method they work with.

Posted in Uncategorized | Leave a comment

Is enterprise agility just an impossible dream?

A few days ago, I was contacted by… well, let us call him Peter. Peter, the CIO was leading the transformation to agile in a (by Nordic standards) large global company in the financial sector. They had been working agile with SAFe for more than 6 years, but Peter and his fellow managers were still not seeing the results that they had expected to get out of their large investment.

They had done all “the right things”. They had changed the organization as described in the SAFe framework. They had plenty of management buy-in as the decision to “go agile” was taken by the top management with the support of the board. They had gone from the concept of projects to products, just like you are supposed to, so why did they not see any major changes in productivity and outcome?

Peter contacted me because he had come across by new book about agile transformations in practice (the book is in Danish but is currently being translated into English), and he wanted my opinion on enterprise agility, and whether I thought that it was at all possible to achieve.

He was curious to know what experiences I had had with enterprise agility after having worked as an agile consultant, coach, and trainer for many years.

Peter’s main concern was, as mentioned, that they did not see any concrete improvements in terms of faster completion and higher quality. Sprint goals were often missed, and rework often necessary, but Peter was still convinced that working agile was the right way to go.

Are you feeling agile, or do you know that you are?

I started asking a few questions about how the teams themselves felt they were doing, and if they were measuring their own performance. (You are supposed to measure progress no matter what agile method or framework you use).

The answers were:

1. Most teams felt they were very agile. They attended the meetings that they were supposed to according to the SAFe framework. They had a Scrum Master and a Product Owner and worked from a Product Backlog, and were part of an Agile Release Train, so what more could anybody possibly want?

2. No, the agile teams did not measure their own performance. They had talked about doing it, and a few of the teams did not mind measuring, while others were convinced that this was something that the management wanted to control them and check if they were working hard enough.

Both examples are behaviors that I have seen again and again on my agile assignments. Although there may be a sincere wish to achieve higher agility, many come to a full stop when they have changed their organization, introduced the new roles, and started up the new sequence of meetings as prescribed.

But when did organizational change in itself ever facilitate improvements? And what improvements are gained by changing the name of a requirements specification and call it a product backlog? Change only happens when behaviors change, and you can only know that your agility is increasing if you can back it up with data based on quantifiable facts. Feelings are good, facts are better.

Transparency is not optional in agile systems.

Behavioral change is not trivial, and it will not happen unless you plan for it. I have had quite a few discussions with other agile coaches who insist that change should happen organically, and bottom-up. This might work in theory, and if you have all the time in the world (as well as money) to wait for that change to happen, but if you don’t, and if you don’t like random change, I strongly recommend that you plan for the changes that you would like to see. Different goals require different actions.

Transparency is a very important part of the agile DNA. Continuous improvement are key words too, but you cannot improve what you cannot see.

Knowing your agile status because your data proves it is one way of creating transparency. Visualizing impediments, blockers, dependencies etc. is another. Analyzing what is blocking you, why and for how long, and being crystal clear about how you prioritize and visualize your product backlog also creates transparency. These are only a few examples, but transparent processes, decisions, quality standards etc. could be added.

Transparency is a prerequisite for making agile methods and frameworks work as intended but being transparent seem to be almost intimidating to some people. I have met quite a few who are uncomfortable by being complete open about their work, their mistakes, doubts, (lack of) competencies etc. But openness and knowledge sharing are key in agile systems, where the members of cross-functional teams are heavily depending on each other’s knowledge.

But let’s get back to Peter and enterprise agility.

Enterprises and silo-mentality

During my discussion with Peter, we also talked about silos and silo thinking in his company. I asked whether they during their SAFe transformation had been able to break down their silos and go “all-in” on the SAFe organization.

Peter’s answer was no. They had tried to get away from their old silo-organization but had not succeeded for several reasons, e.g.:

  1. Some managers and employees did not want to give up or leave “their” old silo, and did not buy-in to agile thinking
  2. Many legacy systems required a special team (a silo) to maintain and operate them. They could not allocate people full time to anything else
  3. Old habits. Personal and team habits. And eg. the reward system was still based on silo performance

I guess that most managers have become managers because the like to have the power to make decisions and control and dispatch their resources, so maybe it is not so strange that some managers work against agile ideas such as self-managing teams, and more team-autonomy.

Working with my clients I always ask: “What will you do when (not if) you experience that managers or team members work against what you are trying to achieve with your agile initiative? Will you accept it? Will you fire them? Will you place them elsewhere in the organization?

One thing is sure. It is highly disturbing if just one person in an agile team is obstructing the agile ways of working. It slows down progress, and the cultural change that must take place. The work environment suffers.

However, even if it is big dilemma and a tough decision to make, you must decide how to deal with those that disagree to work according to new agile ways, in this case SAFe.

New solutions planned to be built by the agile teams would usually have interfaces to one or more legacy systems and would therefore need resources from the systems teams. Those resources became bottlenecks, which resulted in unavoidable unpredictability. Sometimes they worked in their agile team, sometimes in their system silo.

Unpredictability was also the result when e.g. managers, often high-level, asked teams or individuals to do them a small favor and work on new ideas or activities that they found important. I.e. activities that were not prioritized in the sprint backlog.

It is not a sign of good health in an agile system, where unprioritized activities are allowed to move directly into the fast lane, because a manager asks you nicely or maybe yells at you. It introduces risks to your plans.

You get what you measure

Old habits are hard to break. We have heard that many times before, but it is true none the less. Nothing is easier than just keep on doing tomorrow what you did yesterday.

So, if your reward system favors old ways of working, and do not support the new way, it should come as no surprise, that people will work in the way that leads them towards the goal that can potentially affect their own financial situation positively. Of course!

In Peter’s case, the ambition was to get all agile teams in agile release trains in sync, so they delivered value faster, and with higher quality. But the reward system pulled people in a different direction.

Of course, it can be costly to change your reward system, but if you spend millions on an agile transformation, why not take the effort to change your reward system too? If it favors those that work in accordance with agile principles and values, help smooth the way for the agile teams, and work to remove or minimize bottlenecks, cross-team dependencies, blockers etc., it will go hand-in-hand with the transformation effort and facilitate quicker positive results.

So, is enterprise agility an impossible dream?

Well, it depends on the method or framework you choose. If the method/framework is very complex it will only work as intended in high-maturity organizations that are not change averse.

It is a sign of warning, if you have to employ many agile coaches (overhead) to support the agile organization. Then the method/framework is probably too complex. Coaches that can help kick-start or re-vitalize agile initiatives are fine, but they should not be on board for ever.

Based on many years’ experience as an agile consultant, coach, and trainer, my conclusion is:

  1. Keep things as simple as possible and go for a method/framework that fits your context. A “one-size-fits-all” does not exist. Choose your agile direction for the right reasons and avoid the “lemming effect”
  2. Be explicit about what behavioral change you expect from people and what is in it for them. “Agile” is neither easy nor intuitive, and most employees are not hired to be method experts. Therefore, be clear about what people need to do differently and explain the benefits from changing
  3. Measure, measure, and measure. Use metrics such as lead time, that show your actual performance and efficiency. Avoid vanity metrics that may make you feel good but tell you nothing about efficiency. Act on the findings
  4. Make plans for continuous improvement. If you don’t you risk getting stuck at a low maturity level. It happens a lot, but it does not have to be that way.

Achieving enterprise agility is difficult but not impossible. It will certainly not happen overnight or just because you make organizational changes. It’s people and new behavior drive change.

Posted in Agile, Agile implementations, Agile management, Agile maturity, Agile transformation, Enterprise agility, Good agile practice, Uncategorized | Tagged , , | Leave a comment

Vidste du, at Kanban skaber de hurtigste agile resultater uanset hvilken metode, I i øvrigt bruger? Se myterne + en løsning

Jeg har nemlig et engangstilbud på en Kanban-pakke til dig

I de sidste +11 år har jeg nørdet agile metoder og frameworks. Jeg underviser i dem, og jeg bruger dem i praksis på de agile implementeringer, som jeg er en del af. Jeg spiser min egen medicin og mærker på min egen krop, hvad der virker og hvad der ikke gør.

Det jeg ser ”derude” er, at der florerer en masse misforståelser om, hvad Kanban-metoden går ud på. Det er ærgerligt og jeg gør alt for at ændre det. Ikke bare fordi jeg er blevet tilfældigt forelsket i Kanban, men fordi jeg har været hele vejen rundt i det agile univers og set (og selv bevist), hvor overbevisende resultater man kan skabe ved at arbejde systematisk med sine opgaver “the Kanban way”.

Kanban-metoden går ud på at sætte et system op omkring sine teams og aktiviteter og den måde, man arbejder med dem på. Enten i enkelte teams eller i hele organisationen og det er ligegyldigt hvilken slags viden man arbejder med, eller hvilken metode, man har valgt. Scrum, SAFe, PRINCE2 osv.

Men så længe myterne om Kanban er i live, så forhindrer det faktisk folk i at vælge den ultimativt letteste (og faktisk også billigste) vej til organisatorisk agilitet. Simpelthen fordi de (endnu) ikke ved, hvad Kanban i virkeligheden går ud på. Derfor skal du ikke lade dig nøje med en halvkvædet vise. Du skal have alle versene med.

Lad mig fortælle, hvad der overrasker folk mest om Kanban

De fleste af mine kursister m.fl. bliver overraskede over at høre at:

”Kanban er en management metode”

Måske er du også en af dem, der tror, at Kanban kun handler om at skrive sine aktiviteter på Post-its og plante dem på en stor tavle. Så kan man se, hvad der er i gang, og derefter kører tingene, som de nu engang gør. Det er der faktisk mange, der tror.

Faktum er bare, at en Kanban-tavle, hvad enten den er fysisk eller virtuel, er så meget mere end en opgavetavle. Selvom den er super vigtig, fordi den er med til at skabe transparens, så er den faktisk kun en mindre del af Kanban-metoden.

Med Kanban kan I nemlig styre hele jeres arbejdssystem på en ultrastruktureret måde. I systematiserer den måde, I prioriterer og kommunikerer på og ikke mindst behandler jeres blokeringer og flaskehalse på. Alt sammen på tværs af teams.

Jeg tør næsten vædde på, at de fleste af jeres flaskehalse handler om et eller andet, som ikke virker optimalt i jeres eget organisatoriske system. De skaber selvpåførte forsinkelser. Det kunne man jo vælge at gøre noget ved, hvis ellers man kunne se det. Med Kanban får I denne transparens.

Som jeg plejer at sige til mine kursister: ”Kanban sætter et stort spejl op foran jeres organisation og viser jer, hvordan tingene (d.v.s. arbejdet i jeres teams inden- og udenfor IT) egentlig går”. I får ingen skønmalerier at se, som I alligevel ikke kan bruge til noget. I får den rå virkelighed serveret, så I kan tage stilling til, hvad det ville være smart at ændre.

Det er ikke nødvendigvis rart at se sig selv i spejlet, for man får også øje på sine mindre flatterende sider. Men det er jo virkeligheden, og den skal man kende, hvis man vil forandre noget.

En anden ultra-sejlivet myte

Den nok mest sejlivede myte om Kanban er, at metoden kun virker i små support-teams. Det er simpelthen så forkert som det kan være, og jeg har tit tænkt på, hvordan sådan en røverhistorie opstår.

Jeg er kommet til den konklusion, at det må være fordi Scrum, som primært bruges til software-udvikling, definitivt ikke kan bruges i support-teams. Simpelthen fordi man ikke kan forudse, hvilke supportopgaver, der dukker op. Selv i løbet af en dag. Så tanken om at planlægge aktiviteterne i et support-team bare en uge frem i et såkaldt sprint, er jo i sagens natur dødfødt.

Kanban, som er et flow-system, kan sagtens håndtere uforudsigelighed. Derfor virker Kanban også perfekt i support-teams. Det har så fået nogen til at konkludere lidt bagvendt, at så kan det nok kun virke i support-teams. Det er ærgerligt, og det er som sagt skrupforkert.

Sidder du og tænker:“Hey, vi kan da heller ikke planlægge bare en enkelt dag frem med sikkerhed. Der dukker altid et eller andet op, som vi ikke havde forudset, og som absolut skal laves her og nu – faktisk helst i går!”, så kan jeg fortælle dig, at det er en klassiker. Sådan er det faktisk de fleste steder.

Det er derfor, jeg gør meget ud af at fortælle, at det er hamrende smart at kombinere Kanbans principper med Scrum, så nogle af begrænsningerne i Scrum bliver fikset. Og da Kanban er en stor og integreret del i SAFe, så er det da ubetinget smart at blive god til Kanban og dermed få SAFe til at virke ordentligt. (Kanban virker selvfølgelig strålende helt alene. Det er jo en metode i sig selv).

Forestil dig det her:

“Hvad nu, hvis du og dit team kendte Kanbans praksisser og teknikker til bunds og med dem i værktøjskassen kunne gøre det, I allerede gør godt (måske med Scrum eller SAFe), bare endnu bedre?”

Især i disse tider gælder det om at arbejde så effektivt som muligt. Derfor er det en “easy win”, at bruge Kanban til at få mere fart på jeres leverancer, mere værdi til jeres kunder og mindre stress til jer. Det tør jeg godt at love, for jeg har set det ske så mange gange.

Kanban kræver overhovedet ikke, at I laver alt muligt om. Ingen omorganisering og ingen forvirring om roller og ansvar. I skal kun lære Kanbans ret så enkle regler at kende. Og så selvfølgelig følge dem. Ellers sker der jo ingenting.

Måske kan du se for dig, at det ikke ville være værst, hvis I selv uden de store anstrengelser kunne skabe forbedringer. Men hvordan skal du gribe det an?

Det er her, mit helt særlige tilbud kommer ind i billedet

Du kan lære præcis, hvordan du kommer i gang med Kanban hos jer eller optimere det gode, I allerede gør ved at springe på vores Kanban Management Professional (KMP) forløb på 2 x 2 dage. Det afholdes på Ecopark i Århus hhv. den 16. og 17. september og den 30. september og 1. oktober.

Det første kursus hedder ”Kanban System Design”, og du kan læse meget mere her >>

Det sidste kursus hedder ”Kanban Systems Improvement” og du kan se detaljerne her >>

Efter kursus nr. 2 får du en international certificering fra den førende globale Kanban-organisation, Kanban University. Bortset fra at komme hjem med en agil værktøjskasse, der nu bugner af nye værktøjer, så står du også med et stærkere CV.

Og nu til mit særlige tilbud: Jeg tilbyder dig lige nu (og kun denne ene gang) den mest attraktive Kanban-pakke, som du finder noget sted på kloden. Den består af:

1. De to KMP-kurser, som du kan købe samlet med en klækkelig rabat. Jeg giver dig simpelthen et afslag på 4.000 kr., så din samlede pris bliver 15.600 kr. + moms

2. En fri adgang til mit online kursus ”Bliv agil med Kanban”. Så kan du friske din Kanban-viden op når som helst. Jeg plejer naturligvis ikke at forære mine kurser væk, og alle andre må betale 4.400 kr. + moms

3. Et eksemplar af min bog, Kompakt basis-guide til Kanban”, som du kan bruge som opslagsværk. Den koster normalt 195 kr. + moms.

Samlet set står du med en foræring på 8.600 kr. + moms, og jeg ved, at det er værdi for alle pengene. Du bliver i dén grad klædt på til at komme godt og sikkert fra start med Kanban eller optimere, hvis I allerede er i gang.

Men hvorfor denne gaveregn?

Det er simpelthen fordi jeg er så glad for at komme ud af min hule og møde agile entusiaster igen ansigt til ansigt. Det er fordi, vi tager til Jylland med KMP-kurserne for første gang, og så er det selvfølgelig også fordi jeg glæder mig til at vise styrken i Kanban-metoden.

Har du spørgsmål, så kontakt mig gerne direkte her: annette@xvoto.dk

Det ville glæde mig sådan at møde dig den 16. september i Århus.

P.S. Der er ikke voldsomt mange pladser tilbage

Posted in Agil god praksis, Agil implementering, Agil realisme, effektivitet, God praksis, Kanban, Kommunikation, Ledelse, Management, Organisatorisk agilitet, Projektledelse, Transparens, Uncategorized | Tagged , , , , , , , , , | Leave a comment

How Scrum and agile teams can benefit from Kanban

Setting the scene

The agile wave has been rolling for more than 20 years now. It probably started as a reaction to the “old” bureaucratic, and heavy-weight project management methods and standards that at the end of the day could not guarantee project success despite their clear guidelines and roadmaps.

For many years Scrum has been the most widely used agile approach. Personally, I started on my own agile journey more than 10 years ago, and at that time, when someone mentioned agile, Scrum would be the next word coming up.

Back in the nineties when the agile movement started to gain momentum, Scrum was not the only method or framework, but it ended up being the one making it big on the global scene.

During the past many years, I have spent thousands of hours teaching Scrum, Kanban, and agile project management. I have written books and articles, given public speeches, and not least worked on numerous agile assignments i various roles.

I mention this to emphasize that I am not “married” to any particular method or framework (though I do have my preferences). I understand most of the ins and outs of “agile”, and I know from hard-earned practical experience that a one-size-fits-all model does not exist. Even if zealots may insist otherwise.

History repeating itself?

In the past few years SAFe has become increasingly popular, and I can understand why it seems so compelling. If you experience many of your projects failing, being delayed, or breaking the budgets, it is very tempting to start using a framework that seems to have everything covered. In SAFe most of the clever thoughts that have been thought over the past decades in the lean-agile space have been combined.

Lean, Scrum, Kanban, XP, DevOps, Lean Start-up are all part of SAFe, just as it has borrowed the Scrum Master and Product Owner from Scrum. On top of that, several new concepts and titles have been introduced. E.g. “Agile release trains”, “Solution trains”, “Release train engineer”, “Program Increments”, “Innovation and planning sprint”, and more.

This makes SAFe a highly complex model, and in fact it adds significant complexity on top of something that is already complex, namely, IT projects and programs. I would argue that this can only work in high-maturity organizations. To be honest, I still have not seen any organization applying more than a few of the elements from SAFe. They use those that are easiest to grasp.

These days I hear people asking questions about Scrum. Why is Scrum not the easy fix, that we hoped it would be? Why do we not see continuous improvement, as we expected? Why has our Scrum come to a stand-still, even though we are doing everything “by the book”? “Why do we have to go to all these meetings. We feel that we are wasting our time? Why are we still late? Etc. etc.

I have no doubt that similar questions will be asked about SAFe sooner or later, when people realize that they have bought into a wonderful but highly complex dream that cannot be put to life unless you (as mentioned before) are working in a highly mature organization.

Just as the agile pioneers turned their backs to the classic methods, I could imagine that there might be a movement away from agile frameworks that are either too loose, so you have to figure too much out for yourself or to rigid and complex, which makes it too demanding for organizations to make it work.

I am not implying that Scrum and SAFe cannot work, they absolutely can. However, there are several organizational requirements and prerequisites that must be met to get success with Scrum or SAFe. Most being of the more invisible kind such as culture, maturity, behavior, discipline, habits, change readiness, politics, values, and such. But what to do if these prerequisites are not met?

Well, luckily there are other (and simpler) paths to agility. More about that in a short while.

How do you get from feeling agile to knowing that you are?

As mentioned, IT projects are almost by definition complex. Therefore, you should do all you can to minimize this complexity, as it makes it easier to keep your projects, programs, or assignments under control. Again, this is where Kanban comes into the picture.

One of the main reasons to “go agile” is often poor project performance, and the classic way of managing projects is often blamed for this situation. However, projects do not fail because of the method you use or your Project Managers for that matter. They are probably well-trained individuals. It is more likely due to lack of organizational or team discipline, lack of needed competencies, and low project maturity, probably combined with several of the other aspects I mentioned above.

However, no agile method or framework can change or improve that. Only people can. But changing organizational culture, behavior, habits etc. is not easy. Most people would prefer to avoid changes if they could choose because it is hard work and requires conscious action. It is much easier to keep on doing what you always did.

That is why simplicity is key. It is much more likely that you will see changes happen if you take a simple path. It also helps if you are very explicit about what you want people to change. What do you want your colleagues to do tomorrow that they did not do today? The Kanban method offers this simplicity, and clear directions, and it offers a path to agility that can start small on the team level and expand to cover the whole enterprise as you become more ambitious.

On social media you often see people cheer about their agile achievements, and I have been working with quite a few agile teams that claim that now they are much more agile than they used to be. I can’t help but ask them: “How do you know? Did you measure it, and can you compare old and new results?”. Sadly, the answer has never been “yes!”.

Feeling agile is probably a rewarding feeling, but if you cannot back-up that feeling with data, there may not be so much to celebrate. If you can back it up, I will be the first to cheer with you. But how to get to the point where you know that you are moving in the right direction, and not just feeling it?

Again, I will point to the Kanban method, and let me explain why.

How Kanban can facilitate improvements in Scrum or agile teams

I have mentioned that it is quite easy to get started with Kanban. First of all, you do not have to change your organization, and that alone makes it simpler. So, if you are organized according to Scrum or SAFe, you just stick to that organization. But you top it up by working with some (or all) of the 6 general practices in Kanban:

  • Visualize
  • Limit work in progress (wip)
  • Manage flow
  • Make policies explicit
  • Establish feedback loops
  • Improve collaboratively, and evolve experimentally

If you are producing knowledge work, i.e. something that is not a physical thing, you can use Kanban to control and improve your services delivery.

Let us take Scrum as an example and look at how a few of the Kanban practices can be put to use to improve performance. Scrum Teams usually work with a minimal workflow. Often: “To do”, “Doing”, and “Done”. Kanban takes the workflow several steps further and visualizes what is actually happening end-to-end.

Are you analyzing what to do before you really start working on your task? Do you have a QA or testing procedure? Does it involve your users? If yes, your workflow might look like this: “To do”, “Analyze”, “Develop”, “Internal test”, “UAT”, and “Done”. This is one example of visualization. In this case an invisible workflow has become visible.

You might also visualize what is blocking your progress, and whether you can do something about it or not. You might visualize how long time an item has been blocked, what actions you have taken etc. This also helps create transparency which in turn gives you a healthy basis for decision-making. Decisions that will help you minimize the negative consequences of your blocked items, and result in reduced lead times, which ought to be what any team or organization should strive for.

Limiting wip is also a key to shorter lead times. The fewer activities you have in progress, the quicker everything goes. You can simply complete more in less time if you facilitate focus and less task switching by limiting wip. This can be done in any kind of team, and you can still work with time boxes, such as sprints if you prefer to. That is your own decision.

The same is true for the practice, manage flow. If you keep an eye out for tasks that are sitting idle in your Scrum board or have been blocked for some time, and manage these tasks proactively, you will …. Yes, you guessed it.… reduce lead times. In fact, this is also one of the ways that Kanban manages risk.

It would be taking it too far to go through all 6 practices, but they all boil down to the fact that there is much to gain if you succeed in reducing (project) lead times. Stable velocity or good estimates that drown in organizational “dirt” do not tell you much about your performance whereas lead times do. They clearly indicate if things are moving in the right direction. In a more agile direction.

With Kanban there is no wishful thinking, no crystal balls, or wild guesses. Kanban is data-based, which means that you act on facts and with your eyes open. Facts like actual lead times, facts about how long activities have been blocked and why. E.g. when waiting for a specialist, a decision, a 3rd party vendor etc. Applying good Kanban practice to your Scrum or Agile Team will help you increase transparency and improve efficiency.

I think of it as holding a mirror up in front of your team or even the entire organization, so you can see what is actually going on. Both god and bad. This makes it possible to determine where you would benefit from adjusting your system, your behavior etc. and improve one step at the time. Evolutionary change is more likely to stick and become good new habits.

High transparency can be scary for some, and it can be difficult to accept that there will always be something to improve. Reality may show that you are not as efficient that you would like to think, but the good thing is, that now you know so you can do something about it. Ambitious agile teams should welcome transparency and be ready to fix what does not work without annoyance, finger-pointing or blame games.

A few final words

I have given you a few examples of how the use of some of the 6 general Kanban practices can help Scrum or agile teams to improve their efficiency. There is much more to Kanban than this, but it would be very efficient first steps to bring these practices into play.

It would be a powerful yet simple path to higher productivity and agility without stressing or disrupting your team or organization. Why not give it a try?

P.S. This article has been published on the Digité blog too. Her you can find articles about Lean, Agile, Kanban and Successful Project Management see more on: https://www.digite.com/blog/

Read my new post about how Scrum and Agile Teams can benefit from using Kanban

Posted in Adopting agile, Agile failure, Agile implementation, Agile management, Agile maturity, agile realism, Agile transformation, Uncategorized | Tagged , , , , | Leave a comment

From idealized agile pictures to agile realism

A few days ago I read a really interesting article by Jan Wischweh. The topic was “The agile crisis”. (It was published on Medium.)

Jan W.’s article was spiced up with quotes by some of the agile heavyweights who back in 2001 signed the agile manifesto. Here are the two quotes, that I love the most. Robert C. “Uncle Bob” Martin says:

1. “An efficient business discipline coupled to an undisciplined engineering team will very rapidly make a mess”

2. “An Agile team will be Agile no matter how the project is managed. On the other hand, a team that is not Agile will not become Agile simply by virtue of a new and fancy project management strategy”

Isn’t that so very true?

How often have your experienced that the focus when it came to IT-projects was almost solely on the Project Manager and the project method? E.g. PRINCE2, PMI or if we are in the agile world (this is where I am most of the time) then Scrum? As if this was the determining factor of project success…

If we take a look at Scrum, the main concern of many (managers and Scrum Teams alike) is to ensure that the Scrum events are held as they are supposed to. They focus on appointing a Scrum Master and a Product Owner (often any will do), and on doing ”the mechanics” slavishly.

But I have to ask: What about the values and the mindset that play such an important part in making Scrum work, and which also, if not primarily, lies on the shoulders of the IT developers? Just to mention a few:

  • Technical excellence!
  • Respect
  • Customer focus – well, in fact just focus
  • Openness
  • Commitment – e.g. to a sprint goal
  • Assuming responsibility
  • Transparency

Tough value-based prioritization is also ultra-important. This is where the Product Owner and the somewhat extendable concept of ”the business” come into the picture.

And while we are at it, let’s not forget “the Management”. Managers should respect the framework, support their Scrum Teams, and give their Product Owners the mandate to make decisions e.g. about priorities, as they are supposed to know best. (This is only rarely the case).

This is all about how values, mindset, culture, and all the “soft stuff” play an essential part in making Scrum work. But changing habits – sometimes very old habits – is extremely difficult. It is very hard work.

Did I mention, that I like Scrum a lot (when it works), and deliver Scrum training too?

No method (or framework) can save a poor organizational culture or prevent non-constructive behavior

But – and here comes the unpleasant truth – “the mechanics” don’t really matter, if they are all you enforce. A “fundamentalist” practice just for the sake of the practice will give you zero agility. This viewpoint is very well supported by the 2 ”Uncle Bob” quotes above.

Please, could we start increasing our focus on developer and management behavior? The sooner the better, because this is probably the most important part, if you want to get your agile motor running.

For several years I have been deeply annoyed with Scrum zealots, stubbornly insisting that if Scrum doesn’t work, it’s because ”you are doing Scrum WRONG”. This is nonsense. Scrum just doesn’t work everywhere. Neither does SAFe by the way.

In both cases there are prerequisites that must be met. Here are some of the most important points that will determine if Scrum and/or SAFe are realistic options:

  • Willingness to change
  • Maturity
  • Level of competence
  • Organizational structure
  • Culture
  • (Management)behavior
  • Processes
  • The types of work you do and the diversity
  • Stamina
  • Level of quality

I love ”agile”. I have absolutely seen it work and made it work with my own hands. But it’s not easy. ”Agile” is very much a ”people-thing” and it’s a big change to move in a more agile direction, if you are not the least bit agile already.

If you do decide, that organizational agility is a realistic possibility, and worthwhile pursuing, then you should carefully examine, which path to agility would be the best choice for you. There are several to choose from, but it should be your context that determines the way.

Although you may have a desire to become more agile, the conclusion you reach regarding the above points will determine if it makes sense to go ahead, or if you might as well save your time and money. Depending on the conclusion, some agile options might work, but some will not.

A “one-size-fits-all” method does not exist. Nor does an ”easy fix”. But if you want to take the simplest (and cheapest) path, then there are some methods and frameworks you should simply avoid due to their complexity. Even if they are popular and seem like “the thing to do” because that’s what others do. It pays to not be like agile lemmings.

The only method that I – based on my long, practical experience with “Agile” (and my professional pride and integrity intact) – dare recommend for any organization, team or project delivering services and doing knowledge work, is Kanban. Kanban facilitates systems thinking, systematically manages work and options (not people), and optimizes lead times (aka flow).

Let me tell you a bit more about Kanban for service delivery:

Independent of maturity, you can start small and then sharpen the Kanban knife as you move along and get your processes sorted out, together with your dependencies, blockers, and other killers of efficiency that we all know too well. In other words, Kanban facilitates evolutionary, sustainable change.

Kanban is the “start with what you do now” method. You don’t have to change your organization or fire your Project Managers. Kanban can be combined with basically any other method including Scrum, it scales up and out, and is flexible. But of course you must follow a few (simple) rules to make your Kanban system work.

If you want to learn Kanban, the Kanban-University-way, I invite you to jump on my certification course ”Team Kanban Practitioner”. The 25th February 2020, we are going to nerd ”agile” in the middle of Copenhagen. But until then, I can highly recommend you to read about ”The agile crisis”! (It made me think KANBAN!!)

You can also subscribe to my news letter, (for the moment only in Danish). Then you will be the first to know, when I offer Scrum or Kanban certification courses, etc. And not least when I start up my new agile master class. Of course you will always receive tips, tricks and news about “agile”, and what happens on the agile forefront. No spam. I promise!

P.S. I certainly deliver my courses in English too, so let me know, if you need a company course or just a course in English. I would absolutely love to!

Warm regards,
Annette Vendelbo

Posted in Adopting agile, Agile, Agile management, Agile transformation, Agilt mindset, Change Management, Kanban, Organizational agility, Scrum, Transparency, Uncategorized | Tagged , , , , , | Leave a comment