Webinar: Teamen blev agila, men vi blev inte bättre
KOSTNADSFRITT WEBINAR – On demand
Agila, men inte bättre – del 2
Införsäljningen av att förändra sitt traditionella sätt att arbeta till att bli mer ”agila” innefattar ofta konkreta värden som ”bättre kvalitet”, ”snabbare kundvärde” och ”lyckligare medarbetare”. Efter en lång införandeprocess, som förmodligen krävt både energi och diplomati av oss, längtar vi efter att få skörda resultaten.
De agila teamen verkar fungera bättre men ändå känns inte allt bra. Vissa team verkar till och med stagnera och i värsta fall börja backa tillbaka. Ofta med kommentarer som ”de verkar inte förstå hur vi jobbar” eller ”varför ska vi lägga så mycket tid på att bli agila när inte andra gör samma sak?” De där goda resultaten och förbättringar vi såg i början börjar bli mer och mer sällsynta. Något känns avigt och mer och mer tid går till bittra debatter mellan team, ledare och beställare från verksamheten. Vi blev agila men inte bättre.
Varför?
Detta ämne diskuterade Onbirds Torbjörn Dahlström och Martin Comstedt under 45 minuter, en helt vanlig onsdagsmorgon.
Vi tittade på vanliga problembilder och typiska anledningar till dessa problem. Vi förklarade även varför detta är utmaningar ni inte vill ha, pekar på 5 varningstecken och 3 vägar framåt och ut ur problembilden.
Fyll i formuläret till höger för att kostnadsfritt se webinaret.
Talare
Torbjörn Dahlström
Partner och konsult inom Agil organisationsutveckling och förändringsledning.
Martin Comstedt
Partner och konsult inom Agil organisationsutveckling och förändringsledning.
Se övriga delar i denna webinarserie
Del 1: "Vi blev agila, men inte bättre - vad hände?"
Del 2: "Teamen blev agila men vi blev inte bättre"
Del 3: ”Vi blev agila, men vi blev inte snabbare”
Del 4: ”Agila ledare ”arbetar” bara 3 dagar/vecka”
Del 5: "Vi blev agila, men inte motiverade"
Del 6: "Vi blev agila men projekten finns kvar"
Se webinaret
Varför står vi och stampar?
På Onbird vill vi gärna dela med oss av våra erfarenheter i ämnet. Vi har inga absoluta sanningar men delar gärna med oss av de vanligaste fallgroparna vi stött på under våra år som förändringsledare och agila coacher.
Vi ser ofta att verksamheter likställer agila metoder till att enbart handla om ramverket Scrum som i sin metodiska form ”bara” behandlar delar av planning, build och commit. Man lägger vikt vid att man har korsfunktionella team och att skapa kundvärde så snabbt som möjligt, men Scrum har inga tvingande ceremonier för releaser och operations. Detta medför ofta att man har kvar operations (drift) som en egen del utanför våra agila scrum team och den interna driftavdelningen är inte anpassad för att leverera kundvärde snabbt. Agila utvecklingsteam kan vara hur effektiva som helst men om värde inte levereras till kund i samma tempo kommer det inte spela någon roll i slutändan. Ledtiderna kommer inte att bli bättre.
Vidare kan vi tydligt se att den agila transformationen har startat på IT, ofta avgränsat till utvecklingsavdelningen. Det saknas mandat och kunskap att influera andra delar av verksamheten vilket innebär att den agila transformationen stannar upp och effekterna vi hoppats på kan inte uppnås. IT som funktion har lämnats utanför verksamheten och en intern ”beställar- och leverantörssyn” dominerar hur vi interagerar med varandra. Agil magi är svår att uppnå när utvecklingsavdelningen först blir inblandade när produkter och lösningar redan är fördefinierade i en roadmap (eller projektplan).
Vill du ha en mer djuplodande genomgång i ämnet (samt fler punkter i listan över hur vi tar oss framåt) så råkar vi ha ett webinar on demand du kan titta på närhelst du får en stund över! Fyll i dina uppgifter i formuläret ovan, poppa lite popcorn och titta!
Om serien ”Vi blev agila, men…”
På Onbird vill vi gärna dela med oss av våra erfarenheter i ämnet. Vi har inga absoluta sanningar men delar gärna med oss av de vanligaste fallgroparna vi stött på under våra år som förändringsledare och agila coacher.
Vi ser ofta att verksamheter likställer agila metoder till att enbart handla om ramverket Scrum som i sin metodiska form ”bara” behandlar delar av planning, build och commit. Man lägger vikt vid att man har korsfunktionella team och att skapa kundvärde så snabbt som möjligt, men Scrum har inga tvingande ceremonier för releaser och operations. Detta medför ofta att man har kvar operations (drift) som en egen del utanför våra agila scrum team och den interna driftavdelningen är inte anpassad för att leverera kundvärde snabbt. Agila utvecklingsteam kan vara hur effektiva som helst men om värde inte levereras till kund i samma tempo kommer det inte spela någon roll i slutändan. Ledtiderna kommer inte att bli bättre.
Vidare kan vi tydligt se att den agila transformationen har startat på IT, ofta avgränsat till utvecklingsavdelningen. Det saknas mandat och kunskap att influera andra delar av verksamheten vilket innebär att den agila transformationen stannar upp och effekterna vi hoppats på kan inte uppnås. IT som funktion har lämnats utanför verksamheten och en intern ”beställar- och leverantörssyn” dominerar hur vi interagerar med varandra. Agil magi är svår att uppnå när utvecklingsavdelningen först blir inblandade när produkter och lösningar redan är fördefinierade i en roadmap (eller projektplan).
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 och produkter 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.