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!

An Easy Way to Measure Method Calls in a Java resp. Scala Application

In the following find a description how to measure certain method calls in a Scala application even under production load.

To collect execution times for analysis e.g. for locating performance problems in existing Java™ respectively Scala applications you can use JETM. JETM is a library offering execution measurement. The overhead is little compared to Java™ Virtual Machine Profiling Interface (JVMPI) or Java™ Virtual Machine Tool Interface (JVMTI) and the related profiler extensions. Thus the risk to slow down the application in production environment is also little.

Using the programmatic approach of performance monitoring with HttpConsoleServer and JMX Support.

In maven pom.xml include the dependency


for the core measurement functionality and


for an output in a HttpConsole.  (For version information see e.g.

Within a Singleton create a nested monitor ( ” true ” parameter) with default ExecutionTimer  and Aggregator by
Start an EtmMonitor with
val etmMonitor = EtmManager.getEtmMonitor

Start an HttpConsoleServer with
val server: HttpConsoleServer = new HttpConsoleServer(etmMonitor)

Config.JETMMonitoring.port: the port is configurable by using 


for further information see

Register an MBean for JMX Support:
val mbeanServer: MBeanServer = ManagementFactory.getPlatformMBeanServer

if (mbeanServer != null) {

  val objectName = new ObjectName("etm:service=PerformanceMonitor")
  // register EtmMonitor using EtmMonitorMBean
  try {
    mbeanServer.registerMBean(new EtmMonitorMBean(etmMonitor, "com.holidaycheck.mpg"), objectName)
  } catch ...

Keep in mind that you have to take care of stopping the measuring e.g. on shutdown hook.

Mix in the measure call by a trait e.g. named JETM that owns a reference to the monitor ( private val monitor = EtmManager.getEtmMonitor() ):

def measure[T](name: String)(op: => T): T = {
  if (!JETM.monitor.isCollecting()) return op

  val point = JETM.monitor.createPoint(jetmPrefix + name)
  try {
  } finally {

(jetmPrefix is the canonical name of the class that mixes in the trait).

Within the class e.g. OfferMetaDataMap that contains the call to be measured use

class OfferMetaDataMap(...) extends ... with JETM {

  def aMethodCallToMeasure = {

    measure("Get") {
      /** basic method body */


“Get” is the flag of the measured method. In HttpConsole this will occur like

| Measurement Point | # | Average | Min | Max | Total |
| com.holidaycheck.mpg.service.actors.cache.OfferMetaDataMap#Get | 4 | 3.556 | 1.029 | 6.075 | 14.224 |

The measured data is accessible via JMX or via http://[application’s url]:[configuredPort]/index.


For further information see

for instance about persistent aggregation see

Continuous Improvement

Continuous Improvement Culture in HolidayCheck

In this blog post we will explain how HolidayCheck is creating a continuous improvement culture across our IT and Product Development departments.

A lot of companies talk about this topic but few of them actually share it with the rest of the world. This is where HolidayCheck wants to be different. We want to share our experiences with all of you in order to help you to get better on your Agile Implementation. So lets start from the beginning.

Some months ago I had the opportunity to be a beta reader of a fantastic book called: “Lean Change Management” written by Jason Little. This book is about Agile Change management in our companies and how can we create change in our companies in a very effective way. Highly recommendable.

In HolidayCheck we are trying one of Jason´s tools. This tool is called Experiment Board. Jason´s explanation for this term is simple; he feels the word “change” can be quite disruptive, so he calls it “experiment”.

Another reason for naming it like this its related with the fact that if you call changes, experiments you are developing an approach that accepts the fact that you cannot know everything upfront. Which is what usually happens in our companies.

The first step in order to use this tool is to create a hypothesis, after all, experiments start with a hypothesis. The hypothesis is an idea of something that we want to improve in HolidayCheck.

To help with this task (Hypothesis creation) Jason created a template:

We hypothesize by <implementing this change>

We will <solve this problem>

Which will have <these benefits>

as measured by <this measurement>

So mapping it now to HolidayCheck we can have something like this:

We hypothesize by “Fixing the team server instability

We will “Never fail a sprint because of team Server problems

Which will “Allow us to release new features every sprint

As measured by “The number of successful releases over the next 10 sprints

There are several ways to successful tackle a Hypothesis. These “ways” are called “options”. The next step is to brainstorm several different possible options that will allow us to solve the problem stated in our hypothesis.

Each option has a value and a cost associated to it, so the trick is to select the options with the biggest amount of value and with the smallest required effort/cost.

The selected options will be the ones that we will be implement in the near future. In HolidayCheck we define weekly options. This will allow us to get fast feedback about what we are doing.

With the pre selected options at our hand we can then chose what are the options that we want to implement during the next week.

When we are done with the option we must review what was achieved, we must see if our option caused the desired outcome. If this is the case then we are done and we succeed with our experiment. If not, we can create a new option with what we learnt.

In order to implement this process, we created a Kanban board to track all the changes that we are trying out in our company. Every week we come together and discuss with eachother what we did learn with this experiments and how these experiments are actually improving our company.

Continuous Improvement

At this point we are trying this approach with the Scrum Masters but the plan is to expand to the rest of the organization. I believe this is a fantastic way to improve companies.

Every Scrum Master has completely freedom to create hypothesis, generate different options and drive the whole improvement experiment.

My vision as Agile Coach is to create an environment where these boards are spread in different parts of the company and everyone in the whole company can pick up different topics to improve.

Can you imagine a company that provides a framework for every single employee to implement daily improvements allowing him or her to create a culture of continuous improvement?

I can, this company is called HolidayCheck.

I am an Agile Coach in HolidayCheck, and I am preparing something great for you: “Agile Retrospectives Program” this program will help you to become better and better on your continuous improvement effort.