Time as Scrum Master’s poison

I believe that, as Scrum Master, you can’t create a high-performing team in one or two weeks. Let’s imagine that after laborious months of your work a team is stable, aware of its dysfunctions and moving towards self-organization. People know one another, they collaborate well and delivery product frequently. What about you Scrum Master? How would you feel after being part of a team for 12, 18 months?

In this post, I would like to raise an issue which is being part of a team for too long is a poisoning situation for Scrum Master.

Someone could start asking what is the reason for saying this if you still have lots to do as Scrum Master…

Looking at your team…
… there is a still room for a team improvement,
… there is a still way to speed up a product delivery,
… there is a still possibility to raise a technical quality.

This person could be probably right while mentioning those arguments. So why „time factor” sound as a poison for Scrum Master in my opinion? I would like to refer to the theory of System Thinking to help to understand this point of view. Peter M. Senge said:

System Thinking is a discipline of seeing whole

In discussed topic, when you join a team as Scrum Master everything is new for you. You are asking lots of questions, you are trying to understand dependencies (both technical and product-wise) and a relationship between people. Your goal is to gather as much information as you could to have a high-level understanding of a current situation. So what you are aiming to is to create a picture of a whole. You are fresh-minded, not influenced by your work environment, not blinded by anything. All of these help you to propose relevant actions and introduce your agility plan. You strongly believe that it is the proper way. It sounds so exciting, you are stimulated by new surroundings, you have lots of positive attitude in your activities. Wouldn’t it be perfect if such case stayed for a long time?

The reality is that after a few months working with a team, you are becoming part of the system, you would be only „system component”. You are losing an external point of view. You start ignoring obvious things that influence and slow down a team. They could prevent people from a continuous learning. What worse is that you stop developing your skills. It could be very difficult to step out from this situation as you could not be even aware of it. You live in a comfort zone, you are safe inside a team, which is working well but not as much effective as it could be. That’s why I’m saying the longer you stay in the same team the less you support them. In such case “time” is a poison for being Scrum Master.

So how to avoid it? What antidotes Scrum Master should take to recover? I’ll tell you my secret medicines in the next post.

*Image source: Gwendolyn Knapp book’s cover

How we stopped worrying and learned to use Kotlin in our Androd App

Kotlin is a relatively new programming language, becoming more and more popular among Android developers. It is officially defined as Statically typed programming language for the JVM, Android and the browser by its creators, JetBrains – who are also responsible for the Android Studio (and other great IDEs).

Kotlin at HolidayCheck

After the release of Kotlin in stable version, Android team at HolidayCheck decided to finaly give it a go. We’ve implemented a significant feature of Android app (Booking Module) over the course of three months, learned from our mistakes and enjoyed every single moment of the Kotlin experiment. We can safely say it went well and we’re not looking back.

Here are the top 5 reasons why we recommend everyone to try it in their Android apps.

NullPointerException hell is gone

This might not be the most important reason, but it resonates with every Java developer so strongly, that it needed to be put in the first place. Kotlin is type and null safe. If you use it correctly, NPEs will not happen, it is guaranteed by the language. References that might contain null value, must be explicitly marked as nullable – everything else must have value and the compiler makes sure of it. This is built into type system, no Optional<T> needed.

Lambda expressions & collections

Lambda expressions were one of the most imporant additions to Java 8 – it’s finally available for Android so it’s not such a game changer now, but still – Kotlin adds its own lambda support without the need for Java 8 or external libraries for Android.

Lambdas alone can greatly reduce boilerplate code, but their use with collections shows real power in expressiveness and conciseness. Simple mapping and filtering collections is a touch of functional programming that every modern application needs.

Simplified and more powerful syntax

Operator overloading and extension functions greatly improve expressiveness of the code – no static helper classes needed for simple calculations performed on your custom objects. Setting text on your TextView or hiding it when the text is empty – simple as writing one function shared among all TextViews, instead of polluting view code with logic and if statements.

As a matter of fact, if in Kotlin is an expression, so it can return a value. The same applies to when expression, an improved switch operator.

Default function parameters? Check. No semicolons required? Check. String interpolation? Check, check, check.

You don’t need to go all in

Greenfield projects are rare, most of our day-to-day work is all about maintaining software and building features on top of existing codebase. Some projects (even in the worst tech-debt imaginable), cannot be migrated (even into the most promising programming language ever) for the cost of stopping development. We wouldn’t do that either, but fortunately this is not the case. You can migrate old code or write only new one in Kotlin and everything works fine with Java, because the bytecode is JVM-compatible.

Great way to dive into Kotlin development in your Android app is to separate one single Activity in your project and (re)write it in Kotlin. If anything goes wrong, you can always go to Java, even for single, specific classes.

Java Interoperability

Of course the code of your beloved Android app doesn’t exist in vacuum. What about all those Java libraries, that are not (and probably never will be) ported to Kotlin? Fear not, they don’t need to. You can simply cal Java code from Kotlin and vice versa. Thanks to that, Kotlin can be easily adopted in current code, hopefully phasing out Java in the future.

This list is of course not exhaustive, Kotlin has many other features available. In case this doesn’t convince you, here’s a sneak peek of upcoming changes in version 1.1.

Get started right away

This tutorial shows how you can start with Kotlin, migrating single classes one by one. If anything goes wrong, make sure you have the latest Android Studio and Kotlin plugin installed.

Bonus: Anko library

Anko is a DSL for Android, written in Kotlin. It greatly simplifies development, both in terms of code we must write, as well as its complexity, getting rid of many points of interaction with Android SDK and Java quirks. Be aware though – it’s specific to Android and can potentially introduce yet-another level of complexity if you’re just starting out with migration to Kotlin.


Agility insights

I’ve been talking recently lots with people from different companies to understand how they are moving towards agility. Many of them are saying – yes we are fully doing Agile right now. When I’m hearing this “magic” sentence I always ask – please tell me more… tell me what do you mean by “doing Agile”, how it works for you…

So here is a summary of Agile perspective that is evolving inside those companies:

  • Agile equals iterative delivery,
  • Scrum Master is a report manager,
  • Scrum Master is responsible for assigning tasks to developer,
  • Scrum Master acts as project manager,
  • Product Owner assigns stories to sprints,
  • Two roles exists inside a team: Project Manager & Product Owner,
  • Agile ceremonies make company agile,
  • Developer is mostly interested in his tasks,
  • Agile means writing requirement as User Story.

Does it sound familiar to you? Is it one of the companies that you know? Those are typical Agile Anti-patterns in my opinions and in fact most of them are against an agile mindset. Understanding how companies imagine agility helps me realise how much work still need to be done to create the right meaning of it. After fixing it inside your working environment you could start to create a people-oriented organisation based on learnings and transparency.


London Lean Kanban Days – key takeways

There was London Lean Kanban Days conference last week. Thanks to HolidayCheck I had a pleasure to participate in this event. As well as being excited by announced speakers (Pawel Brodzinski, Tobbe Gyllebring, Gitte Klitgaard) I was really looking to meet British Lean community to get a different perspective. In this post, I would like to share with you key takeaways from this conference.

  • Visualize a problem rather solve it – creating an awareness is often enough, then let people fix it – as a coach you don’t have to do everything by your own.
  • Lean = LeaRn – we sometimes forget about the main concept of lean which is continuous learning while focusing on other Lean principles like establishing flow, implementing pull approach or defining value from a customer perspective. Take your time for reflection, analyze what you achieved and learned.
  • Acknowledge yourself – you need to take advantage of the imposter syndrome by things like realizing that your experience is unique, fear indicates growth and keeping pushing your boundaries, improving where you have a passion.
  • Traditional project management is much closer to Agile mindset nowadays. The most needed skill for a project manager is leadership and an organization should aim to be adaptable.
  • Extreme self-organization at the company level is doable – it takes a time, it is not one-day shift and probably part of people will decide to leave your company.
  • While doing a change you need to have someone responsible for delivering value, and facilitating the risk assessment, you need to focus on organizational goals instead of local targets.

Android Runtime Permissions

Android Runtime Permissions

Permissions are used to restrict access to sensitive resources, data and hardware features. Android 6.0 Marshmallow (SDK level 23) introduced the concept of Runtime Permissions, changing many aspects of managing them in Android. The change is aimed to greatly improve user experience and it seems the Android Team did just that. On the other hand, developers need to incorporate those changes into their apps, which might not look that easy at first glance.

Traditional permission model

  • application install requires all of the permissions to be accepted by the user
  • the only way to revoke them is to uninstall application (all or nothing approach)
  • new permissions prevent apps from auto-updating, they need additional review by the user1
  • required permissions are declared in Android Manifest and application can assume, that if it is installed, it has all of them granted

New runtime permission model

Now, every permission falls into one of three protection levels:

  • normal applications get them by default at the time of installation (for instance Internet connectivity)
  • dangerous must be granted explicitly by the user
  • signature custom permissions based on signing certificates that should match in order to request them, typically used by applications by the same developer in order to exchange some private, proprietary data

In addition to protection levels, new concept of permission groups has been introduced:

  • few separate permissions (like we are used to) might be grouped together into one group
  • user implicitly grants us all permissions from the group, that requested permission belongs to
  • if we ask for more than one permission in a group, they are granted/denied automatically based on users decision regarding the group

Dont assume that if you possess a permission from particular group, you also have all the other permissions from that group always ask for specific ones, because current behavior might change in the future.

What all of that means for your users, is they can just install any given app from the Play Store and start using it right away (no questions during installation asked). Permissions falling into normal protection level are granted by default, and those should be enough for typical app to function, at least at the beginning. The process of asking for permissions is pushed back to the last possible moment the moment that user wants to perform an action requiring dangerous permission, for example action of taking a photo would be briefly interrupted by a system dialog with permission request. Finally, user can grant or revoke2 any permission at any time from system settings, without uninstalling app.

App permissions can be fine-tuned separately app by app

When user revokes permissions, our applications process gets killed.

All is fine for the user, but life of an ordinary Android developer has just got slightly more complicated. Were now required to take extra care and prepare for few scenarios, making sure that we:

  • declare required permissions in Android Manifest as usual
  • check on-the-fly, that we are actually granted permissions required to perform given actions
  • disable certain UI controls or indicate in other ways that application could perform those actions, if it had those permissions
  • are prepared for permission revocation at any given time
  • make a clear distinction between permissions vital to your application and optional ones
  • show disclaimers and reasoning behind requests up-front or in context as they are needed

Asking for Runtime Permissions

All features are backported to both Support Library v4 and v13.

1. Opt-in for Runtime Permissions

In order to opt-in for Runtime Permissions, you need to build your application with Target SDK 23 or higher. If youre using Gradle (which you should be doing), make sure its set in build.gradle:

compileSdkVersion 23
targetSdkVersion 23

2. Declare permissions in AndroidManifest

No changes here, declare needed permissions in AndroidManifest.xml as usual:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android=""

    <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/>



3. Make sure to check if permissions have been granted and ask for them if necessary

System window pops up to get user's approval

public class MainActivity extends AppCompatActivity {

    protected void onCreate(Bundle savedInstanceState) {
        if (ActivityCompat.checkSelfPermission(this, Manifest.permission.ACCESS_FINE_LOCATION) != PackageManager.PERMISSION_GRANTED) {
            ActivityCompat.requestPermissions(this, new String[]{ Manifest.permission.ACCESS_FINE_LOCATION }, 123);
        } else {
            Log.d("PLAYGROUND", "Permission was already granted");

    public void onRequestPermissionsResult(int requestCode, String[] permissions, int[] grantResults) {
        if (requestCode == 123) {
            if (grantResults.length > 0 && grantResults[0] == PackageManager.PERMISSION_GRANTED) {
                Log.d("PLAYGROUND", "Permission has been just granted");
            } else {
                Log.d("PLAYGROUND", "Permission has been denied or request cancelled");

As you can see, we use few new methods from Runtime Permissions API. Those are fairly straightforward, but there are few things to note:

  • you can request many permissions, passing an array to ActivityCompat#requestPermissions() method
  • you need to make sure the code is prepared for brief interruption introduced by the request, as well as correctly receive result in onRequestPermissionsResult(), the mechanism is the same as onActivityResult() that you should be already familiar with
  • you can check approval/denial on single permission level notice that response contains requested permissions and separate results for them

You are required to check permissions status every time you might need them, dont assume that you got permission once and its available forever.

Additional considerations

I suppose youve noticed that after first denial user is given the option not to bug them anymore with our request. This is virtually our last chance to explain them reasoning behind the request. In order to do that gracefully, API contains method that returns true, if we previously requested particular permission, but user denied the request:

if (ActivityCompat.shouldShowRequestPermissionRationale(this, Manifest.permission.ACCESS_FINE_LOCATION)) {
	// the request has been denied previously, show explanation why you need this, then request permission again!
} else {
	// ask without explanations

Please note, this method returns false if user already checked Never ask again checkbox.

Asking second time, user can permanently dismiss this dialog for our app

Theres another feature introduced in SDK 23. You can ask for permissions only if the platform supports runtime permissions, so you can optionally provide new features, but dont request new permissions from users on older platforms upon auto-update of existing installed app. All we need is declaration in Android Manifest:

<uses-permission-sdk-23 android:name="android.permission.ACCESS_FINE_LOCATION"/>

This permission would behave as runtime permission and request for it would appear only on Android 6.0 and newer. For users on older platforms, nothing changes.

Few points to keep in mind

  • apps compiled with Target SDK < 23 are treated as usual
  • many basic permissions are granted by default
  • you still need to declare them in the Manifest
  • you must check every time you need them (Activity#onCreate() is sufficient)

Protip: Android Studio parses annotations and warns you if you try to make an API call but dont request needed permissions.

  1. That leads to developers requesting more permissions that they really need, in order to prevent already installed applications from bugging user again when new app features arrive. This is bad practice. ©
  2. This doesnt mean legacy apps are going to crash like crazy after you revoke permissions, throwing Exceptions all over the place. What really happens is, on Android 23+, API calls that had been restricted would return empty data sets or default values, as if there were no data available. ©

Content Freaks & Mob programming adventure

cf-logo-v3In Holidaycheck’s Poznań IT department we work in teams that consist of frontend & backend developers. We pay a lot of attention to knowledge sharing within a team in order to have a common understanding of our architecture and why we’ve chosen one solution over another . For a long time we’ve had well balanced sprints, meaning that we had a few frontend and backend tasks in each sprint. Recently however, due to our business strategy and migration process of our platform, more and more tasks have became frontend focused.

We didn’t want our backend devs to get bored! We wanted to use the potential of the whole team, which meant involving backend devs in frontend tasks. We started looking for solutions that can be helpful in learning new technology stack. One of the things that came to mind was pair programing, which is a great idea for sharing knowledge, but… our scrum master proposed to try MOB programming… We thought: “Why not!? We are an agile team, so why not to try something different and learn !?” 😉

MOB programming in a nutshell, is a scaled up version of Pair programming, with more than two developers. In our case it was four: two frontend and two backend guys. We’ve prepared one of our conference rooms  to be the headquarters of our MOB programming session. We used a big TV as an external monitor – just to feel more comfortable and not to squeeze four people in front of a tiny laptop screen for hours 🙂  Second laptop was used for research, to not disturb the main flow of coding.


We’ve picked one frontend story, which was not very complex, but great for learning the basics. At the beginning of our MOB  session, backend part of our team had a feeling that the story is just a piece of cake … but it wasn’t. Backend guys haven’t had any experience with our current frontend stack and didn’t have a clue about how complex and tricky the story  might be. After we’ve discussed how we would implement the story, we were ready to code! Development process looked a little bit different from pair programming. One of the developers was a “driver”, sat in front of the laptop and owned the keyboard. He was coding what was discussed and agreed on by everyone.   The session revolved around frontend guys suggesting how the story should be done, which was then being discussed by everyone. From time to time, we also had a discussion regarding more general programming ideas like testing approach etc. The MOB session was divided into short iterations  (15-20 min) in which each of us became the driver, which allowed previous driver to focus on research and discussion.

Good parts:

  • sharing knowledge
  • new angle of looking at solutions that we are using on daily basis
  • rise  of team spirit and collaboration
  • backend guys started to like coding on frontend stack

Other observations:

  • the session slowed down the progress of product features in the current sprint, but that was expected and accounted for, as we believe it will enable us to be faster in future
  • frontend guys would love to do a similar session with a backend story 🙂
  • a whole day is too long to develop in that style
  • MOB approach shouldn’t be abused!  🙂

In summary, although we had certain reservations before we started, MOB programming turned out to be a really great experience for us! We think we will be using it   in future, as a mean  of fast learning and knowledge sharing… Maybe frontend guys will learn & love Scala? 🙂   Time will tell… 🙂

Journey to T-Shape team

t-shapeThere is a trend on the IT market to be software developer who has expertise in one specific technology (vertical line in “T”) and knows others at levels that don’t stop him from understanding a full code (horizontal line in “T”). This whole idea seems to help building cross-functional team, one of core thing in Agile world.

Currently the team that I’m working with has decided to try to become T-Shape one. There have been a few discussions how to tackle it, what should be assumptions and how we can manage dependencies. We have used brainstorming session to create a plan that all of us would support. Here is our approach:

  1. Create skill matrix to get knowledge what kind of expertise team has.
  2. Identify skills that should be strengthened.
  3. Verify in which directions team member would like to develop.
  4. Each team member proposes plan of skill’s development with clearly stated goals.
  5. Scrum Master facilitates and challenges progress on skills’ learning plan on monthly basis.

On top of this, the whole team has agreed that during transformation into T-Shape developer we still need to follow principles mentioned as below:

  • Each team member has main focus on core skill/-s.
  • We will plan how to grow individual horizontal skills during sprint planning so we could forecast more accurate sprint deliverable.
  • Each team member is responsible for his/her skill’s development.
  • Each team member seeks actively new ways of skills’ learning.

As you can see the team has decided to move closer to be cross-functional team in structured way, doing it step by step. Such approach gives them a chance to adjust it if needed and to validate their progress (see points 4. & 5.). Additionally it should help minimizing an influence on sprint deliverables. Keep finger crossed!

If you have any experience in creating T-Shape team let me know. I’m curious to find out how you have transitioned to it and I’m open for your advice!


Marathon Maven plugin from HolidayCheck

At HolidayCheck we are using both Docker and Apache Mesos with Mesosphere’s Marathon. Therefore for our development teams creating services using Maven we wanted to set up easy to use configurations bound to standard Maven lifecycle phases.

Starting with Docker Maven plugin

As wiring a Java/Scala project for Docker is possible by multiple existing plugins, we have chosen Spotify’s Docker Maven plugin, as it best suited our needs, was easy to integrate and allowed to use Git commit hashes (aside from standard artifact versions) in Docker image names for uniqueness.

Marathon Maven plugin usage example

You can have a look at the plugin on the GitHub:
or even start using it already in your project:


To interact with Marathon the plugin uses Marathon Java API client. In the processConfig goal the plugin takes marathon.json file currently located by default in root project directory, which might
look like the one here:

  "id": "/my-service-1",
  "container": {
    "type": "DOCKER",
    "docker": {
      "image": "",
      "network": "BRIDGE",
      "portMappings": [
        {"containerPort": 7070},
        {"containerPort": 7071}
  "env": {
    "PATH_PREFIX": "/my-service",
    "_JAVA_OPTIONS": "-Xms64m -Xmx128m -XX:MaxPermSize=64m"
  "instances": 1,
  "cpus": 0.5,
  "mem": 256,
  "healthChecks": [
      "protocol": "HTTP",
      "portIndex": 0,
      "path": "/my-service/v1.0/healthcheck",
      "gracePeriodSeconds": 3,
      "intervalSeconds": 10,
      "timeoutSeconds": 10,
      "maxConsecutiveFailures": 5

replaces container/docker/image with the value provided to the plugin and evaluated taking into account all used variables e.g.:
The result is put into project’s target directory by default. Then it’s being picked up by the deploy goal and submitted to Marathon’s API endpoint with some minor handling of a situation whether the app already exists or not in the cluster.

Docker and Marathon plugins join forces

As mentioned earlier the Marathon plugin goes well with the Docker plugin, mostly due to the fact that we might bind those two plugins together and hook them nicely to proper Maven lifecycle phases and (what is very important in our scenario) to use Git commit hash as the Docker image name detected previously by the Docker plugin to be used in Marathon plugin’ configuration:

                <cmd>java -jar /${}.jar</cmd>

Now simply type:

mvn clean deploy

and you should have it deployed and running on your target environment.

Have a good time using Marathon Maven plugin! If you are willing to contribute your pull requests are welcome.

HolidayCheck craftsmen at SoCraTes Tenerife

Last week our developers Jan-Simon Wurst, Tobias Pflug, Alexander Schmidt, Robert Jacob, Robert Mißbach and Roberto Bez went to the SoCraTes Conference on Tenerife. Of course that is kind of an unusual place for a conference, but exactly that makes the difference. Beeng somewhere isolated, like in a lonely hotel near the beach, gave us a very relaxed and comfortable feeling while talking with other great people about software craftmenship and a lot of other interesting topics.

The Venue: Tenerife

After a very windy landing on Tenerife, we went to our venue, the lovely Hotel Aguamarina Golf, located not to far away from the airport. It gave us enough space for all the sessions we needed, as for example next to the pool or on the terrace.

The Hotel Aguamarina Golf

What is the craftsmanship conference about?

SoCraTes Canaries in fact is a Craftmanship retreat for open-minded craftspeople who strive to improve their craft and the software industry as a whole, organised by the local Software Cratfsmanship comunity in the Canary Island.


It is a totally community-focused Open Space, without a predefined agenda and without any speakers known before the event starts. Proposals were presented during the event itself in the morning:

Session planing in the morning

After the proposals were presented, we had five different locations (like classic rooms with projectors, but also near the pool or on the terrace, while enjoying a great view of the atlantic sea).


Discussion about costs of CI and CD


Talks & Discussions

Just to name some topics we discussed:

Jan-Simon Wurst proposed a discussion about Git Flow vs. trunk based development, trying to find out how other developer teams work and which might be the better solution. But as always – there is no perfect way, but a lot of right ones!

Robert Jacob showed us HolidayChecks continuous deployment pipeline with Mesos and Docker, facing a lot of interesting questions about that hyping topic.

Tobias Pflug let us had a deeper insight into his vim-skills, presenting some of his favorite plugins. Very cool stuff!

Roberto Bez initiated a discussion about distributed teams by sharing his experience about that and with a lot of interest in how other companies are currently facing with not co-located teams. For some it might work, for others it does not – but one outcome was clear: It is not always easy!

With two days full of interesting discussions, in the evening there was the time to enjoy a beer together as well.

To sum up, we went back home with a lot of new motivation, which we can hopefully use to become better craftsmen in our daily work!

A special thanks to Carlos Blé and all the other organizers for the great conference. We are already looking forward to visit you again in 2016!

How we do Agile Intro Workshops at HolidayCheck


Why do we do Agile Intro Workshops

When you are situated in a web driven company with more than 200 employees in one location – plus
dozens on top in distributed offices – the need for a common basic understanding of agile product
development is at hand.
Our product development consists of +/- 8 teams – all contributing to different parts of the web platform
plus native mobile apps.
So we experience communication and alignments that go far beyond the dedicated product dev teams only – basically all departments have a smaller or bigger stake in the agile teams.
That leads us to the need to have a basic common understanding of Agile and how we live it at HolidayCheck.

For whom do we do them

The target groups are always totally mixed and come from different departments – this way we ensure that people come together and form a completely new virtual team during the workshop. After the workshops they are again released to their native teams and their well known area – able to bring in and spread the learnings immediately.

How do we do them

We set a timebox to 90mins and have a theoretical part and a practical part – a simulated sprint with the goal to build something that is ready to use in very few minutes.

The theoretical part covers basic knowledge about Agile, Scrum and Kanban:

  • The need for Agile product development
  • The roles and artifacts
  • The specific team constellation here at HolidayCheck
  • Agile Tools we use at HolidayCheck

And now comes the fun part! We use LEGO bricks to simulate a sprint with the goal to build a house, a garden and a car.
After about 45mins the audience is asked to form 1-2 agile teams themselves to do that – they are given roles they need to fulfill the best they can – even if their real role is completely different (believe me, software developers always want to build stuff instead of just telling where the team should head at).
Roles we use are Product Owner, Developers, UX Designer, Test Engineer.


The Scrum Master role is filled by us as the moderators themselves. Also if the teams are rather small, with +/- 4 people, we only use Product Owner and Developers to keep it more simple and going forward.
We use small time boxes to simulate

  • A sprint planning session (2mins)
  • The sprint itself (5mins)
  • A sprint review (2mins)
  • A sprint retrospective (1min)
  • legopic2

The teams apply the given info instantly and also try to prioritise and deal with the limited time.
This gives them a feeling of how real teams have to focus and organise themselves.
Many people think that building a house with LEGO bricks with a whole team is super easy in 5mins – trust me: experience shows that many struggle to finish in time, while others do really great.


What do you think? Please comment and tell us your experiences!