The past months, I’ve been doing several scrum trainings. In our scrum crash course, we always do a theory part in the morning and a practical scrum game with lego in the afternoon, the game introduced by Alexey Krivitsky. I’ve done the lego game in 2 countries lately: Holland and India. And apart from the fun this game brings, it also shows cultural differences in implementing scrum. Here’re some general observations from my standpoint as a trainer.
1. Indians Love ‘Play’
In Amsterdam, when we did the lego game, we had some people looking at us as if we’re nuts. We had someone who didn’t even want to go on a photo with lego on the background. Imagine people see us serious business guys play lego! :). Well, being Dutch myself, I understand this. In Cochin last Saturday, they all embraced the lego game and everyone got on photos without objections.
I think this also has to do with the way people organize.
There’s no real private business life distinction. In Holland, there’s much more of a paradox in the two. I can also see this in office life at Bridge. People play Carrom during lunch (really tough, I lost!). They come to the office early and stay after office hours to play badminton. They do mime acts during company get-togethers. Of course, many Dutch do games too, but it’s just less a central part of office life (and it has to be PLANNED!).
2. Hierarchy forms a challenge
I believe power distance is a big influencer of the adoption of scrum and agile in organizations. The more people are used to having ‘bosses’ who give them ‘orders’, the bigger the change required to ‘do’ scrum. In the discussions we had during the training last Saturday, some people mentioned things like ‘assign tasks’ and ‘manage work’. In scrum, teams manage themselves. So there’s no real assigning of tasks (at least not in the perspective of a manager assigning to a subordinate). And management is almost a dirty word as everything is about self-organization.
People in roles like team lead or project manager, who need to act as scrum masters or product owners, tend to fall back on command and control. And if we get bosses in a scrum team, the whole spirit of scrum is lost and we risk going back to the old way of organizing software development.
Also in Holland, there were ‘bosses’ standing up in the lego game we did. This happens naturally in many groups, some people tend to just take the leadership position and start organizing the work. If that happens, a big part of the group will take a more passive role. It’s important to be aware of this and encourage equality and active participation by the whole scrum team.
3. Clarification Of Requirements
This was the biggest difference I observed and also the one derailing the process. In the lego game, we have a prioritized backlog made by the product owner (the trainer). The goal is to build a lego city. We have some 20-30 minutes of pre-game process planning, backlog grooming and then estimation. This was what we as trainers also communicated. In Amsterdam, people immediately got to work questioning the product owner. The user stories were very short (e.g. 1-storey building, bridge, hospital). People understood that in order to estimate the user stories, they needed more information (e.g., what color, do you want a door). During estimation, they also kept asking questions.
In India, even while I repeated the importance of understanding the stories to make an estimate, there were almost no questions. Some team members even started describing to the product owner what they would build for her. And they then took a couple of user stories and started building.
Result: In Amsterdam, the first sprint amazed us and a lot of stories got accepted by the PO. In India, almost all teams failed to produce something in the first sprint (which is normal according to the lego4scrum instructions).
Now both approaches have pros and cons. The Dutch spend a lot of time in planning what they’re going to do and then build stuff that fits what the PO had in mind. The Indians got to work right away, they have a bias towards action. They also showed a lot of creativity (the buildings we got were really amazing sometimes, even going beyond lego). The downside of this is that it’s hard to estimate how long something’s going to take. It also leads teams to built things that are not what the PO had in mind. This causes the first sprint to fail. Fortunately, in the game, there was quick learning and the second and third iterations went much better. In both countries, the teams managed to deliver the complete backlog and we got amazing cities!
Read Next >> Scrum Crash Course Training – Amsterdam