Produktägarskap handlar om relationer

23 09 2015

När man tänker på produktägare och produktägarskap, så hör jag ofta att man tänker på marknads- och trendanalys, arbete med användarbehov och affärsnytta, arbete i utvecklingsteam och kanske acceptanstest. Att strukturera och grooma backlogen, sätta visioner och mål, följa upp och kommunicera dessa med teamen. Skriva user stories och klarkriterier kanske.

I teorin var det nog så Scrum-skaparna tänkte.

Efter att i många år ha arbetat både med och som produktägare så har jag insett att de delarna är bara en mindre del av rollen och uppgiften.

En produktägares viktigaste uppgift är att skapa och underhålla relationer. Relationer med kunder, intressenter, slutanvändare, leverantörer och utvecklingsteam. Om du som produktägare undrar vad du ska prioritera idag, så ställ frågan – vem är viktigast att jag träffar idag? (alternativt ringer upp eller kontaktar på annat sätt). För att höra hur de mår, hur det går, ge information om läget eller bara småprat.

Den andra viktigaste uppgiften är att kunna berätta en historia. Som produktägare hinner du sällan med att genomföra allt, leverera allt enligt plan eller förväntan. Men om du kan berätta din historia så är det mindre viktigt vad som faktiskt levererats. Mer viktigt är berättelsen om planen framåt, även när den är ytterst oklar, och om läget i teamet, även när det är kaos. En berättelse kan ha många hål, men det är produktägarens vardag. Du kommer inte ha koll på allt, alla siffror, alla detaljer jämnt. Men kan du berätta din historia på ett trovärdigt sätt så sköter du jobbet utmärkt.

Det kan räcka med en snygg powerpoint-presentation som lyfter fram små men ändå viktiga delleveranser så att det ser proffsigt ut. Eller att du använder ett språk som omgivningen gillar. Eller att du bara valt en bild som illustrerar något som är viktigt för mottagaren.

Framgång som produktägare handlar om att gå och ta den där after worken trots att du inte alls har tid eller har en enorm förkylning. Att du går och tränar ihop med någon chef som du kanske inte alls skulle umgås med annars. Att du åker till andra sidan stan för att luncha med den där leverantören då och då.

Detta leder till framgång för produktägare.

Backlog, user stories, produktvision, demos och allt annat metodiskt kan du delegera eller avsätta en dag i veckan för. Trots att det kanske var det du trodde att jobbet skulle handla om.

Stämmer det med dina erfarenheter?





Produktägaren – domänexpert eller processguru?

3 03 2015

Efter ett samtal häromdagen om produktägarrollen på en organisation så började jag fundera igen över detta.
Vad är det för slags produktägare man ska tillsätta, om man nu som beställare, chef, processägare eller något annat vill ha en sådan roll i sin utvecklingsorganisation?

Är det den person som kan bäst om domänen man verkar i – försäkringar, marknadsföring, administration, kundservice etc? (kan ibland vara superanvändare).
Eller är det någon som är proffs på utvecklingsmetoder, systemutveckling, processer, användbarhet etc i allmänhet? Någon som levt och verkat i utvecklingsmiljöer.
Eller är det affärsägaren – den som faktiskt ansvarar för att affären eller verksamhetsnyttan går hem? Ofta en linjechef av något slag.

Jag har sett olika varianter på detta och naturligtvis finns inget rätt svar. Min slutsats är att oavsett vilken av dem man väljer så:

1. kommer den personen behöva ordentilgt avsatt TID – dvs bli av med andra uppgifter.

2. personen kommer behöva lära sig ordentligt något utanför hens normala zon. Är man domänexpert/superanvändare behöver man t.ex lära sig utvecklingsmetodik på riktigt. Är man process-proffs behöver man lära sig domänen och marknad. Är man affärsägare behöver man lära sig UX-metoder etc. Tid behöver ägnas åt detta och ibland investering i utbildning och liknande.

3. personen kommer behöva stöd av någon av de andra rollerna för att lyckas i sin produktägarroll. Processproffset kommer behöva enkel tillgång till superanvändare och domänexperter som kan vara med i designdiskussioner och delta i acceptanstest, dvs kunna ägna tid åt utvecklingen. Affärsägaren kommer behöva ett processproffs som kan fokusera på behov & kravställning, domänexperten kommer behöva en tillgänglig affärsägare för att kunna fatta affärsmässiga beslut etc.

4. personen behöver ett tydligt mandat – mer eller mindre, bara det är tydligt.

För den som sett en produktägarorganisation riggad på detta sätt, har troligen också sett de resultat man vill åstadkomma med agila metoder – dvs bättre time to market & bättre värde till kund

Tyvärr behandlas produktägarrollen i de flesta organisationer slarvigt. Man tillsätter någon som känns rätt, utan att ge den det stöd eller framför allt den TID som krävs för att få full nytta av rollen. Sedan säger man att man jobbar ”agilt” fast utvecklingsteamen och leverantörerna fortfarande inte har någon riktigt närvarande att kommunicera med utan kör sitt race som vanligt. Alternativt en alltför teknisk produktägare som inte uppmuntras till att kunna och faktiskt få ta ett större affärsansvar.

Om den ideale produktägaren, t.ex en affärsägare, helt enkelt inte KAN flyttas från sina ordinarie uppgifter, kanske är det bättre att hon medverkar som aktivt affärsstöd istället till någon annan utsedd produktägare – t.ex en superanvändare eller processexpert?

När jag sett produktägarrollen fungera så har det inte spelat någon roll vilken av ovanstående som varit produktägare, utan skillnaden har bestått i NÄRVARO, TID samt ordentlig backup på det område hen inte är expert i.

I den gamla metoden XP – Extreme Programming, föreslog man ration 1-1 av kodnära utvecklare och andra roller i teamet  t.ex som nedan:

Skärmavbild 2015-03-03 kl. 12.04.38

Process-stödet (t.ex en Scrum-master, teamcoach och liknande) finns inte i XP om jag minns rätt, men ofta behövs också en sådan roll något beroende på teamets storlek, uppgift och mognad.

Testaren har jag lagt till som en egen roll, beroende på teamets uppdrag och kvalitetsmognad behövs också en sådan. Testaren har jag också sett vara ett ovärdeligt stöd till produktägaren i fråga om både kravställning, acceptans, användningstest mm.

Detta är motsvarande heltidare. Dvs om man har en UX på 50% så borde också en av kodnära utvecklarna vara på 50%… för att hålla ration. Om du vill ”fördela” testaren eller UX:aren på 2 team på 50% vardera, har du också tänkt fördela en av utvecklarna på två olika team? Det hänger också på reell närvaro (fysiskt eller virtuellt) för att fördelningen ska fungera. Dvs en testare som aldrig är delaktig i utvecklingsteamet på riktigt, gör antagligen inte så stor nytta som hon skulle kunna.

Jag vill helt enkelt slå ett slag för XP igen och att alla som beslutar om produktägarskap tar sig en funderare på vad man vill uppnå. Räcker det med att någon får hatten Produktägare för att öka nytta, kvalitet och time to market?  Eller krävs helt enkelt en ny och mer seriös approach till det utvecklingsarbete som är av mindre teknisk art för att våra nya metoder ska löna sig?

Heja alla produktägare därute som gör sitt bästa för att få någonting gjort på sin lilla tid och kämpar för att hålla takten i analys, kommunikation, visionerande, utredningar, planering och uppföljning av utvecklingsarbete, acceptanstest, marknadsresearch, kundstudier….





Vad är krav?

26 01 2015

Häromdagen hörde jag en presentation av en person som jobbar på ett spelföretag. Han sa att de inte arbetar med krav alls. Vad jag hörde var att de inte har den gamla formen av kravanalytiker som sitter och samlar och specificerar allt de kommit fram till, för att sen föda utvecklare med dessa specifikationer. I stället låter de spelutvecklarna testa och experimentera fram olika varianter tills något känns bra. De har också en relativt stor grupp hängivna spelare (användare) som får pröva spelen tills de identifierar vilka som faktiskt är bra och roliga och då eventuellt släpper de spelen. Han sa att endast en bråkdel av spelen faktiskt når ut i produktion.

De arbetar också mycket med test, förutom användningstesten så automatiserar de test av sådant som bara måste fungera gång på gång, typ login och annat. Dessutom har de fasta regler att förhålla sig till, t.ex från API:er (gränssnitt) med tjänster som de använder, t.ex Facebook, Google mfl. Och det är ju bara att följa de gränssnittsspecarna.

I mitt huvud tänkte jag, men! Ni jobbar ju visst med krav! I alla fall enligt min personliga tolkning av vad krav faktiskt är. Det är bara så att ni jobbar mycket mer modernt och snabbt med kravarbete än vad många andra gör.

Det ni gör när ni experimenterar och släpper lös den kreativa sidan hos utvecklarna, testar med spelare och automatiserar gränssnitt och studerar och programmerar utifrån API-specar är ju också krav!

Fast ”Krav” är ett olyckligt ord. Just här använder jag ”krav” som ett samlingsord för alla tekniker, metoder och arbetsuppgifter som leder till förståelse av vad användarna faktiskt behöver och beslut om vad som ska ut i drift eller inte.

”Krav” för mig kan uttryckas muntligt, skriftligt, som en teckning, en modell, en skiss, en dialog, som ett test, som programkod, en första version av mjukvara. Någon sa att den enda sanna kravspecen är programkoden, och det håller jag med om, även om den kanske inte är så läsbar för alla. Programkoden talar faktiskt om för maskinen vad den ska utföra. Det mesta som inte är programkod är tankar och idéer som uttrycks på mer eller mindre luddiga sätt.

”Krav” är analysarbete. Att göra en prototyp av ett spel, eller en tjänst och att låta testa den samt studera och dra slutsatser av resultatet och förbättra eller förkasta är också analysarbete.

Problemet är att ”Krav” är ett så dåligt ord eftersom det associerar direkt till långa kravspecar.

”Krav” kan i min värld vara t.ex:

– En backlog
– Ett experiment eller en prototyp
– En skiss på en näsduk eller whiteboard
– En begrepps/informationsmodell eller domänmodell (vilket ord man nu föredrar..)
– En användarberättelse (user story eller en hel text om kundens resa genom systemen)
– Ett testscenario
– Feedback från någon
– En vision förmedlad av någon (användare, utvecklare, vd, medarbetare, marknadschef, säljare, kundtjänst…)
– Ett kommunicerat mål
– Regler definierade av någon

Jag vill dumpa ordet ”krav” och det är antagligen det vi måste göra för att komma loss från de långa kravspecarnas och användningsfallens bojor. Fenomenet i sig: att analysera, förstå, testa, undersöka, följa upp, visionera & designa försvinner dock inte för att vi dumpar ordet ”Krav”. Det är fortfarande en nödvändighet för att få något värdefullt ut av den mjukvara vi producerar.

Att hej vilt koda utan mål, mening, vision eller feedback vore hrm.. intressant.. att se resultatet av. Jag tror att den här killen från spelföretaget ville säga att de kodade hej vilt och ”kravlöst”, men faktum var att de verkar väldigt strukturerade i sin metod att experimentera och samla in feedback, förstå spelarna och jobba med visioner.

Kravspecifikationen då? Har den spelat ut sin roll?
Ordet i sig, ”kravspecifikation”, måste vi nog också göra oss av med för att bli av med dokument som ingen varken läser eller förstår, förutom den som skrev den.

Specifikationer och dokumentation av olika slag däremot kommer vi fortsätta behöva. I olika grad beroende på hur många beroenden vi har och hur stor vår affär eller verksamhet är. Att publicera ett API/webservice för någon internt eller externt att använda utan någon form av dokumentation blir… svårt för de som ska använda den. Att förvänta sig att mjukvara hos myndigheter, banker eller andra regulerade verksamheter ska anpassa sig till lagstiftning utan någon dokumentation av lagarna blir också.. svårt. Det är också specar.

Att gång på gång undersöka och muntligt sprida affärs- och verksamhetsregler i en stor organisation blir också… svårt. Lyckas man dokumentera dessa regler på ett läsbart och hållbart sätt så kanske man inte behöver så många fler specifikationer.

Problemet med specifikationer är inte att de finns, utan att de är för omfattande, att de snabbt blir inaktuella och beskriver design och andra delar som konstant förändras och att de är svårtillgängliga.

Utmaningen är att specificera tillräckligt lite.

I spelföretagets fall så höll de sina specifikationer i form av automatiserade testfall. Genom att titta i de specarna så förstår man hur spelen fungerar.

Jag har sett verksamheter där man faktiskt har en lätt tillgänglig källa över domänmodellen (informationsmodellen) som uppdateras med exakt vilka koder som betyder vad och vilka regler som gäller.

Det går.

Men kanske går det inte att prata om ”krav” och ”specifikationer” längre. Det för med sig en ryggsäck som vi inte vill ha.

Min ambition är att jobba med både krav och specifikationer utan att prata om dem.





We want parallell (agile) & predefined (waterfall) requirements at the same time.

19 01 2015

I believe we are many in the same situation. At the same time as we are developing the software we define the requirements in different formats – verbally, written or as drawings & models. Also we define our requirements in parallell with other projects who are dependent on our project or vice versa, and who already have started development.

This is basically something good. Previously many did the specifications up front – sometimes for months or years (!), then handed over to development who tried to understand and implement what was written. This led to many errors so the ”requirements phase” has basically disappeared completely.

I have many good experiences from working with requirements in parallell with development. It’s pretty messy and frustrating for everyone, but in the end, the result seems to get a bit better off.

The problem arise when the organization do want to work like this, and at the same time expects the product owners, business analysts, solution architechts or whoever works with requirements to have ALL the answers exactly specified completely for every conversation.

”If you can’t give us a complete specification this week on feature x then we cannot commit to give you any delivery for the next 8 months, and possibly not at all”

-”But, in order for us to give you a good spec we need to see your first version of the software so we know where the gaps are, and can fill in the blanks”

I have seen this many times. You don’t want a 6 months requirements specification phase, because you know this will generate too many errors. Still you don’t want to accept that by removing this you DON’T have a complete specification to offer, you DON’T have the answers to new or modified business rules and you actually HAVE to have a development process that deals with this.  (There are many available..)

It seems so hard for many organizations to accept the fact that there is no specification and to adjust the processes to fit with the new reality of requirements discovery during development.

Those organizations who learns how to facilitate the new way of working by building in these facts into agreements with suppliers or dependent organizatons will succeed.

And those who have realized you need people who spend more or less 100% of their time with requirements investigation, disvovery, design in the teams & projects will also have a better chance to succeed. In mature teams, with time, the ”agile” requirement process will settle but it needs attention, competence and focus.

We’re in the middle of a change and too many are trying to work both in the old and the new way with requirements. This creates only more mess. Let’s accept the new form of working with requirements in parallell with development, and adjust our organizations, agreements and contracts to this.





Examples of testable requirements

1 04 2014

In the last edition of  @TestingCircus I was yammering around testable requirements and the need for requirements people to get help from all you testers out there.  http://www.testingcircus.com/examples-of-testable-requirements/

Testing Circus is btw a great magazine! Even go back to old editions is well worth the time.





Happy ending 2013, fuck Agile and be Good

26 12 2013

Sorry Agile about the title. I can’t figure out another way to say it. Time to ditch the concept of Agile and talk about what matters. All we want to do is Good. In projects, organizations, development, business.

I was upset by everyone, and I mean everyone (at least in the IT domain), putting ”Agile” in front of every word related to their work, to make some sort of statement. ”We need to be more agile”, ”you have to make this team agile”, ”Our organization should be more agile”, ”In agile user experience we do this”, ”to have an agile release process you need to..”, ”our marketing department is agile”..  Seriously, what do you mean really?

A friend of mine, @froderik,  suggested we just replace ”agile” with ”good” and it will become more clear.

Try that.

The Agile manifesto did something awesome more than 10 years ago, putting into words something that needed to be put into words. To put attention to something that was not good in the IT business, and could become better.

Now, the Agile manifesto seems to has served it’s purpose and it’s not enough as a guide anymore.  For instance there’s nothing in the Manifesto that says we actually should deliver stuff (product and services). 🙂 You’ll see it if you read it as another friend @NiclasReimertz reminded me of.  It’s fine. It’s just time to take a breath and take the next step on the ladder.

Nowadays, the word Agile is  used in every situation to explain something bad, or good, or middle. It doesn’t mean anything any longer. How many times have you lately heard the word ”agile” used in any kind of setting?

The Agile communities did change my professional world. With the help of Agile people I learned new methods and structures to do better team leadership & development processes and somewhat better services and products.  For these communities, Agile is now more of a brand name. People know who they are by the name. No need to change. But in all other settings Agile is obsolete.

Now, to do seriously good services and products for my customers, there are so many things that need to be considered, known and explored. Business, people, process, user experience, quality, domain, context, learning. Knowledge from the history and science of communication, psychology, engineering, learning, marketing, technology  as well as crazyness, invention, collaboration over great distances, with highly integrated and complicated or complex systems, Agile just don’t have the chance to give an answer any more. Now I just want to do Good.

I get confused and restless when hearing Agile. What do you really really want? I ask.
You want a faster release cadency?
A functioning team?
An innovative product?
A stable environment?
Happy users?
Big sales?

Tell me what you want, and I’ll try to find a Good way to do it for you.

Bye Agile, enter Good.





What direction do you need?

8 07 2013

Some friends with a little summer house in the beatiful island of Utö, Stockholm archipelago, always invite friends to visit, to stay in one of the two small rooms or in tents. Now they plan to fix their shed down the water to make it liveable.

So they have the idea to bring all friends for a weekend to restore & fix it together with them. Great idea. But ”oh my” my first thought was. A lousy carpenter I am (maybe I don’t know haven’t tried much), anyway with no experience, I can see this crowd of friends standing there with no plan and some tools and starting to discuss where to start, who will do what.  It makes me sick thinking of it. ”I’m more than happy to help out, but please please make sure there is someone gaffer from the start who tells me exactly what to do, and get us going.

This made me think about projects in general, and software projects. A group of people coming together to fix something will for sure gonna be a drain, it there is no direction at all. They’re gonna talk for days. About what and how.

This can work I believe, if you’re really really explicit about that it’s up to the group to decide – everything – and they have easy access to the money – with a sharp deadline and with very direct, personal and visible reward and outcome from the project.

But if it’s not and you just want the shed liveable in the way you want it, and the outcome for the crowd is just ”a pizza and some beers, and maybe access a night or two in the shed during the summer”,  this is not the way to do it.

When knowing nothing about how to build a roof, to do up the windows, fix the floors, install a small kitchen, we for sure need a lot of detailed direction. ”Paint this border of the window, first clean them, with this tool” etc. This will make me productive.

If there are some people in the crowd who knows some  more, they will only need to know ”you take care of the windows, here’s the material, and some guidelines, ok!” to get anything going. Anything more detailed will get them irritated and much less productive.

Someone might be a builder, or have a lot experience from hobby projects, and all she/he will need to know is some constraints ”fix the house” – it can’t be bigger than x m/2, and have to be red, and must include some sort of kitchen area. And this guy will make it. If you give her too much constraints she will just give up ”what’d’you need me for if you know everything yourself!?”

Depending on experience, different sort of direction is needed. Please don’t expect your friends, being there over the weekend, to ”sort it out themselves”. They won’t. They will spend hours talking, discussing, who does what, what should be done, how it should look. Ending up by the rocks having a swim pretty soon..  or at the porch having a beer ”to think”.

Please assign us some roles. ”You’re in charge of the windows” is very helpful even with no experience. Knowing I’d be in charge for window, I’d make sure to gather some people around to figure out what to do. But HOW to do it? With no experience, please give me someone who can give us directions. ”You should start with..”

In software teams, compared with a bunch of friends fixing a shed, we have most often at least some experience or education. No-one is totally rookie. Therefore we start a bit ahead. Still we can’t put together a new group of mixed people expecting a great result without any sort of direction.

Is the product owner’s direction on WHAT to do, enough for software teams?

And the way many project managers, especially less experienced ones, ”direct” a software team, is that really effective? To tell more or less senior developers & team members exactly what to do and how to do it, is that really working?? Or to say ”we’re agile” and with that leave all direction?

Is the HOW so unique and changing so there is no need for any sort of technical instructions? ”You should start with…” Ever?

What level of direction do YOU want and need for yourself? To be able to fix your software shed with pride?

And have you told anyone that?
For example your project manager, CTO, team members or other managers?

Please tell us at least with a comment on this blog, if not anywhere else. 🙂