Timebox

To run your own Learning Swarm you first need to decide upon a timebox, which is the time you are willing to dedicate an entire team towards learning the topic. It depends on the size of the topic but for it really to be worthwhile I would recommend around 3 days. You can always review it after 3 days and decide to extend it by a day at a time if need be.

Having a timebox for the swarm also really helps people focus on getting their work into a complete state as soon as possible and then iterate on it from there. A timebox also reassures managers that you have limited the time you won’t be delivering direct customer value, even if your timebox has to be large it is still reassuring to have it

Scope and Project

Once you have decided on how long and when you are going to run the swarm you can start thinking about what you are going to do during the learning swarm. First you should come up with a scope of what you want to learn, it might also be helpful to say what is explicitly out of scope. An example of your scope might be ‘GraphQL’, you might want to specify that although GraphQL uses the network ‘network protocols’ is out of scope of the swarm.

After you have defined your scope you should come up with an idea for a project you want to build individually. In the example of our GraphQL learning swarm you might want to make the project something along the lines of, “Build a todo list app using GraphQL”. This might seem really narrow but you would be really surprised at how 4 or 5 different people can build wildly different things based on this project description. I would encourage you to go deep into an area that interests you, but make sure to stay in scope!

Swarm Time!

Now you know what you want to learn and build you can get swarming! Everyone in the team should go their separate ways and learn about the topic and build the project. As you go everyone should keep detailed notes about what they have been learning, these will be the main artifact of the swarm. They might also be fairly repetitive between each person but that’s fine at the end we will merge them into a single document.

It is important you keep your daily stand up going because you might need to nudge each other to stay on track or you might have to help unblock someone because everyone needs a fresh pair of eyes from time to time. It’s also a good idea to share any resources you find on the topic, it’s not a competition so sharing is encouraged.

Closing the Swarm

When you reach the end of the timebox now is the time to come back together and share what you have learned! Setup an hour or two (depends on team size) to come together and discuss what you have learned. Everyone should give a quick informal demo of what they made and share what they enjoyed and what they found hard. It is good to record these meetings if you can for later reference. I would also suggest someone takes notes and generates a summary of the meeting.

It might also be worth summarising all of the learning notes that everyone has taken into a single place. I wouldn’t spend a long time doing this, just pull all the best parts together so other people can learn from it.

Now your team all knows a great deal more about a topic in a short amount of time and has practical experience with whatever you were looking into. So it is time to get cracking on with your real project!

As with all processes, make it your own! Maybe run it as suggested first then tweak it so it works better for you.

Example

We recently ran a Learning Swarm at Findmypast so we could get up to speed on authentication, specifically Auth0 libraries as they are our chosen third party for authentication going forward. We set our project to build a React app using auth0 authentication. Surprisingly we all took a different approach. We had people focus on automating config deployment, protecting backends, serverless authentication and comparing the different libraries Auth0 provides. In 3 days we went from a high level understanding of authentication to a deep understanding of the standards as well as plenty of code samples we all learnt from.

Software teams are often faced with the decision between buying in software solutions or building their own.

The example I will use is one that we I recently faced whilst working with a large client with an existing platform. Like most companies, we need a way to identify users securely. So we are asking the question: “buy or build an authentication system?”

When you face this question you typically have three options:

1. Build a bespoke solution

2. Host an open source solution

3. Or pay a SAAS company to deal with everything for you

Hopefully when you approach this decision as a company you will be doing it with people from across the entire business. The decision will often come down to money, which makes sense, however if you ask the wrong questions you will end up with a solution that only benefits you in the short term.

I’ll run through a few questions you might hear and why I think they are flawed and I will end with how to frame the question to get the best decision that works long term.

What is the cheapest option?

When you go to answer the question of what is the cheapest you have to start by obtaining the cost of each option.

It is easy to get the price of a SAAS option, you just go to the price page or contact sales. Importantly this price you get is totally accurate, you don’t have to worry about over or underestimating.

On the other hand it is very hard to measure the total cost of building and maintaining your own solution so it tends to get underestimated. Also humans are just bad at giving estimates and the bigger the project the worse the estimate.

To get the cost of building your own first you have to decide what you want to build. It is likely that you will not build all the features that the SAAS product is offering as the immediate value of them might not be obvious. However, in reality the features you are suggesting to leave out might be features that the SAAS business has added after extensive research and is actually one of their most popular features. So your comparison already starts out unfair as you are not giving an equal comparison.

So to answer this question you end up comparing solutions which are of massively varying quality and you are looking at estimates which have widely different confidence levels. Not a recipe success.

If you hear this question I encourage you to push back, and try and reframe the situation with the final question.

What is the most cost effective option?

This is a much better question to be asking, mainly because it shows consideration for maintenance cost however it still has issues.

When you are looking at how cost effective each option is you need to think about how long you want this solution to last. Do you expect this to be in place for 6 months or 10 years? Is it going to be an area of active development for your company or is it something you want to set up and forget?

It is easy to measure the ongoing hosting cost but that is probably the smallest ongoing cost. However there are so many uncertainties that are impossible to capture. What if a new standard is released? Do you implement it or stay on the old standard? What if the open source library becomes unpopular, do you start maintaining it yourself? What if the open source solution uses a database tech no one is familiar with?

The stars may align and you might not have any problems but more than likely there will be unforeseen problems that you couldn’t possibly capture when thinking about how cost effective the different options are.

In the example problem we have at FindMyPast looking at the cost effectiveness we will probably find that hosting an open source option is far more cost effective than building our own. You only have to pay maintenance costs and if the open source solution is popular it is likely in active development and maintenance, none of which you have to pay for. The ongoing cost of an open source solution will probably be lower than the ongoing cost of a SAAS product. However, you mitigate a lot of the uncertainty by going with a company who is motivated to solve those problems by the money they receive from customers.

What is the most profitable option?

This is the best question to ask as it now leaves room to acknowledge opportunity cost. No one can argue that the answer to this question is not important, ultimately profit is what drives the business. What is the opportunity cost? Google says:

“the loss of other alternatives when one alternative is chosen” - lexico

In our case our case the opportunity cost is the money that should have been made on the features you could have made instead of building your own system. This is again pretty much impossible to measure but it is very important to recognize the size of this cost.

Now that we are asking what option is more profitable we can begin to make an informed decision. One way to make profit is by adapting and innovating faster than your competition. When you are thinking about building you need to decide if the part of you application under question is something you can use to beat your competitors and make more money. If the answer is no, then you should buy.

If we look back again at the example of FindMyPast wanting a new authentication system. A robust authentication system is very important to have for us, and we can’t operate without one. However we will not win customers by innovating in the authentication space. We will win customers by innovating in the family history area. If we acknowledge that all time spent working on authentication is waste because it is not competing then anytime spent now or in the future we on authentication is waste. So we want to minimize that work as much as possible to direct efforts to areas that we can beat our competitors at and gain more profit.

So it likely makes sense for us to buy an auth platform so that FindMyPast engineers can focus purely on family history and think about authentication as little as possible.

You might be thinking, won’t asking this question always lead you to buy? Well a lot of the time it will. Your company should focus on delivering direct innovation in their respective area and not reinventing the wheel at expense of delivering value.

Sometimes you will ask this question and the answer will truly be to build it ourselves. An excellent example of this is search at FindMyPast. We have our own customer searching setup, something which many SAAS businesses are well established at. However, we asked the question: can we use innovation in this area to beat our competition? The answer is definitely a yes, we have billions of complex records so we have a very unique problem and also the speed of searching and indexing will lead directly to a better customer experience. This proves that asking the question “what is the most profitable option” will not always lead you to buy but in fact lead you to the correct answer.

Still not convinced?

Another reason to buy is documentation! Everyone hates to write documentation but the only thing worse is working with a microservice without any documentation. Buying means you don’t have to write documentation and most SAAS companies put a lot of resources into making their documentation very robust.

Another reason to buy is admin panels. Admin panels are often an afterthought and are not given the same usability consideration as the customer facing application is. For SAAS businesses the admin panel is the customer facing application so they will invest heavily making the admin panels top quality.

In conclusion, when you come to this decision you need to reflect on whether or not building will give you a competitive edge, if it wont spend as little time as possible on it. Spend the time you would have been building on out moving the competition.

Sources:

• Why your estimates are always wrong

• The art of doing twice the work in half the time

• Unicorn Project

• Opportunity Cost