Know or Guess

Leif Ershag
4 min readMay 23, 2017

What differs knowing from guessing is facts and i guess that we would like to make decisions based on facts. The best tool that humanity have managed to formulate for knowing things, generating knowledge, is the scientific method. Let us look at some ways we can replace guesses with knowledge. Everything based in the modern agile principle of Experiment and learn rapidly.

Experimenting with process
We should always strive after perfection and one way of reaching that is by incrementally changing how we work and measure how it changes or outcomes. If you have a gut feeling that a change would be beneficial, try to figure out how to measure the perceived benefit. Change the process and see if the perceived benefit is achieved. If you measure and see that it haven’t improved or maybe it has made matters worse: roll it back!

An experiment is a win if it generates knowledge, if your knowledge is that a change doesn’t have a specified effect that is fine. The important thing is that you learned that.

If you see the effect you hoped for you should roll the change out in a larger scale. Abandon experiments with the wrong outcome and amplify those that payed off. Then you should share the result of the experiment with the rest of the organisation also, so we don’t have to do the same experiment but can learn from your.

Experiment with features
An important part in working design-led and focusing on the UX, the user experience, is to actually consider how the system is used. Doing user-testing is one such activity. Quickly scetch a UI on a paper, put it in front of someone and tell them what task they are to complete. See where they would click and present them with more paper mockups. This is a quick way to get feedback on your workflow and UI before writing a single line of code.

Going one step further is to use eye-tracking software. There is software that only uses a webcam to track the eyes of the users. Tell them what they should do at a specified time and replay how their eyes search after the button/function over the screen. Repeat on several users and replay it on a heatmap. A team i was in used eye tracking on kids 3–5 years old to see how they search for a button, invaluable feedback!

Colleagues have been using Piwik to test which of two possible ways to navigate was mostly used. Piwik is an easy tool that enables you to see how often a function or a specific way to a function is used. Really valuable information!

Using tools like this enables us to minimize the amount of features to maintain… We can make sure we build the right things, that we remove things that are no longer used and that we only build the most intuitive way of solving a problem. Less code, less bugs, less maintenance enables more possibilities to solve our customers needs.

Using data for planning
If you have just three things you are able to use historical data to predict, with a statistical interval. What you need is one backlog, a group of people working with that backlog and historical data. The group of people can be individuals working in offices, one team, several teams. The important part is that they are consistently over time kept as intact as possible. Changing the group will make the data less accurate. It will also impact the performance of the group negatively, no matter if you add or remove someone from the teams.

Create a list of the number of items done in each week, sprint, month, release. As far back as you can call it the same group with only minor adjustments. Now calculate the standard deviation and, more importantly, the 5 and 95% confidence interval. This is the ones i have chosen for now, your mileage may vary. Now look at your backlog and see where you get in 1, 2, 3, 4 sprints with 95% confidence, 50% confidence and 5% confidence.

This is real data that is more valuable than any estimates can give you. Put into code this could be generated every time that backlog changes. You could have a live release plan on the wall of your team room that changes every time someone changes a priority in the backlog. You could even see over time how your improvements, your experiments with your process, reflects on the release plan. This will make it possible to say “It’s 95% certain that you will get this before August, it’s likely you will have it by July though.”

End notes
I hope i have given you ideas that you can use directly or at least inspired you on how to improve how you improve.

--

--

Leif Ershag

I'm the geek who didn't get the girl until the last episode. Code gardener at Tieto. Agilist.