Category Archives: Agile


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


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.

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!


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!

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.


How to find a vision for your team


What is a team vision

A vision is a long term goal – a declaration of the team’s future.

During one of the last retrospectives in our team I was quite excited about the possibility to form a team vision.

Basically a well formulated sentence which would then be hung up in our team room – visible for all internals and externals to drop by.

Why is it important

The team vision should serve as common ground for our day to day work, help with decisions to make and also differ us from other teams respective their doings and paths to follow.

So far to my optimistic theory.

How does it work

The method I tried to apply to form a team vision was like this: In the beginning, the whole team was asked to answer the question:

Why is a team vision important for us?

That should serve for some basic common ideas and get everyone to speed up for the next part.
It worked pretty well and the team came up rapidly with statements like ‘Motivation’, ‘Focus’, ‘Group Identity’, ’Solidarity’, ‘code of behaviour’.

In the next part, the team was asked to form a team vision statement – a statement in which they believe and which they support and also vice versa.
It should follow this pattern:

For (target organization)
Who (statement of the need or opportunity)
The (team name) is a (team classification, category)
That (team singularity, compelling reason for the team existence).

Unlike (current alternative without the team)
Our team (statement of primary differentation).


This turned out to be much harder than expected and I tell you why:

Not that the team did not believe in their strengths and abilities – much more the fact that it was nearly impossible to look at the company’s vision and extract a meaningful vision statement for the team blocked all from coming up with something round and smooth.

The team was forced to come up with something to fit in this predefined pattern – a template that was just not the correct one to apply.
Before things got more and more complicated and artificial we decided to not make up something that is not suitable for the team and – in the end even worse – makes them uncomfortable when talking about it.

As you can imagine, this felt quite like a failed approach for me as Scrum Master of the team. However, having let this experience sinked in for a while, it was the correct consequence chosen by the team.

What if something had been published that would serve as a burden rather than something motivational for everyone?
The team gets along as a team quite well – each one supports the others when stuck, we have some rituals and some truly common ground we base our work on.
The vision remains unspoken for now – still it is felt day to day when working in the team. Maybe it needs just some more time before a vision itself is “ready to release” – and therefore visual for everyone.

Why did it fail

What I learned from this experience is that trying to push something like a team vision (statement) is not easy at all.
The reason behind it needs to be explained very well and detailed first. And even then you have to nail the critical slot for the right timing.
This means that – instead of pushing something adHoc – it can be easily released during a coffee talk or team event just at the right point of time – and then feel right.
When the time is right. Stay patient. Inspect and adapt 😉

Did you like the post? Send me feedback. I would love to hear from you!