Working in a distributed teams – Gamifying Agile Learning

As much as all Agilists want fully co-located teams, achieving co-location is a challenge for large organizations. especially for organizations that are undergoing transformation. Transformation is typically a 12-18 month journey. During this time, how would the teams deal with distributed teams?

Here’s a game that I came up with, so that teams get a feel of how it feels to work in a distributed environment, what are the challenges that the teams typically face and how can the teams overcome them.

The most common scenario in the context of the IT industry in India is that the Development team is located in India, as offshore development center, and most often, Product Management, and specifically the Product owner works out of an office outside India, and, closer to the client.

Here is the how the game is designed.

The team that is playing this game identifies a temporary product owner(for the game, only) PO is shown a random picture. PO then needs to describe the picture to the team, and the team will have to sketch the picture. In the entire process, the team and the PO stand with their backs to each other.

In another case, I tried this game with “Knotting a Tie” as well. The PO was shown a particular way of knotting a tie and asked to explain to the team, with his back to the team. The team will have to understand the knot and produce as many knotted ties as possible, knotted exactly the way it was explained/shown to the PO.

At one point, the situation becomes very tense and un-restful, especially, when the teams and the PO don’t talk the same language. It is then, that teams learn. Teams learn how to behave, how to talk(from each other’s perspective), how to manage work within the boundaries of restrictions, and learn to innovate.

I hope you are able to try this out in your teams and derive some value out of this

Feel free to share your thoughts

Prioritization for beginners

Some of my biggest challenges were faced when I tried to teach a team how and why prioritization is to be done.  Teams that were used to committing to all features for a given release (and not MMF/MVP for a sprint), found it difficult to prioritize.

Here is one activity that I used to help them understand why they need to prioritize, and how they should look at prioritizing.

I got some inspiration from the Biblical Noah. In case you are not aware of what Noah’s Ark is, you might want to look it up here

So, here’s what I tell my teams – Imagine you had to be on ship for an undefined amount of time. You are allowed to carry 5 items (distinct items, not items of 5 categories), what would it be. One question I get back from them is weather there would be mass or weight restriction, on the  item that is being carried. So I reply that(at least theoretically) there is no such limit for the sake of the exercise.

Teams then get to the job of identifying the top-5 items. Some teams, as I have seen, have really strong discussions around what to be carried, and what not. Few teams conclude very quickly and with less discussions. Maybe this reflects how much each of the members have in common.

Obviously, you have food, water, clothing, accessories to carry, and 5 is a very aggressive limit. So, team gets into the mode of discussing what is really important for their survival. Teams that start with “Shaving Cream” as the priority, often end up putting it at the very bottom. Another thing that usually comes out during these discussions are some long term alternatives for an item that helps in short term. For example – Carrying a water purifier v/s carrying water itself

So, when teams are done with the exercise, I ask them to share their conversations that led to selecting the top-5, and the debates they had around them.

These are the kind of discussions that teams should be having during Sprint planning and Backlog Grooming Sessions. Teams should be talking about what is it that product cannot go live without, are there alternative(and at times, sustainable and easier) options that the team can explore

Estimation for Beginners

Gamification of Scrum and Agile activities is something that is seeing huge success.

In the same lines, I have been trying to teach Agile way of working through games and activities. This is a chance I took, at helping my teams understand “Relative Estimation” through a simple activity.

For teams that are used to estimating in hours and days, the term “Relative Estimation” seems near un-perceivable. The challenge was not only to make them understand what Relative estimation meant, but also to help them with sizing things based on the concept of Relative Estimation

So, here’s what I usually do –

I list out the planets of the solar system, and ask teams to arrange them in the order of size. Yes, I know you are thinking this is easy, and more importantly, how is this got to do anything with Relative estimation. Well, unless you are a 5th grader(or one who has a great IQ), you will find it difficult to accurately arrange it.

Yes, we all know what the smallest and the largest planets are, but, teams mostly mess up in the middle. What teams mostly end up doing is – Relative estimation.

Teams mostly start with Pluto as the smallest, and Jupiter as the largest. Most teams get Mercury, Venus, Earth and Mars right. But, when it comes to Saturn, Uranus and Neptune, teams are a little confused.

After the exercise, when I ask the teams what went through their minds while arranging the planets, this is what I mostly get to I hear –

We THINK Saturn is the second largest. We Know Mars is bigger than Earth. , so, we had to place Uranus and Neptune in between Mars and Saturn.

This is exactly what I then tell the teams. Identify the smallest and the largest User stories/Epics in order of complexity. Pick up a few more, and see if you can fit them in the same order. Teams can choose to have as many buckets as they want, however, its important to have lesser number of buckets, so that teams do not end up with over-analysis

So, while identifying the Relative size of any user story or Epic, you can use the following factors as a indicative to Rank it – Complexity , Uncertainty and the Magnitude of work

The slides that I use are shared on Slideshare