In general, the product owner’s job is to specify what to build, not how to build it. But, there may be times when it is appropriate for a product owner to specify some architectural decisions.
Många chefer och traditionella projektledare är ofta skeptiska till scrum och agilt för att de känner att de förlorar kontrollen och till viss del stämmer det eftersom man inte detaljplannerar allt i förväg för att undvika onödigt arbete och vara flexibla för förändringar.
Det beror även på att scrum och agilt förespråkar att de som kan ett specifikt område bäst också är de som fattar besluten där som t.ex. scrum teamet angående hur de ska jobba och vem som gör vad.
Scrum team ska vara självorganiserande och produktägaren ska tala om vad som ska göras och teamet bestämma hur det ska göras vilket många tror innebär att produktägaren och kunden inte får komma med några direktiv alls gällande tekniska val o.s.v och att de inte har någon kontroll alls.
Men det har det fast de ska undvika att överutnyttja den kontrollen och bara göra det i undantagsfall när det är nödvändigt och berättigat.
Produktägaren och de intressenter denne representerar behöver inte alltid nöja sig med att bara komma med user stories till teamet som dessa sedan får implementera med den teknologi och i den plattform dessa vill, utan har rätt att ha med specifikationer angående teknik och arkitektur i sina krav om de anser det nödvändigt och berättigat och har kompetensen att avgöra det.
En produktägare och dens intressenter eller ledningen för en verksamhet behöver inte tillfråga teamet om saken innan ett sådant strategiskt övergripande beslut fattas, och kanske undviker att göra det initialt p.g.a det motstånd bevarandet av status queue ofta utgör vid större förändringar.
De kan därför ha använt sig av externa experter för underlaget till beslutet som är minst lika kompetenta som någon inom organisationen eller till och med mer.
Ibland kan ekonomiska eller strategiska skäl finnas till det som gör det till ett bra beslut för verksamheten på lång sikt även om det innebär umbäranden och kostnader på kort sikt.
Det är produktägaren som fångar in och specificerar kraven och kraven kan även vara specifika kring teknik och arkitekturval i undantagsfall, och teamet måste hålla sig inom de ramar produktägaren och de intressenter denne representerar ger dem om de inte ändrar sig efter att de gett sina synpunkter.
Det rekommenderas att kraven förfinas i samråd med utvecklingsteamet i sk. backlog grooming möten för att utnyttja deras tekniska expertis så kraven blir både förstådda och rätt, men det blir då i ett senare skede och gäller user stories som då ska implementeras i den valda tekonologin och plattformen.
Teamet förutsätts även fatta ansvarsfulla beslut och göra det som är bäst för kunden eller verksamheten, gör inte teamet det har produktägaren självklart rätt att ingripa eftersom dennes intressenter/arbetsgivaren betalar kalaset.
Men som artikeln säger ska inte produktägare och chefer fatta sådana här beslut över huvudet på temet för lättvindigt utan då ska de ha kompetensen och goda skäl att göra det också, och helst göra det i samråd med teamet.
Låt oss som exempel säga att ledningen för en verksamhet beslutat att de ska byta teknologi och plattform från t.ex. Java till C#/.Net Core/Azure för att de gör bedömningen att det är det långsiktigt bästa för verksamheten och produktägaren får det som krav från dem för ett projekt.
Det kommer självklart innebära vissa umbäranden och förändringar för medlemmarna i utvecklingsteamet och vissa kommer säkert protestera, och det är inte säkert att det i just det projektet ens är rimligt att göra det och då måste scrum teamet flagga för det, men mer kan de inte göra.
Är det däremot helt omöjligt för scrum teamet att uppfylla kravet i det projektet så måste scrum teamet med objektiva fakta övertyga ledningen/produktägaren om saken, för säger de bara nej det går inte eller nej vi vill inte så kommer produktägaren/ledningen bara anse de är motsträviga och förändringsobenägna.
Låt oss säga att ledningen i det läget däremot är beredd att ta kostnaden övergången innebär och ge scrum teamet den tid och de möjligheter de behöver för att lära sig den nya teknologin och plattformen på ett hållbart och kontrollerat sätt och, accepterar att projektet då kommer ta dubbelt så lång tid eller bli dubbelt så dyrt.
Då tolkar jag det Mike Cohn som är en av världens största auktoriteter på scrum säger i artikeln som att scrum teamet i ett sånt läge har som uppgift att hjälpa till att genomföra beslutet på bästa sätt oavsett vad deras personliga känslor kring det är.
Däremot måste ledningen/produkägaren i ett sånt läge disskutera hur övergången till den nya teknologin och plattformen ska gå till så det sker på ett kontrollerat och hållbart sätt som ger scrum teamet rimliga förutsättningar att hjälpa till med dess genomförande.
Det kommer behövas utbildning (helst professionella kurser) och pilotprojekt som ska vara små i början för att i takt med att teamets kompetens inom området växer blir större, tills alla projekt sker i den nya teknologin och plattformen och genomförandet är klart, så man får ta sådana byten av teknologi och plattform stegvis.
Robert Forsström's Blogg 