I HATE Transparency!!!

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

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

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

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

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

Where does fear of transparency come from?

Well, 3 answers apply:

  1. Culture
  2. Culture
  3. Culture

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

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

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

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

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

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

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

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

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

Agile looks deceivingly simple, but….

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

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

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

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

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

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

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

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

Debunking 3 big myths about Kanban

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

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

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

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

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

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

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

 

Posted in Adopting agile, Agile implementation, Agile transformation, Kanban, Uncategorized | Tagged , , , , , | Leave a comment

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

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

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

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

Og hvorfor fortæller jeg så det?

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

Er det ikke ulogisk?

Sund fornuft og sund praksis følges ikke altid ad

Nej, det er ikke så ulogisk endda.

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

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

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

På bagsiden står bl.a.:

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

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

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

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

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

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

Det gør ikke ondt

Det føles trygt

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

Man får ikke det hele for det halve

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

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

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

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

Det er bekvemt, nemt og meget letkøbt.

Jeg lægger ikke igen ryg til halvhjertede agile tiltag

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

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

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

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

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

 

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

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

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

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

It’s all about managing change

Resistance to change

Fear of change

Unwillingness to change

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

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

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

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

kanban-and-scrum-values

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

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

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

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

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

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

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

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

The top-5 reasons for not wanting to embrace agility

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

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

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

More “dictatorship”, more action. less talk

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

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

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

PPS: My Kanban book will give you many more details

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

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

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

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

I kan sikkert nikke genkendende.

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

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

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

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

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

Det agile mindset er et paradigmeskift

alignment-vs-autonomy

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

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

Agilitet i øjenhøjde

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

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

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

Agil transformation – fra tanke til implementering

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

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

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

 

 

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

Scaled agile frameworks and methods? Don’t waste your time and money in an attempt to make the unworkable work

It has been a while since I have had a chance to write on my blog, and have I missed it!

You may be a busy person too and want to go directly to my latest article on TechBeacon about why you should save your time and money to scale agile if your organization is not ready for it: http://techbeacon.com/are-scaled-agile-frameworks-worth-trying

If you are interested in reading a bit more about agile transformation at first: Please continue reading  🙂

For the past several months I have been heavily involved in introducing and coaching companies in how to introduce agile thinking and principles. These organizations were looking for better project results, improved lead times (=time-to-market), better flow, fewer internal blockings, less waste in their system etc.

These are traditionally organized organizations with too many silos, and not enough collaboration between the silos. As always, there are dependencies between the silos. These are often handled too late causing delays, ripple effects on other projects or initiatives. AND they cause a lot of frustration at all levels.

No doubt the transformation to a more agile approach will improve performance and project results in these companies, but the main reason why I believe that these transformations will actually happen, is the strong management support behind the initiatives and an honest desire to change the organization. Knowing that this change will not come over night.

If you don’t have back-up and support from the management layer, a transformation from traditional project thinking to agile will not happen. You may see improvement on the team level here and there, but nothing significant seen from the helicopter perspective.

Agile systems require a different way of managing people, teams, and projects, and this is not intuitive. In fact it is a paradigm shift. It takes time to adjust your old (bureaucratic) habits to new agile ways, and this adjustment in a whole organization will take years.

Someone has to say it: There is no easy way. No free lunch. No silver bullet. If there were, we would have found it ages ago.

When you start an agile transformation, there is often a desire to scale it to the program level. However, it does not make sense to scale e.g. Scrum, if Scrum is not working properly in your organization. If the roles are not filled by people with the right skillset, if the Product Owner don’t have the authority to make decisions, if there is no agile mindset, agile just will not work, and scaling it will only make things more complicated.

That caused me to write an article about why you should save your time and money to scale agile if your organization is not ready for it. My article has been published on TechBeacon, and you can read the details here: http://techbeacon.com/are-scaled-agile-frameworks-worth-trying

Enjoy! If you have questions or comments please feel free to make them here or send me a mail on annette@xvoto.dk.

Posted in Adopting agile, Agile, Agile implementation, Agile project management, Agile transformation, Good practice, Management responsibility, Organizational agility, Project efficiency, Project Management Methods, Uncategorized | Tagged , , , , , , , | Leave a comment

Sådan gør Kanban livet som projektleder lettere

If you wish to read this article in English, please go to TechBeacon: http://bit.ly/Knbn4PM

IT-projekter er pr. definition komplekse, og det er være IT-projektleder (PL) er en mangefacetteret og svær rolle at udfylde godt. Du leder teams, styrer budgetter, kontrakter, planer og de risici, som måske rammer dig. Du skal gøre dine chefer og interessenter tilfredse, og du styrer måske underleverandører.

For at strukturere disse forskelligartede opgaver har de fleste organisationer implementeret en projektmetode. Mange inspireret af PMI, PRINCE2 eller IPMA m.fl. Men hvorfor ser vi så stadig så mange projekter, der fejler?

Gennem de sidste 10 år har PMI lavet en årlig undersøgelse og udgivet resultaterne i en rapport, “Pulse of the Profession”. Rapporten har gennem årene vist, at kun ca. halvdelen af de projekter, vi starter, gennemføres inden for den afsatte tid og budget. Desværre viser den seneste rapport fra februar 2016 en nedslående tendens. Flere projekter fejler i 2015 sammenlignet med 2014. Se nedenfor:

PMI Pulse Report 2016 state of proj. outcomes

Agilitet har ført til så meget Scrum, but…

De tunge procesbaserede projektmetoder har projektlederen i centrum og fokuserer mere på at levere alle kravene i en kravspecifikation end den kvalitet og værdi, som reelt efterspørges. Der er implicit sat lighedstegn mellem kravspecifikationen og den ønskede kvalitet/værdi, hvilket bestemt ikke altid er tilfældet.

Da Scrum dukkede op i 1990erne, svingede pendulet i den modsatte retning. Der kom større focus på teamet, og projektlederen blev taget helt ud af projektligningen. I det mindste i teorien. Scrum arbejder med et defineret sæt roller, møder og artefakter, og introducerede et helt nyt ordforråd.

Selvom undersøgelser viser, at en agil projekttilgang giver større projektsucces, har Scrum ikke været løsningen på alle vores projektproblemer. Der er nemlig en række faktorer, der afgør om man får succes eller fiasko på sine Scrum-projekter:

  • Organisationens modenhed og forståelse af agile sammenhænge
  • Team-modenhed og -kompetencer
  • Hvorvidt team-medlemmer er allokeret til flere/mange projekter
  • Effektive product ownere, der forstår rollen
  • Accept af transparens og visualisering

Virkeligheden viser, at forudsætningerne for god Scrum kun sjældent er til stede. Agile teams skal fungere i ikke-agile organisationer. Projekt-teams forstår ikke Scrums DNA og hvad det kræver af teamet. Product Owner rollen bliver ofte ikke udfyldt effektivt, og det er ikke alle, der er begejstrede for transparens. Nogle føler sig intimiderede af, at alle ved, hvad alle andre laver og at åbent diskutere produktivitet og fremdrift.

Scrum er heller ikke nemt at få til at fungere i en stærk ”control-and-command” kultur, ligesom det er en stor udfordring at skalere Scrum til program- og porteføljeniveau. Hvordan tackler vi risici, afhængigheder, snitflader m.v. mellem flere Scrum teams, der arbejder på ét produkt? Scrum virker fint på mindre software-projekter, men knap så godt på program- eller porteføljeniveau.

For at gøre en lang historie kort: Hverken de traditionelle metoder eller Scrum har givet os de projektresultater, som vi øsker. Begge kan løse nogle af vores projektproblemer, men ikke dem alle.

Sådan gør Kanban livet som projektleder lettere

Da jeg i sin tid faldt over Kanban, gik det op for mig, at det måske var den løsning, jeg ledte efter. Bl.a. fordi Kanban respekterer de roller, titler, hierarkier m.v., som findes i en given organisation, og så starter optimeringsrejsen fra dette udgangspunkt. Kanban er lige så meget et mindset som en metode.

At gå i detaljer med Kanban-metoden bliver for omfattende. Men én ting der giver stor mening fra et projektlederperspektiv er, at man arbejder altid med de vigtigste aktiviter først, så hurtigt man kan. Denne adfærd fremmes i kraft af de seks Kanban-praksisser:

  1. Visualisér aktiviteterne
  2. Begræns igangværende arbejde
  3. Styr og optimér flow
  4. Lav eksplicitte regler
  5. Implementér iterativ feedback
  6. Gå efter forbedringer i fællesskab, og vha. ’eksperimeter’

Kanban har visse ligheder med Scrum. F.eks. visualisering og iterativ feedback, men tilgangen er helt forskellig. Men Kanban kan du håndtere forskellige typer af arbejde på én tavle, tavlen er aldrig tom, og du fokuserer på flow. D.v.s. at gøre dine aktiviteter færdige. Mantraet er: “Stop starting – start finishing”.

Dette er virkelig tiltrængt. Det forhindrer nemlig projektaktiviteter i at være 90, 95, 98% færdige i evigheder. Men det bedste af det hele er, at du slipper for at lave detaljerede projektplaner, aktivitetslister, Excel-ark m.v.

Kanban viser og måler alle arbejdstyper

Jeg har prøvet, men det har været umuligt at planlægge mit projektlederarbejde i sprints, men med Kanban kunne jeg synliggøre og måle alle mulige forskellige aktiviteter. F.eks.:

  • Tekniske aktiviteter
  • Gentagne PL-aktiviteter (F.eks. møder, status- og risikorapportering)
  • Opgaver med deadlines
  • Underleverandørarbejde
  • Uplanlagte aktiviteter

Mens det giver mening at begrænse igangværende arbejde på de aktiviteter, vi selv kontrollerer, så gør det ikke på underleverandørarbejde. Jeg visualiserer alligevel underleverandøraktiviteter og deadlines og følger op på disse. På den måde får du et holistisk overblik over dit projekt på din Kanban-tavle. Det giver også værdi at visualisere og måle aktiviteter, som tidligere var usynlige. F.eks. uplanlagt arbejde. Jeg måler, hvor meget tid, der bruges på aktiviteter, der kommer ”ind fra venstre” og de tilhørende omkostninger.

Med Kanban kan du faktisk organisere dit arbejde i alle slags organisationer, hvis ellers du kan få lov. Det eneste du skal bruge og gøre er følgende:

  1. En stor tavle, farvede PostIts og magneter
  2. Afstem forveningerne med din styregruppe, (hvis du har en).
  3. Forklar:
    1. Hvordan en simplere projektrapportering stadig holder dem i kontrol,
    2. Hvordan simple metrikker viser tendenser, uønsket varians og fremdrift
    3. Hvordan visualisering altid viser den virkelige projektstatus
  4. Aftal med dit team, hvordan I vil arbejde med Kanban (nej, Kanban er ikke kun en stor aktivitetstavle)
  5. Beslut jer til at følge princippet: “Stop starting – start finishing”
  6. Vis forudsigelighed og stabilitet (som kommer automatisk, når i har udført ovenstående 5 punkter)

Løser Kanban så alle dine projektudfordringer?

Selvfølgelig ikke. Men svaret på dårlige projektresultater har hidtil være at tilføje flere kontrolmekanismer, bureaukrati, processer og kompleksitet til projektmetoden. Det har kun gjort den vanskelligere at bruge som projektleder og samtidig gjort det vanskelligere for resten af organisationen, at forstå deres rolle i projektsystemet.

Der vil altid være beslutninger, dilemmaer og kompleksitet i IT-projekter, som ingen metode kan fikse. Men Kanban har bestemt gjort mit liv som projektleder nemmere, og som den vigtigste bonus har resultatet været hurtigere projekter og højere succesrater. Det er da værd at tage med!

Posted in Adopting agile, Agile, Agile failure, Agile implementation, Agile project management, Best Practice, God praksis, Kanban, Management, Organisatorisk agilitet, Organizational agility, Project efficiency, Project Management, Project Management Methods, Project maturity, Projektledelse, Projektmetode, Projektmodenhed, Projektteams, Scrum, Uncategorized | Tagged , , , , , , , , , , | Leave a comment

3 ting du som leder kan gøre noget ved med det samme og få øjeblikkelig positiv effekt på dine projekter

Forskning har gennem de sidste mange år vist, at en af de faktorer, der har størst betydning for projekters succes er aktiv ledelsesopbakning. De organisationer, der præsterer godt og stabilt på deres projekter har for 81% vedkommende aktive projektsponsorer. Du kan fordybe dig i tal og detaljer her: PMI Pulse of the Profession 2015

Når nu alt peger på, at stærk ledelsesopbakning giver mere succesfulde projekter, så skulle man tro, at lederne står i kø for at give opbakning til deres projektledere. Men her bliver man skuffet. Som projektleder oplever man meget ofte, at ens projektsponsor, styregruppe m.fl. kun holder sig overfladisk orienteret om de projekter, de er overordnet ansvarlige for.

Projekter opleves tit som et nødvendigt onde, der ikke som sådan kommer ledelsen ved: ”Vi har jo en projektafdeling”, lyder det.

Ofte opfatter ledelsen udelukkende sig selv som et eskallationspunkt, og giver ikke sine projekter den løbende bevågenhed, der er så afgørende for, om deres projektledere kan levere sunde, succesfulde projekter.

Hvad er god ledelsesopbakning?

Ledelsesopbakning kan jo være mange ting, men for lige at starte med, hvad det ikke er, så er det langt fra nok, lejlighedsvis at spørge sin projektleder:

  • Nå, leverer du så mit projekt til tiden?
  • Overholder du det budget, du har fået?
  • Hvad med kvaliteten? Er den OK?

Dét er simpelthen for letkøbt og et udtryk for, at automatpiloten er sat til.

Her er de 3 områder, hvor det virkelig halter, og hvor du som leder med fordel kan sætte ind

1. Prioritering af projektporteføljen, så det er helt tydeligt, hvilke projekter, der er vigtigst og har størst forretningsmæssig værdi

Det vi ofte ser ”derude”, at der er et antal prioritet 1 projekter, et antal prioritet 2 osv. Hér savner vi, at ledelsen tager ansvar for en ægte prioritering.

Ligesom i sportens verden kan der kun være én nr. 1, én nr. 2, én nr. 3 osv. Det kan ikke være anderledes. Men denne mekanisme er ofte sat ud af kraft i projektverdenen, og man hører ofte, at ”alle projekter har topprioritet”.

Det kan jo ikke passe.

Hvis alt er vigtigt, er intet vigtigt.

Der være et projekt, der er vigtigere end alle andre.

Derefter et andet, der er nr. 2 på listen osv.

Ofte mangler der også overblik over hvilke projekter, der er i gang i virksomheden. Det sker oven i købet, at flere afdelinger arbejder på hvert deres projekt, der skal løse det samme problem. Den ene afdeling ved bare ikke, at de andre også er i gang. Det er rendyrket spild!

Hold styr på din projektportefølje og prioritér den. Det forbedrer automatisk projektresultaterne

2. Lad være med at starte flere projekter ad gangen, end der er kapacitet og kompetencer til

Hvis du mod al fornuft gør det alligevel, så betyder det, at dine ressourcer smøres for tyndt ud. Jo flere projekter de fordeles på des værre.

Folk bliver nødt til at multitaske, hvilket er ineffektivt og giver projektspild. Det stresser medarbejderne, og kvaliteten lider. Konsekvensen er typisk forsinkede projekter og en blødende projektbundlinje.

Når man ikke afpasser udbud og efterspørgsel i sin organisationen, så får man projekter, der fortsætter i det uendelige. Dét er dyrt, det binder ressourcer, og de gevinster, man ønsker at høste kommer sent

Man kan ikke ophæve tyngdekraften, og man kan heller ikke presse flere projekter ind i en organisation, end der er kapacitet til og samtidig regne med gode projektresultater.

Gør alle inklusive din bundlinje en tjeneste og afpas udbud og efterspørgsel.

3. Sidst men ikke mindst: Træf robuste, rigtige og rettidige ledelsesbeslutninger baseret på konkret og præcis viden

Projektledere kan typisk træffe beslutninger inden for de afstukne projektrammer, mens strategiske projektbeslutninger træffes af ledelsen.

Det ses ofte, at ens projektsponsor, styregruppe m.v., der er ultimativt ansvarlig for projekterne, kun holder sig overfladisk orienteret, og ikke ved nok om projekterne til at kunne træffe de rigtige beslutninger første gang.

Samtidig kan ledere godt lide at træffe beslutninger.

Dét er en farlig coctail, der ofte giver tømmermænd i form af forsinkede, dårlige eller ligefrem forkerte beslutninger.

Det betyder, at man må i tilbageløb og lave ting om. Dét er frustrerende, og det er dyrt!

Som leder må du ikke undervurdere betydningen af at være tæt på dine projektledere. Hvis du sætter dig godt ind i de projekter, du har ansvaret for, og kan du træffe ”on-demand” beslutninger, så vil du straks se en positiv effekt på projektresultaterne.

Du får lige den hurtige opsummering af de 3 gyldne regler:

  1. Prioritér projektporteføljen efter forretningsværdi
  2. Lad være med at starte flere projekter op end organisationen har kapacitet til
  3. Træf rettidige, sunde og velgennemtænkte projektbeslutninger baseret på konkret viden

Du behøver ikke at gøre alle 3 ting på én gang, men når du ser resultaterne, er det svært at stoppe 🙂

Posted in Best Practice, Ledelse, Ledelsesansvar, Management, Management responsibility, Project efficiency, Project maturity, Projekter og forretning, Projektmodenhed, roller og ansvar | Tagged , , , , , , , | Leave a comment

This is why you need to be razor sharp when specifying roles and responsibilities on your project

All project management methods include an activity to specify roles and responsibilities. In Scrum the roles as Scrum Master, Product Owner and the Team as well as their separate areas of responsibility, are clearly defined. In Kanban, flow is controlled by balancing supply and demand, and Kanban respects the roles that are in place in each individual organization. In both systems you use Post-its and note who does what etc.

In PMI, IPMA and PRINCE2, the roles and responsibilities for the steering committee, the Project Manager and the Team are also clearly defined, and there is emphasis on stakeholder and communication management. (Don’t forget that your project team members are also stakeholders). All processes are clearly defined with input and output for each process step.

So why do projects still fail?

They fail, because you cannot fit people into a formula!

Imagine that a project manager comes up to you and says that you are needed on a project. Your skills will be needed in 3 months’ time. You think that it sounds reasonable and suggest that the project manager makes further arrangements with your manager. After this, you don’t hear anything before “5 minutes to 3 months”, when the project manager returns and asks if you will be done soon? “What with?” you ask. In fact, you have forgotten all about the delivery that the project manager asked for approximately 100 years ago, cleared with your manager, but didn’t follow up upon.

This might be pushing things to extremes, but it happens over and over again, that you assume that once you have discussed something once, or if you have sent an email with a deadline, then the delivery will be ready exactly on time. You forget that a project, which may be the most important in the world for you, is not necessarily important to your colleagues. To them projects are typically a stone in the shoe, because they always result in extra work on top of the tasks, that they were hired to do.

Assumptions are the root to all evil!! You must immediately forget:

  1. I assumed that…
  2. I felt that…
  3. I imagined that…

Make clear agreements, communicate precisely, and follow up. Not only once but several times, because people forget or postpone the project task, or they hope that it will go away. Not because they want to make it difficult for you, but because they are busy with everything else but your project.

But does management not leave room for participation in projects for all the project workers?

The answer is a loud and clear NO!! During my + 20 years working with IT projects, I have never seen any organizations organize themselves in a way that leaves room for the employees to participate in projects.

This means that when you need a resource on your project, you have to fight like crazy, because when this person is taken away from his daily work, there are activities that will not be done, will be delayed or might even fall between two stools. But if the resource is not put at your disposal, you cannot proceed in your project. So you end up stuck between a rock and a hard place.

While you discuss the resource situation, your project is delayed, and delayed projects result in exceeded project budgets. That is a fact.

This is what you can do as a project manager

Insist that resources are allocated to your project in “whole pieces”.

You have to avoid – at any cost – that you get resources that are allocated a few hours here and there. You very often see that especially key resources are spread too thin on several projects – 10% here and 15% there. These are “desk allocations” making it impossible to carry out any activity effectively, and it is very unproductive. The consequence is that a task, which is estimated to 3 days, on condition that you have 3 days in a row to complete it in, suddenly takes several weeks to complete, and exceeds the estimated 3 days, because your resources have to do a lot of task switching.

Which brings us straight back to delayed projects and project budgets at risk. In your plan, the 3 estimated days are 3 consecutive days. If reality shows, that the 3 days are chopped up and distributed over several weeks – and thereby underestimated – the project will be delayed.

As a minimum, you have to communicate the consequences of poor resource allocation, which will be exceeded budgets and time delays.

Make explicit agreements with your project team

Just to show in your project plan that you need a certain competence, does not mean that your will get what you need. Make clear agreements on, exactly who you can expect to be allocated to your project, exactly when the resource will be available, and also communicate the consequences of a potential lack of required competencies.

Important! Ask your resources to confirm that they have accepted their tasks, and that they know, what it takes to complete them. Make sure that they have enough time. It is not enough that they tell you that, “they will do their best”. Don’t we all? They have to convince you that they can deliver on time.

To sum it all up

Be very explicit, when you specify roles and responsibility on your project, make precise agreements and communicate often. Your colleagues will not “figure it out”, and “somebody” has never made anything happen – only real people get things done!

Posted in Management responsibility, Project efficiency, Project Management, Project Management Methods, Project maturity, Resource allocation, Roles and responsibilities, Uncategorized | Tagged , , , , , | Leave a comment

Derfor skal du være knivskarp, når roller og ansvar skal fordeles på dit projekt

I alle projektmetoder sker en tydelig fordeling af roller og ansvar. I Scrum er rollerne som Scrum Master, Product Owner og Teamet og de tilhørende ansvarsområder klart beskrevet. I Kanban styres flow i arbejdet ved at balancere udbud og efterspørgsel og med en rollefordeling baseret på, hvordan den enkelte organisation arbejder. Man bruger gule lapper og noterer, hvem der laver hvad.

I PMI, IPMA og PRINCE2 er roller og ansvar for styregruppe, projektleder og team også klart beskrevet, og interessentstyring og kommunikation er i fokus. (Husk lige, at dine projektressourcer også er interessenter). Processerne er klart defineret med input og output til hvert procestrin.

Hvorfor går det så alligevel galt?

Det går galt, fordi mennesker ikke kan sættes på formel!

Forestil dig, at en projektleder kommer og fortæller, at der er brug for dig på et projekt. Du kan noget, som de har brug for om 3 måneder. Du synes, at det lyder fornuftigt, og foreslår, at projektlederen aftaler nærmere med din chef. Derefter hører du intet, men 5 minutter i 3 måneder er projektlederen tilbage, og spørger, om du snart er færdig. ”Med hvad” siger du. Du har nemlig glemt alt om den leverance, som projektlederen for 100 år siden fortalte dig om, og derefter klappede af med din chef, men ikke lige fik fulgt op på.

Dette er sat lidt på spidsen, men det sker igen, og igen, at man antager, at når man én gang har talt om tingene, eller sendt et mail med en deadline, så kommer leverancen præcis til tiden. Man glemmer, at det projekt, der er vigtigst i verden for mig, ikke betyder noget for kollegerne. For dem er projekter typisk en sten i skoen, fordi de altid kommer oven i de opgaver, de egentlig er ansat til at lave.

Antagelser er roden til alt ondt! Glem straks:

  1. Jeg antog, at…
  2. Jeg følte, at…
  3. Jeg forestillede mig, at…

Lav tydelige aftaler, kommunikér klart og følg op. Ikke kun én gang, for folk glemmer eller udskyder projektopgaven, eller håber, at den går væk. Ikke fordi de vil genere dig, men fordi de har travlt med alt muligt andet end dit projekt.

Giver ledelsen da ikke plads til deltagelse på projekter for alle, der har projektarbejde?

Svaret er et rungende NEJ! I mine +20 års arbejde med IT-projekter har jeg aldrig set nogen organisere sig, så der er plads til projektdeltagelse i organisationen.

Det betyder, at når man skal bruge en medarbejder på sit projekt, så må man kæmpe som besat, fordi når denne trækkes ud fra sit daglige arbejde, så er der noget der ligger stille, bliver forsinket eller måske endda falder på gulvet. Men får man ikke medarbejderen til rådighed, kan man ikke komme videre med sit projekt. Altså pest eller kolera.

Mens man diskuterer ressourcesituationen, forsinker man projektet, og forsinkede projekter belaster projektbudgetterne. Sådan er det bare.

Dette kan du selv gøre som projektleder

Insistér på, at folk bliver allokeret til dit projekt i ”hele klumper”

Du skal for enhver pris undgå, at få projektressourcer, der er allokeret et par timer hist og pist. Ofte bliver især nøgleressourcer smurt tyndt ud på flere projekter – 10% hér og 15% dér. Dette er ”skrivebordsallokeringer”, som gør det umuligt, at få opgaven løst optimalt, og det er uproduktivt. Konsekvensen er nemlig, at en aktivitet, der tager 3 dage, hvis man får tre hele dage til det, pludselig er flere uger undervejs og tager længere tid, fordi man hopper til og fra opgaven.

Så er vi tilbage til forsinkede projekter og belastet projektøkonomi. I din plan ligger de estimerede 3 dage i et samlet stræk. Hvis virkeligheden er, at de 3 dage er hakket op og fordelt over flere uger og derfor er underestimeret, så bliver projektet forsinket.

Som minimum må du kommunikere den økonomiske og tidsmæssige konsekvens af dårlig ressourceallokering.

Lav klare aftaler med dem, der skal levere på dit projekt

At vise i din plan, at du skal bruge en bestemt kompetence, er ikke ens betydende med, at du får, hvad du skal bruge. Lav klare aftaler om, hvem du kan få på dit projekt, hvornår, og kommunikér konsekvenserne af evt. manglende kompetencer.

Vigtigt! Få dine ressourcer til at bekræfte, at de har påtaget sig opgaven, ved, hvad der skal til, og har afsat den nødvendige tid. Det er ikke nok, at du får at vide, at de ”vil gøre deres bedste”. Don’t we all? De skal sandsynliggøre, at de kan levere til tiden.

Summa summarum

Vær meget eksplicit, når du fastlægger roller og ansvar på dit projekt, lav præcise aftaler og kommunikér ofte. Dine kolleger regner den nemlig ikke ud, og ”Nogen” har aldrig fået noget fra hånden.

Posted in Best Practice, Forventningsafstemning, Interessentstyring, Kommunikation, Ledelse, Project efficiency, Project Management, Projektøkonomi, Projektledelse, Projektmetode, Projektmodenhed, roller og ansvar | Tagged , , , , , , , , | Leave a comment