Agilt ledarskap
I dagens värld finns det ett stort behov av att snabbt anpassa sig till omvärldens förändringar. Agilt ledarskap är den form av ledarskap som stämmer väl överens med detta arbetssätt, och som med fördel kan användas av organisationer som vill hänga med i den snabba utvecklingen.
Ett sätt att enkelt förstå det agila arbetssättet är att jämföra det med det traditionella, mer ”mekaniska” arbetssättet. I sin bok ”Det agila företaget” listar författarna Lennart Francke och Göran Nilsson fyra områden där skillnaderna mellan de båda systemen är påtagliga:
- Det mekanistiska systemet har ägarorientering. Det agila har kundorientering. I ett agilt företag fungerar horisontell styrning bäst. Den utgår främst från kundernas krav, till skillnad från den vertikala styrningen som bestäms av ekonomiska riktlinjer uppifrån.
- Det mekanistiska systemet använder belöningssystem. Det agila skapar inre motivation. I agil styrning behövs engagerade medarbetare som upplever att de kan vara med och bestämma, som har roligt och som vill ha dialog och delaktighet.
- Det mekanistiska systemet använder granskning för att saker ska bli rätt gjorda. Det agila jobbar med förtroende. För att ett företag ska kunna drivas agilt behöver det finnas förtroende mellan människorna i organisationen. Förtroende ger ofta lojalitet, medarbetarna blir mer benägna att stanna kvar hos den arbetsgivare som ger förtroende.
- Det mekanistiska systemet styrs med noggrann planering. Det agila genom snabb anpassning. Vi kan hantera osäkerhet om framtiden och förbereda oss för den genom planering. Eller så kan vi se till att bli så bra som möjligt på att snabbt anpassa oss till förändring. I agil styrning är det förmågan att anpassa sig som är det viktigaste. Projekten planeras bara i stora drag i början, för att sedan bli mer detaljerat ju längre projektet fortlöper.
Områden att titta på om du vill utgå från ett mer agilt ledarskap.
De viktiga medarbetarna Det är medarbetarna som är de väsentliga personerna inom det agila arbetssättet.
Gränserna suddas ut Ge medarbetarna stor frihet inom givna ramar.
Coacha Den agile ledaren måste använda coaching som metod för att vägleda sina medarbetare. Ledaren i kanske inte har samma kompetens som medarbetaren i fråga, men ska besitta kunskapen om hur man coachar en annan medarbetare till framgång.
Inspirera Den agile ledaren måste förmedla sin vision på ett engagerande sätt. Medarbetarna kräver inte att ledaren skall veta och kunna allt, men de vill känna att ledaren bidrar till positiv energi, inspiration och är beredd att anstränga sig lika mycket som alla andra.
Anpassning I en snabbrörlig värld och organisation betyder förmåga till anpassning allt.
Förnyelse och motstånd För att det agila ledarskapet skall kunna fungera är det viktigt med tillit inom teamet. Att ha kunskap om förändringsledning och de mekanismer som styr människor är till stor nytta eftersom förändringar sker både i organisationen och inom uppdragen hela tiden.
Rak och tydlig kommunikation Kommunikationen har stor betydelse i allt ledarskap. Att skapa en plan för möten inom teamet och uppdraget, vad avhandlas vid vilket tillfälle. Transparens kring framväxten av arbetet, framgångar och problem är också en viktig del av det agila ledarskapet.
Läs om IPMA ® Leader Certification >
Scaled Agile Framework (SAFe)
Ramverket Scaled agile framework som skapats av metodexperten Dean Leffingwell i ett försök att underlätta för hela företag att bli agila. Kärnan i ramverket är att se ett företag i tre nivåer, ur ett it-utvecklingsperspektiv: portfölj, program och team.
På portföljnivån sköts affärsutveckling och utformning av övergripande arkitekturer. Här hittar vi användning av metoder som Lean och Kanban.
Programnivån handlar om att skapa riktlinjer för produkter som utvecklas, hantering av produktsläpp och diskussioner om vilka funktioner som ska finnas i vilka produkter och i vilka versioner av produkterna de ska implementeras. En metod som används är DevOps.
På teamnivån utvecklas den mjukvara och andra funktioner som behövs i produkterna. Nyckelordet här är ”cadence”, ungefär rytm. Det innebär att samordna arbetet i de enskilda projekten och teamen. Den förhärskande metoden är Scrum.
Rational Unified Process (RUP)
RUP är ett ramverk för mjukvaruutveckling som man kan anpassa i det oändliga för att passa ett visst projekt.
De fyra faserna i RUP beskrivs så här:
Inception betyder start eller förberedelse. Det är i denna fas som man lägger grunden till sitt projekt, här skapas och formuleras projektets syfte och mål, man gör riskbedömningar, uppskattar vilka resurser som kommer krävas och skapar en projektplan.
Elaboration i denna ska man arbeta vidare på detaljerna. I denna identifieras problemområdet, domänen, systemets design och arkitektur samt projektplanen vidareutvecklas. Fasen innefattar att skapa en fastare grund för projektet.
Construction betyder helt enkelt tillverkning, det är i denna fas som produkten konstrueras, byggs. I denna fas utvecklas produkten iterativt till att bli ett färdigt system. Det är en utvecklingscykel av testande och kodande och det är även här acceptanskraven från mottagarsidan formuleras.
Transition är den sista fasen i RUP och den syftar till överlämning eller övergång. Det är i denna fas som produkten överlämnas till slutanvändarna. Denna fas innebär ofta att slutanvändarna upptäcker än fler krav och ytterligare utveckling sker. Inom RUP finns ett par viktiga roller som bör identifieras och/eller bemannas inom projekt, dessa är; sponsor/beställare, projektledare, utvecklare, användare, modelleringsledare och mentor. Rollen utvecklare består av bland annat programmerare, arkitekt och domänanalytiker.
ITIL
Förenklat kan man säga att ITIL är en samling konkreta tips, råd, rekommendation, processer, mallar, teorier, metoder och modeller för att guida IT-organisationer och IT-leverantörer till en säkrare, billigare, mer stabil leverans.
ITIL utgår från i huvudsak fyra huvudkoncept:
- Allt vi gör inom IT måste skapa värde för vår kund/verksamhet. Med det i fokus kommer vi göra rätt saker och hushålla med våra resurser. Många IT-organisationer lägger så mycket som 65 procent (process institute) av sin totala arbetstid på oplanerat arbete, ITIL hjälper oss att sänka den siffran markant. Med utgångspunkt i värdeskapandet tvingas vi också att utgå ifrån den faktiska kunden och bygga nära relationer och lära oss förstå vår omgivning, för att förstå vad det faktiska värdet består av.
- Tjänst. Genom att grupperar våra olika IT-lösningar i väldefinierade tjänster tydliggör vi vad vi har till vårt förfogande men också vår leveransförmåga. Genom tjänsterna kan vi också synliggöra vilka risker, kostnader, ansvar och relationer mellan komponenter vi har att hantera.
- Processer är ITILs tredje huvudkomponent. Det är genom processerna vi utför alla aktiviteter som behövs för att initiera, designa, planera, testa, rulla ut och slutligen förvalta och supportera våra IT-tjänster. Det är genom processerna vi får saker att hända helt enkelt.
- Etablera tydliga roller – illustrera vem som gör vad och vem som har vilket ansvar, exempelvis för tjänster, processer och verktyg.
Feature Driven Development (FDD)
Feature Driven Development (FDD) är en process som börjar med att man fastställer helhetsmodellen av det system man ska bygga. När detta är gjort delar man upp modellen i mindre bitar så kallade features, ”design by feature, build by feature”. Dessa implementerar man över en period av cirka två veckor. En feature är inom projektet definierad som en funktion som kunden har nytta av.
Man kan dela upp Feature Driven Development i fyra punkter:
- Develop an overall model
- Build a feature list
- Plan by feature
- Design by feature/Build by feature
Likheterna mellan FDD och XP är många. Båda processerna är designade för att snabbt kunna leverera färdiga resultat till kunden så att man snabbt skall kunna få feedback. De är också mer fokuserade på att överföra kunskap genom människor istället för att som i de stora tungviktprocesserna producera tusentals sidor dokumentation. Även när det gäller rollerna i projektet har de samma synsätt. Det vill säga att det finns ingen fast designgrupp eller någon fast implementeringsgrupp utan alla jobbar tillsammans. Detta gäller även kunderna som båda processerna vill ha med i projektet som en aktiv part i utvecklingen.
Adaptive Software Development (ASD)
Jim Highsmith har utvecklat Adaptive Software Development (ASD) efter många års arbete med tunga traditionella processer.
ASD har tre faser som arbetsprocessen genomlöper:
- Spekulation Highsmith menar att en planering är omöjligt att genomföra i ett adaptivt arbete eftersom det är omöjligt att förutse allting. Däremot kan man spekulera i vad som kan ske i det fortsatta arbetet.
- Samarbete När man arbetar i en miljö där man måste vara beredd på snabba förändringar måste projektgruppen samarbeta på ett helt nytt sätt. Projektledningens uppgift är i mindre skala att tala om för sin personal vad som ska göras, viktigare är att uppmuntra kommunikation mellan gruppmedlemmar så att de tillsammans kommer fram till vad som skall göras.
- Lärande I en traditionell processutveckling kommer själva lärandet i skymundan i och med att man bestämmer sig för en design och sedan håller sig till den. I en adaptiv utvecklingsprocess är det viktigt att man efter varje iteration tittar tillbaka på vad som gick bra eller dåligt. Sedan är det viktigt att lära sig av detta inför nästa utvecklingscykel.
Crystal
”Crystal metoden” även kallad ”Crystal clear” (kristallklart) är en så kallad ”human-powered” metod, alltså att den är driven och centrerad till och av människor. Den här modellen utgår ifrån en väldigt enkel del, nämligen att teamet ska vara och befinna sig väldigt nära varandra och man ska ha möten med varandra och avstämningar med kunden. Det här arbetssättet är även utvecklat för att direkt tolka regler och visa teamet vad man ska göra och vad man ska uppmärksamma. Crystal metoden passar bra då projektet har ett fast pris/budget. Syftet är även att man ska försöka minska ”byråkratin” i projektet och skapa utrymme för att låta teamet göra det dem är bäst på, designa, utforma, skapa eller något annat som de är intresserad av som gynnar projektet.
En annan del är att man förutom avstämningar med kunden låter kunden få vara med i arbetet och ses som en ”expert” eftersom det är de som kommer att använda produkten senare är det inte konstigt eller skadligt om denna får vara med i utvecklandet av produkten.
Crystal-familjen är färgkodad för att beteckna ”vikt” av den metod som behövs. Således skulle ett stort projekt som har konsekvenser som innebär risk för människors liv använda Crystal Sapphire eller Crystal Diamond metoder. Ett litet projekt kan använda Crystal Clear, Crystal Yellow eller Crystal Orange. Clear är till för projektgrupper som sitter i ett och samma rum, omkring sex till tio personer.
- Clear kräver av gruppen att producera teknisk dokumentation, men innehållet lämnas över åt gruppen att själv bestämma efter eget omdöme. Detta är för att hjälpa framtida utvecklare att sätta sig in i projektet. Inom Crystal talar man varmt om whiteboardens oöverträffliga egenskaper i utvecklingsarbetet. Köp in, och snåla inte med whiteboards, för man ritar sällan av vad man kommit fram till (och det är inte sällan man kommer fram till att den informationen var kritisk först långt efteråt) och då är det bra att man inte behöver sudda ut tavlan. Det kan finnas information lite här och var på tavlorna som kan vara viktig att få med i den tekniska dokumentationen.
- Efter och mellan varje release har man en workshop med projektgruppen där man satsar på att trimma in både produkten och själva utvecklingsarbetet. Man intervjuar utvecklarna och tittar på och reder ut brister i produktionskoden och arbetsmetoderna.
Den optimala jobbpausen
Att ta regelbundna pauser är viktigt. Men vad du gör under dem är lika viktigt.
Avbrott är avgörande", säger Cal Newport, författare till Deep Work: Rules for Focused Success in a Distracted World. "Om du arbetar dag efter dag och inte pausar kommer du att ”brinna upp”."
NÄR? Det viktigaste är att sätta dina pauser i kalendern. Om du inte schemalägger dem säger din hjärna: ”Jag vet att jag måste ta en paus någon gång. Varför inte nu?" förklarar Newport, som nyligen släppte The Time-Block Planner: A Daily Method for Deep Work in a Distracted World. Du har hela tiden "Varför inte nu"-konversationen i ditt huvud. Du tar pauser för att kolla nyheterna eller något annat online. Du blir hela tiden distraherad. Om du vet att du ska ta en paus en viss tid kan du fokusera på jobbet och sedan njuta mer av pausen.
VAD du gör är också viktigt", säger Newport. ”Om du tar en paus mitt på dagen bör du undvika att utsätta dig för är något som ligger i samma kontextuella område av normalt arbete.” En sak som aldrig bör betraktas som en paus? E-post! Om du tittar på din inkorg, ser många meddelanden och inte har tid att hantera dem, skapar det en kognitiv katastrof, säger Newport. "E-post är arbete", säger han. E-post är den kognitiva motsvarigheten till att ta shot whisky medan du arbetar.”
Newport säger att distansarbete för människor som inte är vana att arbeta hemifrån gör schemaläggning av pauser ännu viktigare. "När arbete sker på samma plats som livet är det svårt att veta när arbetsdagen börjar och slutar", säger han. “Var mycket försiktig med att få ut det mesta av den tid du har. Ju bättre du blir vid tidsblockeringsplanering, desto bättre har du det. ”
Källa: https://www.fastcompany.com/90582261/this-is-the-exact-type-of-break-you-should-be-taking-when-working-from-home
XP (Extreme programming)
XP baseras på fem värderingar: kommunikation, enkelhet, återkoppling, mod och respekt. Det är viktigt att ha en kund på plats så att kontinuerlig kommunikation mellan utvecklarna och kunden är möjlig. Kunden som är på plats har möjlighet att bestämma vad som ska uppfyllas av systemet (krav på systemet) och i vilken ordning dessa ska prioriteras (så att de viktigaste kraven hanteras först).
XP har ett antal så kallade ”tillämpningar” som stöttar de fem värderingarna. Det finns tolv tillämpningar i XP som stöttar de fem värderingarna:
- Planeringsspelet Funktionalitet i nästa leverans bestäms genom prioriterade verksamhetsberättelser och tekniska bedömningar.
- Små leveranser Systemet levereras i små inkrementella versioner.
- Metafor En enkel beskrivning av hur systemet ska fungera.
- Enkel design Genom att hålla koden enkel blir även designen enkel. Ta bort komplexitet från koden kontinuerligt när den upptäcks.
- Testning Tester skrivs innan koden utvecklas. Programmerare skriver tester som testar och validerar koden medan kunden skriver tester som testar och validerar verksamhetsberättelser.
- Omstrukturering av kod Ta kontinuerligt bort identiska (dubbletter) och komplexa kodbitar.
- Parprogrammering Programmerare arbetar i par vid en dator. En skriver koden medan den andre granskar koden.
- Gemensamt ägarskap Alla har rätt att ändra i all kod, skriven av dem själva eller någon annan.
- Kontinuerlig integration När en implementationsuppgift är utförd byggs systemet och integereras med den redan färdiga koden. Detta kan ske flera gånger per dag.
- 40-timmars arbetsvecka Programmerare tänker och därmed arbetar bättre utvilade. Övertid tillåts inte i två veckor i rad.
- Kund på plats Kunden arbetar med utvecklarna på heltid för att kunna svara på frågor, definiera systemet och skriva tester.
- Kodstandard Konsekvent kodstandard som alla programmerare följer.