Agila metoder blir allt mer normen för utveckling. Typfallet är när ett team av konsulter får i uppdrag att bygga ett nytt system eller en ny tjänst åt en extern kund. Ett annat exempel när ett av många team i en produktorganisation sätter i gång med att bygga en väl avgränsad mjukvara som ska bli en del av en större produkt.

I sådana fall är det lätt att anamma agila metoder som Scrum. Teamet i fråga har en väl avgränsad uppgift och kan styra sitt eget arbete i hög utsträckning.

Läs också: 11 konkreta tips för att upptäcka intrång i dina system

Men även utvecklingsteam som ägnar sig åt vidareutveckling, systemförvaltning och supportuppdrag försöker arbeta agilt. Sådana team finns ofta internt på företag och myndigheter, och det utmärkande för dem är att de ofta har flera interna uppdragsgivare, eller produktägare. Det innebär problem.

agil utveckling


Eftersom de olika produktägarna har olika behov och alla med all sannolikhet anser sig vara i störst behov av att bli prioriterade blir det svårt, eller omöjligt, för utvecklingsteamet att planera iterationer, eller sprintar som de kallas i Scrum. Att arbeta i iterationer är ofta en grundpelare i agila projekt.

Om teamet ändå lyckas planera arbetet i iterationer så innebär flera parallella uppdrag att mycket energi går åt till att kontinuerligt sätta sig in i nya tekniska lösningar för utvecklare som byter mellan arbetsuppgifter för olika produktägare. På engelska används begreppet ”context switching” ibland för att beskriva att en person byter fokus för sitt arbete, och det är allmänt ansett att vara en produktivitetsdödare för utvecklare.

Läs också: Utvecklaråret 2016 bjuder på (minst) fyra stora utmaningar

– Det är ganska vanligt att agila team tvingas arbeta parallellt med uppgifter för olika produktägare. Det blir problematiskt om man har mer än en uppdragsgivare eller produkt att ta hand om, säger Niclas Nilsson, konsult och vd på Fooheads.

Hur löser man det här problemet?

– En bra lösning är att skapa en produktägargrupp i vilken produktägarna gemensamt kommer överens om vilka arbetsuppgifter från varje produkt som ska prioriteras i nästa iteration. Det är sällan bra att utvecklingsteamet tar sådana beslut, säger Niclas Nilsson.

Om det handlar om att arbeta agilt i team med supportansvar föreslår han dessutom att se utse en supportansvarig i teamet och att övriga teammedlemmar hjälper till om det uppstår akuta behov eller om de har tid över.

– Man bör rotera supportansvaret i teamet. Om den som har supporten kör fast, får den personen be en kollega om hjälp. Med det angreppssättet får den som har supporten bredare kunskap om de system teamet jobbar med och övriga teammedlemmar kan ha fullt fokus på det planerade arbetet.

På så vis går det att minimera bytena av arbetsuppgifter, med högre produktivitet som följd.

Läs också: Bra appar kräver för mycket jobb.