Kan UX lära av agil produktutveckling?

UX-Open

Igår var jag på den fantastiska konferensen UX-open som gick av stapeln för fjärde året i rad! Blixttal blandades med workshops och paneldebatt där alla deltagare lyssnade, lärde och förde samtal om hur vi ska förhålla oss till användbarheten i våra verksamheter.

Sälja in användbarhet

En genomgående diskussion på konferensen handlade om att ‘sälja in’ användbarhet och övertyga om att användbarhetsmetoder ska få användas i produktutvecklingen. UX lyftes fram som en viktig roll som behövs för att vi ska veta om våra produkter går att använda och om vi utvecklar efter våra målgruppers behov. Diskussionerna förde mig tillbaka i tanken till när agile var det som behövdes säljas in till chefer och ledare ute i verksamheterna.

Agile har lyckats- de allra flesta har anammat de agila utvecklingsmetodikerna även om inte alla är på samma mognadsnivå.  En viktig faktor för att agile skulle fungera var att fokusera på samarbete och tvärfunktionell kompetens i teamen. Man tog makt över HUR saker skulle göras och lämnade VAD till de styrande och ledande personerna i verksamheten.  Med det tvärfunktionella arbetet följde ett borttagande av roller och ett förtydligande av vilka kompetenser som behövdes för att lyckas med uppgifterna. Man tog också hand om att ständigt förbättra sin egen utvecklingsmetodik- vilket innebär att man själva är ansvariga för att förbättra sitt samarbete och väg framåt.

Bredda kompetenser

Kan inte UX göra samma sak? Vi behöver UX som kompetens för att kunna lyckas med en bra produktutveckling. Jag som produktägare och produktledningscoach har provat att bredda kompetenserna från produktägaren som en roll till ett produktledningsteam där UX har en naturlig plats. I den tvärfunktionella grupperingen har vi också såklart ansvar för att ständigt förbättra vår egen metodik, och därmed kan vi själva styra över att UX-metoderna får den plats de behöver. Kanske inte alla metoder på en gång, utan prova en, utvärdera och göra om: Inspect and Adapt

Kanske är det svårare att få plats i de styrande och ledande funktionerna av produktutvecklingen, men om inte vi som har rätt erfarenhet och bra metoder med oss kan,  vem kan det bättre? I mitt blixttal på UX-open: ”Produktägare eller Produktledingsteam” pratade jag om ett tvärfunktionellt arbete i ett produktledningsteam istället för en ensam produktägare. Kompetenserna som behövs är säkert olika i olika verksamheter, men vi provade användbarhet, affärsnytta och teknik. Det fungerade för oss!

3 kompetenser

Produktägare eller Produktledningsteam för bra produkter?

Produktägare eller Produktledningsteam för bra produkter?

Har ni produktägare i er organisation? Någon mer än jag som tycker att rollen är alldeles för svår att leva upp till? Kan man verkligen både göra och ansvara för allt det där som Scrum beskriver ska ingå i rollen för att få fram en bra och säljbar produkt?

Vi var några personer med olika kompetenser och bakgrunder  som istället provade att dela på rollen och forma ett produktledningsteam. Vi jobbade tillsammans med affärsnytta, användbarhet och tekniskt kunnande för att på så sätt kunna leverera en bättre produkt.   Vi prioriterade hur produkten skulle utvecklas från de olika perspektiven.

Effektmål och mätbara mål

måttband

Vi fokuserade tidigt på den effekt som vi ville uppnå.  I vårt fall ville vi att 75 % av användarna skulle kunna utföra sina egna beställningar i gränssnittet.  Vi hade uppenbara problem med användbarheten och istället att använda gränssnittet ringde användarna till kundtjänst. Eftersom det övergripande effektmålet blev uttalat och överenskommet var det enkelt att komma igång och få med organisationen på vad vi ville göra och varför.

I anslutning till  effektmålet satte vi upp andra mål som gick att mäta och följa upp. Dessa var både funktionella som handlade om affärsnyttan, och icke funktionella som fokuserade på användarupplevelsen och systemets ändamålsenlighet.  Vi analyserade till exempel hur urvalsprinciper och kvoter skulle förändras,  och därmed vilket pris som skulle gälla för respektive princip. Det gick att sätta upp en prognos för hur vi trodde att användarna skulle bete sig och bevaka om så skedde eller inte. Uppföljningen hjälpte oss att återkommande fatta nya beslut om den funktionalitet vi valde att utveckla tog oss närmre målet, eller längre bort. Detta blev ett väldigt bra sätt att jobba på då vi fokuserade på riktningen istället för på att se den interna processen eller på förhand uppsatt scope.

Vi satte upp både en baseline för det existerade systemet och ett önskat läge  i det vi skulle bygga som vi kunde enas om mellan produktledning och ledningsgrupp. Det var en väldigt viktig del i vårt arbete.

Intern dialog och användarintervjuer

Den interna dialogen vi hade fått till genom att kommunicera de mätbara målen, kompletterade vi med wireframes och skisser på hur vi trodde oss att systemet skulle se ut och fungera. Vi i produktledningsteamet behövde lära oss av de som dagligdags träffade användare –  t.ex. kundtjänst och säljare. Samtidigt som vi i produktledningen lärde  oss av dem kunde vi skapa en gemensam förståelse för hur vi tänkte oss det nya systemet och gränssnittet. Det var en mycket bra och tidig feedback där både våra kompetenser om affärsnytta, prioritering och användbarhet kom väl till pass.  Besluten vi gemensamt kunde fatta och den kunskap vi hade byggt upp  kom till användning när vi väl började vår resa för att testa våra prototyper.

Genom att vi utförde användarintervjuer som vi genomförde skapade vi en förståelse för hur det existerande systemet fungerade för användarna. Vad som var problematiskt eller rent av omöjligt att använda blev tydligt.  Vi fick en inblick i användarnas situation, kunskapsnivåer och vana att använda både vårt system och andra IT- system generellt. Det hjälpte oss att se och förstå vår målgrupp och kom att betyda mycket för oss när vi utvecklade produkten.

Tidig feedback!

Genom vårt arbetssätt hade vi både idéer och mål som vi trodde kunde vara sanna och kanske möjliga att uppnå. Genom kontinuerliga prototyp- och användartest fick vi väldigt tidig feedback på användbarhet och affärsnyttan. När vi kom upp i hastighet kunde vi testa med användarna inför- och efter varje sprint. Det gjorde att vi hade ett kontinuerligt flöde av återkoppling. Därmed kunde vi ändra riktning innan det blev både för dyrt eller jobbigt.  Eftersom vi jobbade med både affärsnytta och användbarhet samtidigt och i samma sprint stod vi samlade varje dag och delade med oss av kunskaper och prioriteringar till teamet. Guld värt!

Tekniska test och realisering

En annan slags feedback som var vår tredje kompetens i produktledningsteamet var såklart de tekniska valen. För att kunna realisera både icke funktionella och funktionella aspekter av produkten behövde vi arbeta med tidiga tekniska test. Genom detta arbetssätt fick vi helt enkelt veta väldigt tidigt om våra tankar, idéer och koncept skulle bli onödigt dyra eller ens möjliga att genomföra. Ingen av oss ville sitta fast hur länge som helst innan vi kunde realisera en riktig affärsnytta till användarna så att vi hade den tekniska aspekten med i produktledningen gav oss en snabbhet och smidighet som var nödvändig. Vi fick såklart också ett mycket bra samarbete om hur funktionalitet kunde realiseras.

Uppföljning som strategiskt internt vapen!

Eftersom vi tidigt hade satt upp ett effektmål samt mätbara mål som vi trodde att vi ville realisera fokuserade vi mer på att kommunicera om vår riktning än om precis vilken funktionalitet vi tänkte realisera härnäst, kostnaden eller utvecklingens hastighet. Det här gjorde att vi kunde skapa oss en strategisk nivå där produktledning och utveckling kunde producera och skapa med högt självbestämmande. Ledningen fick löpande information om hur användarna uppfattade produkten genom de mätningar vi utförde.  Vi tog och behöll initiativet om produkten och slapp på så sätt den onödiga kontroll och styrning från ledningen som inte hade lett till att produkten blev bättre. På sätt och vis eliminerade vi både våran och deras waste

Bättre produkt?

Eftersom vi använde kompetenserna affärsnytta, användbarhet och teknik parallellt växte vår backlog till att innehålla dessa tre dimensioner. Det var såklart ett överflöd av feedback, idéer och behov. Vi jobbade nära den interna organisationen, i nära dialog med våra användare, fokuserade på affärsnytta och fick tidig kunskap om våra tekniska begränsningar och möjligheter.  Överflödet var inte på något sätt dåligt, utan gav bara oss en möjlighet att tillsammans bestämma oss för hur det verkade vettigt att realisera produkten.  Samarbetet mellan de tre kompetenserna i produktledningteamet gjorde det möjligt för oss att göra en riktigt bra produkt!

Det är mycket mer effektivt att bredda sin produktägargrupp till fler kompetenser så man kan arbeta tillsammans i ett tvärfunktionellt team för att få fram bra produkter!

overflowing

Mitt blixttal från Agila Sverige 2015

Holacracy? Not for me!

Taggar

, , ,

Image result for tangled rings

I must admit I’ve been a promoter of the Holacracy movement for some time now without really knowing in any detail what I was cheering for. Holacracy is promoted as an organizational system that distributes authority evenly throughout the organization compared to a traditional hierarchical organization. Many of my fellow “agile-nerds” have been promoting it as the greatest thing since sliced bread so it must be great, or so I thought…

Recently I finally got the time to study Holacracy in a bit more detail through reading the newly released book – Holacracy: The New Management System for a Rapidly Changing World – written by the inventor of Holacracy, Brian J. Robertson.

Unfortunately, I must say I was quite disappointed when I found out what Holacracy is. I have a hard time pointing out exactly why I get a bad feeling when reading it (or actually listening to the author reading it), I just do, but I’m going to give a shot at analyzing the bad feeling further down. I can say as much as this: It won’t be at the top of my list to work for a company practicing Holacracy. I actually think I can understand the reason why (at least some of) 200 people decided to jump ship when Zappos declared “either you’re in or you’re out” (with regards to Holacracy).

So what are my main objections? Read on!

1. It’s far from the “work on the project you want” concept that is common in some modern companies like Valve and GitHub
Holacracy is based on a hierarchy of circles, the outer circle decides what the inner circle does. The “Link Lead” of the circle decides who to assign to which role that is defined in the circle.

2. The author mentions the word governance about 3000 times in the book
That word is not my favorite, especially after working with (or for) some bosses who saw it as their main mission to establish governance and then govern all the resources that reported to him or her.

3. It feels like “process before people” rather than “people before process”
The processes that make up Holacracy are very extensive and very specific down do which meetings shall take place, who shall attend, who is allowed to say what and so on.

4. It does not feel very agile
If you discover a “tension” which could mean there is a type of task that is not clearly stated in anyone’s role description you don’t just go ahead and do it or ask someone else if they can do it. No, you write up a proposal and bring that proposal to the next Governance Meeting (which is about once a month). Then the government meeting decides who should put that type of task in their role description and thus do it in the future. Sorry, that does not sound very agile and adaptive to me!

5. They are tearing down the pyramids but I still get the feeling there are “more important people” and “less important people”
Even though there is not a formal hierarchy (at least not top-down), I get the feeling there are roles that are “better” and more exclusive than others (such as being the Lead Link of a large circle). Also, it sounds like it is desirable to have as many roles as possible. The author mentions something about having some 30 roles in his own company. I bet a junior person don’t have that many roles!

6. The “Lead Link” role sounds a lot like the Scrum Master role I see in a lot of companies where they have implemented the role in a bad way (according to me)
A lot of companies I have worked for and read about have implemented the Scrum Master role in what I would call a bad way. They turn the Scrum Master into a “miniature manager” or project manager who handles all the relations with the outside, goes to project meetings, process meetings and so on. Some Scrum Masters I have met even makes decisions for the team and decides large portions of the team’s process. This sounds exactly like the Lead Link role according to the book.

7. I can smell money making forces a long way…
“Certified Holacracy Practitioner”, “Certified Holacracy Facilitator”, “Certified Holacracy Coach”, “Certifed Holacracy Master Coach”. SAFe anyone?

8. What happened to “trust them to get the job done” and “theory Y”?
It is not a “trust them to get the job done”, “theory Y” style philosophy but rather a “specify in nitty-gritty detail what each role is responsible for so that they can’t bail out”, “theory x” style philosophy. The great thing about agile is that the team is autonomous and without roles and that they all help out to create value in the best possible way. We have tried the variant where we have separate developers, testers, analysts or whatever that simply sit on their butts and wait (or worse, create excess inventory) when there is nothing to do that fits their job description. It is NOT effective; neither does it generate a team spirit. In Holacracy everyone has one or many detailed job descriptions that define clearly what they do and what decisions they can make. To me it seems like it will be almost impossible to avoid the old “it’s not in my job description” problem.

OK, so maybe I’m being overly critical of Holacracy. I must admit, if applied to whole organizations I guess in most cases Holacracy would be a vast improvement to todays pyramid and silo structures. I guess I just had too high hopes for it. I’m a bit worried however that if Holacracy is implemented in a company, it stops there and there is no continued journey towards a more democratic company filled with theory X people who works together towards a clear purpose. It’s pretty much the same fear I have for “magic” models like SAFe.

Time for a new manager – let the group choose

At the company I work we faced the task of assigning two new managers for a group of consultants that were without a manger and also had grown too big for just one person to look after their needs. Traditionally this was done by our CEO and some other managers who looked for someone in-house by talking to people they thought were suitable for the job or sometimes by looking for people from the outside. Historically this had sometimes worked well and other times not so well.

This time we thought we should try something new. Why not let the members of the group choose?

3-leader

Our process looked something like this:

  1. We informed the group of what we were about to do and why we were doing it.
  2. We created a form with Google Forms that was sent to all the members of the group. It contained these two questions:
    1. Would you be interested in being the new manager for this group? (yes/no/maybe – tell me more)
    2. Who do you think would be suitable to be the next manager?
  3. After everyone had answered we gathered up the results and started talking to everyone who had given a ”yes” or ”maybe” answer to the first question. During that meeting we discussed their view on leadership and the challenges they saw from their point of view. We also answered any questions about what having this role would mean.
  4. We selected two candidates based on the number of nominations (this was the main thing we considered) but also looked at their view on leadership.
  5. We split the group mainly based on the nominations but we also considered social connections and other similar factors.
  6. We then talked to all the members of the group individually and asked them if they were happy with their manager to be or if they wanted to belong to the other group. If someone wanted to swap we let them without any questions asked.
  7. We talked to the new managers and told them what the groups would look like and helped them get started.
  8. Done.

This process became quite lengthy but the really great thing about this approach is that we have eliminated a lot of risks involved in a change like this. The new manager was instantly accepted by the group and the managers knew what they were getting themselves into and knew that they were accepted in their new role by their group.

This is still quite new and we will see how it plays out in the long run but from we have seen so far this is a really good approach when appointing a new manager or leader for a group.

Avoiding the meeting menace for your development team

Have you ever heard members of a development team complain about too many meetings? And when you look in their calendar all you find is a couple of meetings spread out through the week. As a Manager, Scrum Master, Product Owner etc. you might have thought ”That’s nothing – I have meetings a day long!”. This is a natural reaction but the point you are missing is that the nature of your work is radically different compared to that of the development team. While a lot of your work is done in meetings and your days are fragmented the teams work doesn’t work that way. Paul Graham describes it very well in his post from 2009 about the Maker’s Schedule and the Manager’s Schedule (I really recommend reading the whole post). He describes that a developers day may be blown to pieces if meetings are scheduled in a way that prevents them from getting some flow in their work. To remedy this I recommend talking about this within your team and adding it to your Teams Working Agreement(because you have one of those, right?).

closed

Examples of how this could look in practice:

  • Do like Facebook and have a meeting free day per week. During that day the team can completely focus on the work at hand without interruptions.
  • Have something similar to visiting or opening hours for the team. During these hours it is ok to schedule meetings. When you choose these hours I recommend considering having your prime working hours (high energy) as your non-meeting time. On the Working Agreement this could be formulated something like:
    • ”We are all in the office at least between 9 am and 4 pm. Meetings are scheduled after 2 pm.”
    • Or ”We do meetings after 2 pm. All meetings have a clear agenda and purpose. We are on time.”

I really recommend trying this out. And who knows, maybe you as a non developer find value in getting some uninterrupted thinking time as well.

Ps. You should of course still talk to people if you need help getting unblocked or help someone else get unblocked. ”People and interactions over processes and tools” is still what we strive for. This is merely a tool to help getting you meetings under control if that is a problem for your team. Ds.

Shorten your feedback loops with Cafe Testing

One of the teams I have been working with lately develop and maintain a retailing web site. Historically what they should focus on was decided by someone high up in the organization with little to no involvement of the team. After a lot of time and money invested most of those ideas turned out to have little to no impact on the number of purchases made through the site. To remedy this we wanted to leverage the collective intelligence of the team and also use a more scientific approach when deciding what to do. The approach we took drew inspiration from Lean UX and Lean Startup. We also used tools like Impact Mapping where the idea is to have a clear goal of what we want to achieve, see what actors could affect that goal and then look at what assumptions we have about those users related to that goal. After that we have our Impact Map and it’s time to get to work with the assumptions. We did this in really short iterations to keep the investments small if assumption turned out be false. One really useful way of validating ideas we found was to do lightweight usability testing. The way we did it often included theses steps:

  • We have an idea or an assumption about how we can better achieve one of the goals we are striving for at the moment. We selected the assumption that we thought could best contribute to the goal.
  • In the most lightweight way possible we create a mockup, prototype or MVP that could in some way validate or invalidate our assumption.
  • The next step is to do the validation and now it was time to get out of the building. We found that a good place to find test subjects was at a café at the grand central station in Stockholm. The benefit of this is that you find people from all over the country of all different ages. They are very often just waiting for their train and because of that very open to answering some questions in exchange for us buying them a cup of coffee.
  • When we have interviewed about 3-5 persons representing different personas we usually have enough data to go back to the drawing board. Did our assumptions hold true or do we need to focus on something else? Of course we can’t blindly go by what the test subjects were saying but it is usually a good indication.

We can usually go through this cycle in a day and that gives us really fast feedback loops and we avoid investing too much time and money in developing something just because someone high up in the hierarchy decided it was a good idea.

This approach has helped us a lot and perhaps it is something that can help you as well if it fits your context. Please post a comment below if you found this post helpful or if you have tried it yourself and have some insights or experiences to share.