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.