Agile Nearshoring with Yogurt!

At a recent beerstorming (*), we discussed how to make nearshoring of software development work. Funny enough, the smooth taste of Yogurt entered the picture.

(*) Beerstorm is a fun-name invention for a practice came out of experimentations; it has very good effects on my spirit, it literally drags me into the zone… 

A primer on Yogurt cultures!

Yogurt brewing, when done the natural way, is a fascinating process. A perfect example of nurturing a self-reproducing organism. The bacteria used to make yogurt is known as “yogurt cultures”. Fermentation of lactose by these bacteria produces lactic acid, which acts on milk protein to give yogurt the characteristic texture we love.

Continue reading

Know your feedback loop – why and how to optimize it

If you always write perfect code, know how to predict the future and don’t care how your money is spent, you don’t need to read this. The rest of you need to know this stuff.

What is a feedback loop?

A feedback loop is the path your assumptions travel before they are validated or invalidated. Naturally you will have different feedback loops for different assumptions. In this post we will discuss three levels of feedback loops that should be easily recognizable. They are:
Continue reading

What seems to be the Problem, Solution?

Like so many others, you’re ready to start practicing Lean Startup and Customer Development. You’re about to start working on a new product or feature, so the timing is perfect. You sit down with a Lean Canvas and start filling it in. However, if you are like most of us, you will quickly come across the following obstacle:

You have already gone ahead and designed a Solution in detail. You’re also quite sure that it is good. Why go through all that work if you already know what to build?

The quick answer is that you may have built a Solution, but not a Business Model. You have to take one step back: Is there actually a Problem out there that my Solution is the answer to? Is the Problem important enough for Customers to pay for having it solved?

You can and should do Problem Interviews with potential customers even though you have a specific Solution in mind. First of all, it might inform you and enable you to make your Solution better. Having figured out the most pressing Problems will help you build a better Unique Value Proposition and thus improve the chance for success in the marketplace. Finally, if you figure out that your envisioned Solution does not solve any important Problem, you will have saved a lot of money.

Reverse-engineering a Problem from a Solution is quite possible. You have to get out there and do Problem Interviews, but you have to follow a few simple rules to succeed:

1) Don’t go out looking for confirmation. If that’s what you do, you will find it. Keep an open mind and do what you can to keep your hypothesis falsifiable and your interview scripts unbiased. The input you get will be very valuable when you decide to go ahead and build your product.

2) Listen to the customer, but don’t ask for advice. It’s very easy to show your Customer a demo of your Solution and ask him what he thinks. Pure politeness will require him to be positive about whatever you put in front of him. Find ways to test your hypothesis without leading the Customer to a given conclusion.

3) Get out of your own circles quickly. Interviewing friends and family is a nice way to get started and to iron out issues with your interview script. But they are not unbiased enough to build your conclusions on, and they are not likely to represent your Customer Segments well. If they have ideas for more people to interview, though, you will quickly be heading out of your closest circles.

4) Don’t give up too fast. Problem interviews can be discouraging when your Problems don’t resonate with the first Customers interviewed. However, your problem doesn’t have to be must-have for everyone. When you dig deeper you might be able to find a Customer Segment that feels your Problem more than others, and who really has the need for your Solution. They will serve as your Early Adopters and help you build your product.

That’s it. Put your Solution aside for the time being, and start testing to see if you have a Problem worth solving.

You’re Writing the Wrong Software – You Never Know What Users Want Until You Ask Them

Too often companies and IT departments believe that they know what software they should create. However users often need and want something different than you believe, even if you’re a domain expert yourself. My colleague and dear friend Ivar had exactly this experience when designing a meal planning tool for his girlfriend and himself. He knew everything perfectly – the previous tool they’ve used (a paper on the fridge), the problem domain, the users. Yet the first prototype tested did not at all match the ideas of what he thought was needed.

Continue reading

Implementasjon og lansering på Google Play Store

Etter to uker med effektiv jobbing kan vi med glede annonsere at applikasjonen vår nå er på Google Play Store! Applikasjonen vår, som nå er døpt Strandfunn, kan lastes ned fra Play Store til en rimelig lanseringspris.

I disse to ukene har vi parallellt med programmeringen holdt intervjuer, hvor vi har vist frem nye iterasjoner av design og funksjonalitet. Dette har gitt oss raske tilbakemeldinger slik at vi har kunnet tilpasse oss raskt det brukere ønsker, og få bekreftet antagelser vi gjorde angående utseende og funksjonalitet. Et eksempel på hvordan tilbakemeldinger har vært verdifulle, er hvordan filtreringsfunksjonen i applikasjonen ikke var intuitiv nok. Vi begynte med et søkefelt hvor brukeren skrev inn egenskaper som stranden skulle ha (såkalte tags). Når brukeren begynte å skrive ville applikasjonen foreslå forhåndsbestemte tags som passet opp mot det som ble skrevet inn. Dette viste seg fort å ikke være intuitivt, da brukeren i de fleste tilfeller ikke la merke til søkefeltet i det hele tatt. De som la merke til søkefeltet prøvde å søke på samme måte som man bruker en vanlig søkemotor som for eksempel Google og ble forvirret når de ikke fikk noen treff på sine egendefinerte søkesetninger.

Continue reading

En prosessorientert uke!

Med en ny uke kommer nye muligheter. Etter en produktiv uke har vi kommet langt på vårt minimum viable product (MVP). Denne ble lagd ved hjelp av HTML, CSS og JavaScript, verktøy som raskt lot oss skissere layout og primær funksjonalitet. Dermed kunne vi fort komme oss ut av kontoret for å vise fram MVP’en til potensielle brukere. Våre potensielle brukere er i første omgang det som heter early adopters, personer som liker å teste og ta i bruk nye applikasjoner. Ved å holde intervjuer med disse brukerne håpet vi å få gode tilbakemeldinger for å kartlegge hvor bra applikasjonen treffer det ønskede marked. Ettersom vi bruker enkle verktøy** er det lettere å jobbe fleksibelt, hvor vi er forberedt på at krav til funksjonalitet kan forandre seg fra dag til dag.

Continue reading

Er nye bygninger trygge?

Vi er vant til at programvare har feil. Bare husk de grufulle minnene fra Windows sin blåskjerm “blue screen of death”, som selv for Bill Gates kom på det mest ubeleilige tidspunkt (da Windows 95 krasjet under en demonstrasjon for pressen). Som brukere har vi forsonet oss med at programvare ikke er perfekt.

Enkelte av oss har nylig erfart ubehageligheter med selvangivelsen. Problemer mer alvorlige enn de vanlige ytelsesproblemene som kommer når halve kongeriket sjekker restskatten samtidig: Enkelte har til sin store overraskelse fått anledning til å se en annen person sin selvangivelse. Det er kanskje å ta offentlige skattelister en smule langt?

Vi stoler ikke på nye IT-systemer. Vi har lært oss å ikke oppgradere noe som helst rett før vi tar med oss laptoppen på hytta, eller før vi går i et viktig møte. Jo eldre programvare, desto tryggere føler vi oss, fordi tiden har luket ut de styggeste feilene.

Det er anderledes med bygninger. Selv føler jeg meg mindre trygg desto eldre bygning. En kompis bodde en gang i en loftsleilighet fra 1800-tallet, og etasjeskillerne besto av knusktørr halm. Én flamme på feil sted i første etasje, og hele bygningen hadde blitt en stor skorstein. Nye bygninger derimot, de står støtt. Bygget etter moderne metoder, og gjennomgått grundig ettersyn. Iallefall de fleste av dem.

Hva skiller disiplinene bygg og programvare? I byggeindustrien må man sikre kvalitet i hvert ledd. Du kan ikke bygge andre etasje før du vet at første etasje holder. Det er man (dessverre) ikke nødt til i programvareindustrien. Istedenfor å bygge integritet inn i løsningen, tester vi kvaliteten etterpå. Da finner vi selvfølgelig masse feil, som vi ikke har tid til å rette opp. Det er et paradoks: Vi tester for å finne feilene vi har laget, når det åpenbare alternativet er å unngå feilene i utgangspunktet.

Empire State Building ble bygget på ett år, men kanskje ikke utelukkende i små sikre steg ..

Hvorfor er det slik?

Continue reading

Få betalt for feil du ikke finner!

På dagens frokostmøte ble det ytret frustrasjon rundt testere i ett prosjekt som så det som sin oppgave å finne flest mulige feil i applikasjonen. Og det er greit nok det, om man har rigget prosjektet sitt på en måte som gjør at det er mulig å implementere feil i utgangspunktet. Kollegaen min refererte hele tiden til “oss” og “dem” når vi snakket om situasjonen.  Noe som forsterket muren som stod mellom utviklere og testere i dette prosjektet.

Dette er fra et prosjekt med den klassiske designe-alt-utvikle-alt-teste-alt-produksjonsette-alt-tankegangen (også kjent som vannfall). Ett av problemene er jo selvsagt strategien som er valgt, men hovedproblemet til min stakkars kollega er at utvikling kommer før test i et slikt sekvensielt løp. Det må jo være bedre om utviklere og testere samarbeider i større grad, tenker jeg? Noe man kan dra nytte av helt uavhengig av metode og strategi.

Continue reading

The splendid long iterations

Some times, we want longer iterations.

We waste to much time in meetings and other activities associated with iteration turnovers, so we decide to extend the duration of the iteration. Let’s make those planning meetings, estimation workshops, retrospectives and what-have-you happen less frequently. We might even get some work done, right?

Sadly, longer iterations don’t change how customers interact with us. We continue to get expedite requests, like having to fix a bug (which obviously shouldn’t have been there in the first place). Now that iterations are longer, we appear less responsive to our customers, which of course wasn’t the idea at all. To compensate, we could introduce mid-iteration releases?

Moreover, with longer iterations management feels less in control, because feedback is less frequent, and problems seem to pile up more now than before. That wasn’t the idea in the first place, so they feel compelled to introduce stricter reporting. How about a mid-iteration report?

Finally we get to the iteration turnover. We have experienced flow and feel great, except lack of coordination within and between teams makes our stuff not work that well together when we integrate. We decide to talk more. So we introduce a regular integration planning meeting with the other development teams. Would twice each iteration do?

Making iterations longer can be comfortable for a while. It feels better to work longer periods at a time undisturbed, and it feels better to spend our working time developing as opposed to attending meetings.

What's the scent of your learning cycle?

Longer iterations are however nothing more than a dangerous painkiller, which conceals the real problems we have. Double the iteration length, and iteration turnover gets four times as painful and half as useful. The reasons we have iterations in the first place is to create learning opportunities. Why would we want less of them when we could have more?

Longer iterations create room for more waste, forcing us into compensations that drive more compensations. We get iterations within iterations. We get wasteful reporting. We get less coordinated and produce more bugs. We stop doing retrospectives because we don’t have time to follow up on the resulting action points anyway. The resulting problems call for more meetings, and we get tempted to extend the iterations even further, which makes iteration turnovers even more painful. In the end we’re so sick of iterations that we start longing for waterfall.

Taiichi Ohno, the great engineer and systems thinker at Toyota had a helpful analogy about rocks and water. Imagine your process being a river with rocks on the bottom. The water is our level of comfort, and the rocks are everything which we shouldn’t be doing. Ohno calls them waste, which he defines as everything we do that doesn’t bring value to the customer. When the water level is high, we hardly see any rocks, hence the only way to find waste is to lower the water level. In other words, make ourselves less comfortable.

How does this translate to the pain of iteration turnovers? We do more of it. We have those turnovers so frequently that we have no other choice but to get good at it. In other words: When iteration turnovers are painful, we make the iteration duration shorter.

Here’s a question to ask our team: What would it take to go to half the iteration length, while keeping our current velocity?

We would have to make meetings shorter and more efficient. We would have to reduce the defect rate. We would have to make deployments faster. We would have to stay coordinated at all times, both within and between teams. We would have to follow up rigorously on action points from retrospectives.

That’s when we stop curing symptoms and start acting on root causes of problems. That’s when we start doing continuous process improvement.

That’s when we want even shorter iterations.

The user feedback problem

If you’re into agile, you’ve probably encountered this question: If iterating over user feedback is so fundamentally important, how come Apple has repeated success with their apparent one-off, non-iterative, grandiose launches of new products?

Monty Python I'd like to have an argument

Is this the place for user feedback? (I told you once)

Agile skeptics love this argument. To them it’s a once for all win over advocates of frequent releases. They probably feel like Michael Palin in his surreal Monthy Python sketch with John Cleese, where they enthusiastically have an argument about whether they have an argument. Desperately fighting and imminent defeat after failing to stop arguing when “time’s up”, Cleese responds “I might be arguing on my spare time”, to Palin’s pointing-in-your-face-gotcha-finger.

“No you’re not”. “Yes I am”. “No you’re not”. “Yes I am” …

Similar surreal arguments happen in software companies. There are always someone who doesn’t want to go into production in short, regular intervals, and there are always someone who wants it.

So what’s Apple doing? Iterating on their spare time? Maybe the rest of us should look to Apple and grant the skeptics right. Stop nagging ourselves with those tedious deployments, not to mention the even more tedious user feedback. We’re talented developers, trained professionals, experienced craftsmen – let’s go with our vision and gut feelings just like Jobs did!

Both within the agile community and other places I encounter this misunderstanding disturbingly frequently. Moving on from the triumphant Apple argument, the skeptics continue: Users lack fantasy. They don’t know what they want, and will ask for solutions within a narrow mindset framed by whatever it is they use today. Henry Ford nailed it forever with his famous quote: “If I had asked people what they wanted, they would have said faster horses.”

This is where I think things get tricky: In a sense the skeptics are both right and wrong. It’s true that users lack imagination and even lie some times. Hence, they are right that we shouldn’t ask users what they want. They are however wrong about not frequently releasing to production.

The fact that users don’t know what they want is no excuse not to iterate.

We should still interact with our users – and we should use our software as medium. First and foremost we must have empathy with our users. We need to fundamentally understand them, better than they understand themselves. If we do ask users questions, we don’t ask about features. We ask how they feel when logging into their computer. We ask what’s their favorite software, and why. We ask why they are using our product.

When iterating cleverly we’re somewhere in the middle. (Comic: Calvin & Hobbes)

From this insight we might get tons of ideas for features. We verify them one at a time, quickly. We refine them and verify the refinements in a tight build-measure-learn loop: Cut a feature into the thinnest slice possible, and deploy it. Monitor what happens. Deploy two different versions of the same feature and monitor what happens. Pull a feature which is hardly used and see what happens.

What’s interesting about this approach, is that neither the overacting agile crowd, nor the agile skeptics will agree with you. To them you’re either not listening to your users, or you’re letting them dictate a product without direction. (Thanks to Kent Beck for this perspective).

From Eric Ries book The Lean Startup: We really did have customers in those early days – true visionary early adopters – and we often talked to them and asked for their feedback. But we emphatically did not do what they said. We viewed their input as only one source of information about our product and overall vision. In fact, we were much more likely to run experiments on our customers than we were to cater to their whims.

In the Scrum world there is a lot of discussion about a Definition of Done. Jeff Sutherland has a long list of steps that need to be carried out before a task is done. To me he’s missing the most important part: That you’re not done with a feature until you’ve analyzed the behavior of paying customers using it.

Focus groups, user dialog, staged usability tests in artificial environments and situations can all be sources of insight, but they can also be deceiving. The interesting part is not what the users say – it’s what they do, on a daily basis: The Proof of the Pudding is in the production usage data. Hence we should develop a way to quickly try out features, gather usage statistics, opinions and other knowledge. It might also be a good idea to recap statistics classes from the university days, make A/B-testing easy, and if your product is in the public, use sites like usertesting.com.

I don’t believe Apple isn’t iterating. Having hardware products they cannot iterate like a software company. Having a marketing strategy which builds up hype around spectacular launches calls for subtlety. But you don’t really think they came up with all those products without seeking insight into their users?

Arguments shouldn’t be about whether we release frequently or not. It should be about how we do it. So if you haven’t already, I encourage you to start a discussion with your team about sources of insight into users, tools for gathering such insight and what iterative strategy would support this. You may also want to reiterate how your organization is set up.

You will be innovating before you know it. @hauge2


Liked the article? Join a free mini-seminar about Guerilla User Reserach in our office in Oslo on the 11th of december, 8:00. You will learn why asking your users for what they want isn’t always helpful, which do-it-yourself techniques you can use to understand their needs, how to make sense of the data you collect, and how all of this translates into the development of better features. Sign up here>>