Hur blir man mer agil?

Vad innebär det egentligen att arbeta agilt och vad är skillnaden mot att inte göra det? De flesta som inte jobbat agilt med ramverk som Scrum, Kanban eller DevOps ser det som något hippa IT-företag håller på med där de sätter upp post-it lappar på väggen. Det är sant att nästan alla agilister älskar post-its, men att arbeta agilt handlar om något helt annat! Agilt arbetsätt eller agila metoder är i grunden en filosofi som genomsyrar allting på arbetet: från vilka mål man sätter upp, till hur man organiserar sig, till hur ens arbetsdagar ser ut. Här är de saker som är mest utmärkande när man jobbar agilt.

1. Hantera osäkerhet
2. Snabb kundnytta
3. Produktorienterat
4. Distribuerat ansvar
5. Synliggöra flöde

Hantera osäkerhet

Det första vi måste erkänna är att vi inte kan veta allt på förhand. Vi lever i en föränderlig värld med yttre omständigheter som ständigt utmanar oss och därtill utvecklar vi ofta saker som vi aldrig gjort innan. Även om vi eller andra gjort liknande saker innan så är förutsättningarna ofta unika för varje projekt. När vi arbetar agilt så prövar man sig fram. Vi tar fram minsta möjliga funktionella version av den tänkta produkten eller tjänsten (MVP), testar den mot den tilltänkta marknaden och låter feedbacken styra utvecklingen vidare.

Snabb kundnytta

När vi bygger ett hus är det väldigt svårt att börja med att först bygga hela köket från grund till tak, för att sedan gå vidare till badrummet och göra samma sak. Vi behöver liksom börja med hela grunden och sluta med hela taket. När vi tar fram tjänster eller bygger virtuella produkter har vi inte samma begränsningar Det innebär att vi inte behöver bygga på samma sätt. Nu kan vi bygga en fullt fungerande enkel chatt utan att ha ägnat en tanke på chattbotar eller videosamtal. På det här sättet skapar vi snabbt kundnytta innan hela produkten är klar. Hur skulle ni kunna dela upp ert projekt per funktion för att skapa snabb kundnytta?

Produktorienterat

När vi analyserar effektiviteten i utvecklingsprojekt har vi sett att den allra största effektivitetstjuven är överlämningar. En person eller avdelning jobbar på produkten ett tag, sedan ska det lämnas över till nästa person eller avdelning och däremellan krävs dokumentation, möten och annan administration. Detta ger upphov till förseningar och missförstånd. När produkten gått igenom ett antal överlämningar så blir det som viskningsleken: Den tänkta chatt-tjänsten blir i slutänden en elvisp. I agila organisationer organiserar vi oss därför oftast i team centrerade kring en specifik produkt eller tjänst. Vi samlar all kompetens som behövs för att utveckla och underhålla denna produkt i det som kallas tvärfunktionella team. Alla jobbar mot samma mål tillsammans. Inga fler knepiga överlämningar!

Distribuerat ansvar

I agila organisationer litar vi på att de som jobbar mest med ett område också är de som kan det bäst. Agila ledare drivs inte av ego utan inspirerar folk att sträva mot gemensamma mål och gör sitt bästa för att undanröja hinder på vägen dit. De detaljstyr inte och lägger liten vikt vid hur man tar sig mot målen. Detaljerna bör vi delegera till teamen som förväntas veta bäst hur saker ska utformas för att uppnå målen. Som en agil ledare behöver man därför vara lyhörd och justera sina mål utifrån förändringar i omvärlden, kundernas feedback och teamens synpunkter. Att få ledarna att släppa kontrollen är normalt sett det svåraste i införandet av agila arbetssätt. Men det gäller också att ha team som är villiga att axla ansvaret. De måste kunna ta en del obekväma beslut och inte bara vänta på order uppifrån.

Synliggöra flöde

Nu kommer vi äntligen tillbaka till våra älskade post-its! Om vi bygger ett hus eller en bil så är det väldigt tydligt hur långt vi har kommit och vad som är kvar att göra bara genom en okulär besiktning, dvs gå runt och kika lite. När vi bygger icke-fysiska saker är det inte alls lika uppenbart. Hur långt har vi kommit? Vad är kvar att göra? Vad är det vi bygger egentligen? Det är här de agila metoderna med sina olika ceremonier och artefakter kommer in. Product backlog, sprint planning, kanban board, daily stand-ups, demo session, retrospective, etc använder vi för att hålla koll på vad vi gör och ge en överblick på hur vi ligger till. De där post-itsarna på väggen kan man säga är en representation för vårt ofärdiga husbygge, en ögonblicksbild på hur vi ligger till. Men också en markering för den filosofi vi tror på – kundnytta, samarbete, tydlighet och öppenhet.

Om Onbird

På Onbird tror vi på några enkla saker. Vi tror att organisationer idag sitter på en mängd outnyttjade förmågor. Vi tror också på att alltid sträva mot enkelhet. Vidare tror vi på att man först måste definiera vilket problem som man vill lösa innan man definerar lösningen. Slutligen tror vi att vi skapar mest värde åt våra kunder när vi hjälper dem att själva utvecklas och hitta lösningen.

Utifrån det har vi utvecklat en portfölj av tjänster, produkter och utbildningar som vi använder för att hjälpa våra kunder. I portföljen finns kunskap, produkter och lösningar baserade på kända ramverk. Men ramverken kan aldrig vara lösningen eller målet. De kan bäst användas som ett medel för att nå målet. Ibland kallar vi detta för ett ”agnostiskt perspektiv eller förhållningssätt” till ramverk.

Bland våra kunskapsområden erbjuder vi kompetens inom Agile, DevOps, Lean IT och ITSM och ingen av dessa är alltså slutmålet.