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….

Annonser




Word of the week: Sustainable

11 06 2014

I was at an organization where the top management changed more or less every year.
At another well reputed organization where some of my friends used to work and deliver good stuff, BAAM, top management changed or it got bought or something and then it changed from a team-oriented organization to a very bureaucratic top-down way of work.

A third one, smaller, same thing happen and within a few months the crew was gone.

At a forth one..  I can give you thousands of stories of companies and organizations who seriously changed in very short time. If these organizations are still successful today, more successful or less successful I don’t know.

At one organization, an academy, not much changed at all, bits and pieces now and then and sometimes a small change could take 250 years. Is this academy successful? 

What are you’re criterias?

The academy keeps, as far as I know, ”delivering” awesome bright students.

The ”team-oriented” to ”top-down bureaucratic” organization I still believe have profit and a loyal customer base.

Some organizations die, some of them turn into something else, better or worse – who is the one to judge? The market?

The market is not always right. Just think about all those seriously successful industries.. which get so much profit, to the cost of humanitary and environmental disasters. Are they successful? They keep selling.

Was the .com era a failure? Oh NOOO way if you ask me! I too was part of ”portal site projects” stopped before launch ‘cause of the crack in the bubble. But .com was successful, don’t you agree?

And for all those companies who might have got sucked in and died within HP or whatever huge enterprise, how long would they have succeeded, how long would their technology have stood up for the seriously high pace of their competitors with much cooler stuff.

What makes a sustainable company? How long will HP be around? SAP? H&M? Twitter..? Myspace?

I think Google will be around for a while. As HP. Will Apple?

But all those ”we have such a cool map/search product, it can draw you a map very easy”.. well they disappeared or live a tiny existance today. 

The owners, the entrepreneurs, they keep going on most of them even after something happened to their baby. Taking what they learned and doing something new, wiser from the previous experience and possible with a contribution to technology development that get injected in someones project somewhere. Or they retire on that sought after palm beach.

What is sustainable? 

Kids are.

 

 

 

 





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. 🙂





Agile Quality and capoeira

3 12 2012

While not being very productive at the moment on this blog, I have got some thoughts down about Agile Quality at the company blog. What is Agile Quality? And what do you think it is? I’d love to hear!

http://blog.smartbear.com/software-quality/bid/242524/Understanding-the-Term-Agile-Quality-Through-Acrobatics

 

 





Att vara projektledare

27 08 2012

Jag fick idag en fråga ”kan du berätta lite vad du gjort som projektledare?” av en person som fått ett erbjudande att prova-på att byta roll.

Jag fick tänka till lite, vad är det egentligen jag gjort i projektledar- och projektledarliknande roller (som t.ex produktägare, scrummaster) under de ca 10 år som jag verkat i rollen.

Jag måste vara ärlig och svarade så här:

I korthet har det mesta jobbet som projektledare handlat om det sociala – att bli kompis med alla – och då menar jag alla, inklusive den där jobbiga otrevliga typen som jag kanske inte alls alltid haft lust att bli kompis med.

Och dessutom få dessa alla att bli kompis med varandra. Som en jäkla kamratstödjare för vuxna helt enkelt. 😉

Andra halvan har handlat om att om att övertyga ledningsgrupper och chefer om att tro på vårt projekt och ge oss de medel (miljoner ibland, lokaler, utrustning etc) till just vårt projekt som vi behöver. Som en jäkla politiker och försäljare helt enkelt. 😉

Och det värsta är att det är sant.

Planering och organisation är typ 1% av jobbet som projektledare.

Vilket när man läser kursprogram och annat kan låta som att det är de 1%-en som det handlar om att vara projektledare.

Vi pratade om detta och jag kom på att ingen talade om detta för mig när jag gav mig in på banan.

Jag kunde också lägga till att, jo som projektledare är man den som får ta smällarna och all skit när saker går dåligt, och när det går bra är det teamet som får beröm. Det är du som står där när det stormar, det är du som får vara försvararsadvokaten när det är svårt och det är dig de hotar att halshugga när det krisar.

”Låter inte så lockande” säger hon.

Om någon sagt detta för 10 år sedan, hade jag ändå tackat ja till det erbjudande jag då fick?

Jag vet inte.

Det tog mig 5 år att börja tycka det var roligt på riktigt att vara projektledare – eller då blev jag ScrumMaster – kanske hade något samband? Eller var det bara så att det var då jag började få tillräcklig erfarenhet för att börja bli bekväm med rollen?

Det tog mig ytterligare 5 år att ha tagit mig igenom strider, stått i blåsten, blivit hotad, kramad, peppad och stressad innan jag började förstå vad teamledarrollen egentligen handlar om. Jag påstår inte att jag bemästrar den, mycket är kvar att lära. Numera är det väldigt roligt och spännande att gå till jobbet och faca de där herrarna i höga hattar som har miljonerna, eller se sitt team växa och nå framgångar.

Det har tagit tid, och jag vet inte om någon annan projektledare skulle säga annorlunda?

Jag har sett så många pressade, stressade, överarbetade, ledsna och oförstådda projektledare runt om.

Samtidigt verkar vi vara ett ordentligt gäng som bara inte kan hålla oss ifrån den här organisation/metod/team/coachande rollen, som bara måste se om det går att komma i mål den här gången och hur roligt man faktiskt kan ha på vägen. Att få möta team efter team av fantastiska människor som älskar att utveckla system, produkter och tjänster i någon form.

Jag skulle inte vilja vara utan det.

Skulle du?





Tips till konsultköpare

18 08 2012

Samma dag jag bestämde mig för att lämna konsulttillvaron ett tag så fick jag några nya insikter, kanske har det med perspektivet att göra. Så snart du kommer utanför det snurrande hjulet är det lättare att observera vad som händer i hjulet.

Något som för mig nu framstår väldigt tydligt är hur extremt mycket (arbets)tid som läggs i vårt IT-samhälle på rekrytering, eller snarare inköp, av tillfälliga konsulter. Både av konsultköpare (ofta verksamhets- eller IT-chefer), konsulterna själva (ofta högavlönade kunskapsarbetare) och konsultsäljare (ofta mycket kompetenta och högavlönade kunskapsarbetare).

Konsulting är den nya anställningsformen. Vad jag ser på svenska IT-relaterade avdelningar är att det inte är ovanligt med hälften anställda, hälften konsulter. Egentligen är det bra, en flexibel arbetskraft som kan röra på sig snabbt när det behövs.

Det som INTE är bra enligt min uppfattning är den enorma mängd tid som läggs på avancerade inköpsprocesser av ett stort antal människor för att ofta inte köpa alls, eller efter en lång och tidskrävande köpprocess, göra ett köp för mycket kort tid t.ex 3 månader.

Jag uppskattar mina tidigare kunder och potentiella kunder, de har varit ambitiösa och ärligt intresserade personer, som gör ett bra jobb. Det jag kritiserar nu är systemet för hur svenska organisationer ofta upphandlar konsulter. Av gammal vana, tradition eller bara en viss brist på analys av processen.

Det är inte sällan jag varit med om 3 månaders inköpsprocedur för ett 3 månaders konsultuppdrag. Samtal, intervjuer, mail, telefonkonferenser, cv-skrivande, prov-seminarier, uppföljning, intervjuer och lunchande med ännu fler (annars väldigt upptagna) chefer.

När jag slog ihop det totala antalet arbetstimmar som lagts ner av ett företag för mitt eventuella 3-6 månadersuppdrag, av ett 10-tal chefer + min egen och säljarens tid, fick jag ihop det till minst 40 timmar, en arbetsvecka av högkvalificerad arbetskraft.

Tänk hur många samtidiga köpprocesser som pågår just nu, även om det bara vore 10 samtidigt = 10*40 = 400 arbetstimmar som tas från något annat – mer värdeskapande arbete i våra organisationer?

Är det värt det?  

När beställaren efter några veckor kommit fram till att ”jo, det verkar bra vi kör på detta” och hörde av sig till säljaren för att göra upp, hade konsulten naturligtvis hunnit tacka ja till ett annat uppdrag. Och beställaren fick börja om processen med den 3:e potentiella konsulten. Hela köpprocessen var vid detta tillfälle uppe i ca 4 månaders kalendertid, eftersom en tidigare tillfrågad konsult också hunnit tacka ja till något annat medan beställaren konfererade.  Innan de hittat nästa potentiella konsult har kalendertiden överstigit tiden för uppdraget.

Är detta klokt??

Och jag har sett samma sak, gång på gång på gång.

En annan lika vanlig variant är:

Beställaren kontaktar oss (konsultföretaget) av personliga skäl, känner någon som rekommenderat någon etc. Vi åker dit med den rekommenderade personen, för en både lång resa och lång intervju där konsulten presenteras för olika personer, introduceras till beställarens organisation och utmaningar, en dialog startar och fortsätter på mail och telefon efter intervjun.

I detta fall är beställaren ganska snabb på att bestämma sig för att ”jo, det här verkar bra, vi vill gärna jobba med dig.” ”Så nu börjar vår budgetprocess. Vi hör av oss när den är klar”.  !!  Det fanns inte ens avsatt medel för att göra ett inköp!!  När budgetprocessen sedemera är klar och det verkar finnas ett ok på finansiering, ca 2 månader senare, är naturligtvis konsulten ute på annat uppdrag och kan inte tacka ja. Så beställaren, konsultköparen, får börja om köpprocessen. Denna gång förhoppningsvis med budgeten klar.

I detta fall, när jag lägger ihop timmarna, är vi ca 5 inblandade personer i köpprocessen, hos beställaren och hos leverantören. Högkvalificerade kunskapsarbetare som tillsammans lagt minst 30 arbetstimmar på en inköpsrutin som inte ens kunde leda till något, eftersom budgeten inte var säkrad.

Är det värt det?

Vad tycker du som konsultköpare? Kanske är det någon viktig del jag missat, som jag inte förstår.

Jag tror att hela denna procedur handlar om att köparen så gärna vill göra rätt. Det ÄR mycket pengar för de flesta att köpa en kosult för kanske 1000 kr/tim och uppåt. Därför vill köparen göra allt som står i dennes makt för att säkerställa att det är rätt person, rätt kompetens som kommer in. Så köparen ser till att skaffa förankring, genom att flera viktiga personer involveras, att det avsätts ordentligt med tid för intervjuer, presentationer och uppföljning. Kanske ett prov-uppdrag (seminarie-liknande aktiviteter som den tänkta konsulten förväntas hålla) etc. För om alla dessa undersökningar gjorts kommer rätt beslut fattas.

Viljan att göra rätt verkar ha en förmåga att gå överstyr.

Både hos köpare, konsulter och säljare.

Och när köpprocessen är klar, är konsulten redan upptagen på annan plats och oändligt många arbetstimmar har lagts på en köpprocess som inte leder någonstans.

Så här skulle konsultköpare kunna göra i stället, åtminstone vill jag agera så när jag står i köpläge:

  • Pengarna först! Money talks! Se till att du som beställare har en avsatt budget redan när du börjar, så att när du hittar rätt konsult kan slå till direkt utan väntan.
  • Genom detta kan förankringsprocessen handla om avsatta medel, snarare än person. Så när det är dags för personintervju – kan du sköta det själv med någon nära teammedlem.
  • Får du ett bra intryck av personen och hyfsat pålitliga meriter,  ge det en chans, med möjlighet till snabb utgång. Avtala fram snabbt inköp – snabbt avslut om personen visar sig vara fel. Våga riskera att du omöjligt kan ta reda på allt om personen i förhand. Väg tiden före mot värdet efter.
  • Om personen är rekommenderad av någon du litar på, eller du har hittat denna genom dina nätverk och kontakter, slå till direkt! Det kan visa sig vara fel, men vad är rekommendationer annars värt?
  • Bestäm i förhand hur mycket tid som får läggas totalt på köpprocessen av involverade personer internt. Fördela den där det ger mest värde. När den bestämda tiden är förbrukad, fatta ett beslut. Är du för osäker? Fatta beslutet nej då.

Konsulter är en fantastisk kraft för tillfälligt arbete, när du inte vill anställa. En mer medveten köpprocess kommer gagna både köparens organisation och samhället genom att kompetens används där den gör mest nytta.