I think it started with the article How to take Smart Notes by Tiago Forte a few months back. It's quite a long read and among other things, it taught me about the 20th-century German sociologist Niklas Luhmann and his knowledge system called “Zettelkasten”.

Learnings from the article reinforced an idea I already had growing on myself. I felt that a lot of knowledge from reading articles or watching talks was lost. Given the time investment it takes to consume all this content, only to forget about it a few days later, was a terrible ROI. I had to do something about this. I thought about summarizing articles but didn’t really know where to start, until now.

So I started writing summaries of articles I read. Around the same time, I heard about a new note-taking app called Roam. Roam has the ability to link notes together and form a knowledge graph, similar to that of a Zettelkasten.

Fast forward to earlier this week. I was watching a talk about bootstrapping a SaaS and something special happened. I noticed that I was watching it differently from before: I was keeping a mental list of items that I thought were important enough to summarize later on. Then it hit me:

When you start taking notes and make it into a habit, you will read/watch differently. You will constantly be thinking about how to summarize it while reading an article or listening to a talk.

This has some great benefits. Making mental lists boosts your ability to remember it later, but it also helps you to connect different concepts together. The latter is a vital part of learning. So instead of just consuming the content, you'll start to actually learn something new.

These days I take notes on about anything. Articles, talks, meetings, etc. I also link these notes together based on related concepts. Roam is a big help here, as it can suggest related notes. Working with your notes on a daily bases also acts as a form of spaced repetition, reinforcing the knowledge in your memory.

I found that the more notes I take and connect to each other, the more powerful it becomes.

Do you have any feedback? Feel free to send me a tweet.

At my workplace we have different product teams. From management there was a clear wish to make team performance visible during Sprint Reviews. The natural response was to present Scrum related metrics, like velocity (story points committed vs delivered).

These general Scrum metrics feel a bit off to me. Take velocity for example. What does this tell us? Say that we have a product which receives 10 new bug reports every week and every sprint we fix these bugs. Our velocity would be pretty good. But does this mean our team and product are doing good?

Let's take another example. John Cuttlefish recently published an excellent post about signs of working in a Feature Factory. Say our team is only focused on shipping new features, but neglects attention for technical debt. The velocity metric would still indicate everything is fine, as story points are being delivered. But if we keep accumulating more and more technical debt, is our team really performing well?

If velocity doesn't actually tell us how we are performing? What does it tell us? The one thing I can think of is that it tells us that the team is busy. And being busy by itself doesn't say anything. We want to know if we are actually performing and bring value. So this brings us to our main question.

What are good measurements of team and product performance?

We can do a bit of reverse engineering to come to these measurements. Let's start with our main goal. We want to build a product, which solves the problem(s) of our customer in an efficient way, resulting in happy end-users.

So what makes customers (un)happy?

• When a product is unavailable, users won't be happy. So a high uptime would make them, or at least keep them, happy.
• When things don't work as expected, users won't be happy. So a low bug report count indicates that things work as expected.
• When a bug is reported, users will be happy if it's quickly fixed. So time from initial bug report to fix in production should be as low as possible.
• Getting exceptions is quite frustrating for users. So also the number of exceptions should be as low as possible.
• When the application feels slow, users will be unhappy. So response times of web requests should be as low as possible.

We could also just ask our end-users what they think of the product. One way would be to send a survey every once in a while to rate (1 to 10) certain aspects of our application. Similar to a NPS survey. We can think of questions like:

• How do you rate your productivity within the product?
• How do you rate the usefulness of our product?
• How do you rate our customer support?

By tracking the average of these scores over time and plotting them on a graph, we can easily see if we improve as a team or not.

Technical indicators

Considering we are talking about tech teams we can also ask ourselves what technical indicators tell us how we perform?

• Tests prevent regression, so test coverage should be sufficient
• Slow tests are killing productivity, so time to run all tests suites should be kept within an acceptable range
• Same goes for waiting on peer reviews, so we could measure the average time between opening a PR and when it's merged.
• Or what about measuring deployment duration? The same as with tests, we want to keep waiting times for developers as low as possible.

And finally, just like asking our end-users, we can also survey our team and ask them to rate various aspects.

• How do you rate your productivity?
• How do you rate the productivity of your team?
• How do you rate your morale?
• How do you rate the morale of your team?

Conclusion

In this post we explored various ways to measure the performance of product teams. I hope this challenges you and your team to think further than just the standard scrum metrics. Collecting the right metrics gives you valuable insight in your teams performance and triggers healthy discussions on how and where to improve.

Do you have any thoughts on this subject? Feel free to reply on this tweet.

Big thanks to Sander Lissenburg and Ferenc Szeli for proof reading this article.

Recently I spoke a few fellow developers and they were unhappy with the performance of Docker on macOS. Personally I couldn't really relate to these performance issues. So what was going on? Well it wasn't hard to find the difference: They were using Docker for Mac, while I was using Docker Machine with Docker Machine NFS.

So yesterday I gave it a try. I send a colleague instructions on how to setup his development environment with Docker Machine. His reaction?

My docker is quite fast now

This gave me reasons to believe that this setup of Docker is actually faster than Docker for Mac. Feel free to try this for yourself using the following instructions.

1. Install requirements

First go to your project directory.

$ cd ~/git/<project>

Install the required software using Homebrew.

$ brew install docker docker-compose docker-machine docker-machine-nfs

$ brew cask install virtualbox

2. Create a virtual machine

$ docker-machine create <your-project-name>

3. Setup NFS

$ docker-machine-nfs <your-project-name> --shared-folder=`pwd`

4. Connect docker to the virtual machine

$ eval $(docker-machine env <your-project-name>)

5. Add virtual machine ip to hosts file

$ echo "$(docker-machine ip <your-project-name>) your-domain.test" | sudo tee -a /etc/hosts

6. Verify that everything works

$ docker ps

You can now start your project containers, e.g.

$ docker-compose up -d

Suppose that your project exposes a website on port 80 or 443, test that you can access it.

$ open http://your-domain.test/

Caveats

A few thing we have to remember:

1 . With every new shell instance we need to repeat step 4.

2 . After a reboot the VM is shutdown, so we need to start it:

$ docker-machine start <your-project-name>