To Move Faster, Experiment More
Als je ooit een deadline voor een softwareproject hebt moeten voorspellen, ben je maar al te bekend met de wet van Hofstadter :
Het duurt altijd langer dan je verwacht, zelfs als je rekening houdt met de wet van Hofstadter.
Het is dus geen verrassing dat elk productontwikkelteam meer 'behendig' wil zijn. Voor de naïeve CTO is 'agile' slechts een synoniem voor 'snel'. Het is een magisch zoekwoord dat de loopband versnelt en een team vertelt sneller te lopen , sneller opstarten en meer doen met minder. En als dat allemaal agile middelen in uw organisatie zijn, dan zult u teleurgesteld zijn als u een muur van gemiste verwachtingen, uitgebrande werknemers en stagnerende statistieken raakt.
Dat komt omdat goede behendigheid niet hetzelfde is als snelheid. Het is de vereiste voor snelheid, niet het eindresultaat. Wendbaarheid is het vertrouwen dat u nodig hebt om snel te bewegen . De meeste technische teams zijn niet traag omdat ze lui zijn, omdat het werk te zwaar is, of zelfs omdat ze onderbezet zijn. Ze zijn traag omdat ze bang zijn - en meestal om een goede reden.
De angst waar ik het hier over heb, is de faalangst. Als uw product een bepaald niveau van goedkeuring heeft, dan is er zo veel dat er mis kan gaan. Als een kaartenhuis kost een applicatie jaren om te bouwen en een seconde om te kloppen. Er zijn miljoenen manieren om uw site te verbreken, uw statistieken te gebruiken en uw gebruikers te irriteren, en kostbare manieren om er zeker van te zijn dat u niet zo'n fout maakt. Dus hoe meer ons product groeit, hoe meer we bang worden. En ironisch genoeg eindigt deze angst om te falen juist het ding dat succes voorkomt. We maken ons zorgen over de verkeerde weg, dus we gaan langzaam en voorzichtig. We worden nerveus van gewaagde beslissingen, dus we wachten op consensus. En we beginnen bang te zijn voor verandering, dus klampen we ons vast aan de status-quo.
Er is iets heel primers aan deze angst. Het is alsof we bang zijn in het donker. Denk aan de laatste keer dat je de badkamer moest vinden met het licht uit, of naar buiten liep zonder een zaklamp.
Wanneer we proberen in het donker te bewegen, lopen we voorzichtig. We houden onze handen voor ons uit en schudden langzaam, bang om te struikelen over ongeziene obstakels of tegen pijnlijke barrières aan te botsen. We nemen zorgvuldige stappen en gaan op zoek naar aanwijzingen, in de hoop dat we niet verdwalen. We klampen zich dicht bij de groep vast en volgen de luidste stemmen omdat we geen duidelijk pad zien. En hoe hard we ook proberen samen te blijven, we dwalen onvermijdelijk in verschillende richtingen.
Stel je nu je baas voor, staand voor al hun werknemers strompelend rond in het donker, schreeuwend "GO FASTER! WAAROM LOOP JE NIET? "Het kan de dingen alleen maar erger maken. Ze drijven sneller, botsen sneller, struikelen sneller en vallen sneller - maar ze zullen eigenlijk niets sneller bereiken omdat ze het pad of de bestemming niet kunnen zien. Als dit is hoe het voelt om software in uw organisatie te ontwikkelen, ligt het probleem niet bij uw mensen, maar bij de tools die ze proberen te gebruiken om in het donker rond te reizen. Traagheid is een product van angst en angst is een product van onzekerheid.
Now imagine a flashlight. What if every employee could flick a switch and suddenly see everything — where they are, where they’re going, and what the path looks like from here to there. Then suddenly they wouldn’t have to shuffle and stumble. They could start to run, confident that each step would get them closer to their destination.
This is the lesson we see over and over in agile development. When engineers have automated tests, they can refactor anything without worrying about what might break. When teams adopt frameworks like Scrum, they can adjust their approach in the middle of a project to adapt to customer demands. When launches are gated behind feature flags, anyone can roll out a bold new idea, secure in the knowledge it can be rolled back at the first sign of trouble.
What each of these practices points to is the essence of agile product development: a culture of experimentation. This kind of culture empowers your team with the confidence to make bold changes by constantly validating your ideas with data. Experimentation is the key to agility because it makes you fearless. It’s the flashlight that illuminates the whole product development process, giving your team the clarity it needs to build the best possible product for your users.
What does this mean concretely? There are many ways to experiment, from simple A/B testing to elaborate multivariate approaches. It’s a cultural mindset more than a specific tool, but generally it requires a few key practices.
The first step is establishing metrics. You can’t develop products effectively if you don’t know what you’re trying to achieve and how well you’re tracking towards those goals. What does success look like for your product? To answer that question, you’ll have to work backwards from your company’s business model — which might be based on subscriptions, advertising revenue, in-app purchases, or some other activity that drives success for the business. For any given feature, you should find concrete metrics that capture its impact toward those goals, like increasing retention, driving actions like reading and sharing, or reducing churn from high-value customers. Whatever the metric is, you have to measure it reliably and then hold your team accountable to improving it.
Once you have metrics, you can start using hypothesis thinking. Instead of a “waterfall" roadmap made of dramatic launches, develop theories about how your users behave and where your product can go. For example, rather than declaring “we have to redesign our signup flow," you might ask, “why do only 22% of new users sign-up?". You could then consult your metrics, analyze the data, and form a hypothesis, like, “if we had a simpler sign-up flow with fewer steps up-front, our users would sign up at a higher rate because they’d get value from the product sooner."
As Satya Nadella of Microsoft puts it:
If you are going to have a risk-taking culture, you can’t really look at every failure as a failure, you’ve got to be able to look at the failure as a learning opportunity….Instead of saying “I have an idea," what if you said “I have a new hypothesis, let’s go test it, see if it’s valid, ask how quickly can we validate it." And if it’s not valid, move on to the next one.
There’s no harm in claiming failure, if the hypothesis doesn’t work. To me being able to come up with the new ways of doing things, new ways of framing what is a failure and what is a success, how does one achieve success — it’s through a series of failures, a series of hypothesis testing. That’s in some sense the real pursuit.
Armed with a clear hypothesis, you can start validating ideas through gradual rollouts and A/B testing. For every UI you design or API you build, the question to ask is: “did we accomplish what we set out to do?" To even pose this question, you must first have defined your goals, measured them with metrics, defined the problem, identified a solution, and gated that solution behind a feature flag. Only then can you validate it by bringing it in contact with your users, as early and as frequently as possible. You can validate a new feature through gradual rollouts, monitoring your metrics as you go, or you can measure it directly by running an A/B test where half your users get the new feature and the other half don’t.
And finally, you can use experimentation to iterate through variations of an idea. The term “A/B testing" is really a misnomer, because the most effective experiments have more than just two variations and proceed through many cycles of improvement. Instead of a linear product roadmap, with each feature either launched or killed, imagine a forking tree, with each feature tested and tweaked through many variations. One reason to try many possibilities is that you’re more likely to find a better outcome. Optimizely’s data shows that experiments with a single treatment have just a 14% chance of significantly improving metrics on average, but tests with four treatments double this chance to nearly 28%.
What these numbers should illustrate is that most experiments fail, and that’s the point. By testing many hypotheses, and many variants of each approach, you steer your team towards the biggest impact for the business. You also learn valuable lessons along the way, driving future hypotheses for more ambitious experiments over time. A/B testing is often misunderstood as purely a trick for driving clicks on forms. But experimentation is broader and deeper than that. The best product teams deploy it not just as a tool for increasing conversions, but as a cultural practice that unlocks agility by giving engineers and product managers the confidence to take smart risks.
So if you want your team to move faster, challenge them to experiment more.
Dit is de eerste in een reeks artikelen over hoe je betere producten kunt bouwen door te experimenteren. Ons doel is om het proces van A / B-testen te demystificeren en rollouts te voorzien, dus deel uw vragen en feedback in de opmerkingen. En als u klaar bent om uw productexperimenten naar een hoger niveau te tillen, probeer dan Optimizely Full Stack .
Source: blog.optimizely.com
