All posts by rblessing

How we do Agile Intro Workshops at HolidayCheck

legopic1

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.

legopic4

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.

legopic3

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

How to find a vision for your team

vision_road

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).

vision_statement_template

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!