A cooking event that resonates your Agile life

It was part of a team building exercise. The company I am working for took the ones interested in to a cooking event. The cooking event was a social occasion, it was a four-hour event in total, divided in two. In the first two hours or so, a professional chef showed us how to cook a pasta and a sauce. He cooked it in front of us and answered all of the questions relevant to the topic.

After just observing him for two hours, we had been asked to form teams and try to make the same pasta. However, this time, the sauce was a new one. We created 4 teams and worked on the pasta. At the end, we made four different pasta sauces, only one of which we have seen been prepared in front of us.

The chef let it to us on how to organize and who to do what. We needed to get the ingredients ourselves from big fridges. We ended up self-organizing into three different groups within our team, one working on the sauce, one on the pasta and one on the stuffing. The people, if they got bored or wanted to try their hands dirty with other parts of the dish, were able to move around and no one was asking why or telling them what to do. We would hover around (shadow) other team members and see what they were doing. We were giving them feedbacks, on what we thought we knew best. From time to time, a team member would consult the chef for his professional opinion. 

We had a limited amount of time. We ended up making pasta per instructions. We filled them with the stuffings and had the sauce on top. The first run was not satisfiable to all team members, but we didn’t have a choice. We were running out of time, so we had to ship the plate to the judges, and that’s what we did. Every one of us was trying to deliver what we thought it was valuable. We tried our best to deliver the closest to what our customer (i.e. chefs that are judging us) wanted. You can see the result below. So many different shapes and so many sizes, all of which showing continuous improvement over time.

The results were in, and we got the best flavour (taste) out of all the teams. Although we were lacking in presentation, we have achieved what we targeted for. We made the most delicious pasta as a self-organizing team. (our dish is the one with the sliced limes in the image below)

While the judges were trying our pasta, some of the team members decided to give it another shot. They improved on their dough making techniques, and they were able to make an even better dough for our pasta.

Have you noticed similar scenario happening in Agile Teams? A self-organizing team that has a leader to lead them on and show their way. To continuously improve on their product and deliver. Although each of us had different backgrounds, we were able to organize, in a trusting environment and improve upon that. We were able to help each other and the most important, we delivered the best taste. Thanks to the great people I had the pleasure to work with.


Estimation, we suck at it; and we should cherish sucking at it!

I was participating at a team meeting. It was an important one, everyone was there. The meeting began with the director's opening speech and then led on with different team managers. Typical of these meetings, and typical of the managers, to talk on and on and of course, we ran out of time. So, the speakers decided to skip some of the topics. They were just discussing the ones that seemed very important.

There seems to be an interesting topic coming up. The speaker decided to address that topic quickly. The were 5 important areas highlighted to be talked about. Let's spend one minute on this topic, the speaker said. He spent one minute on the topic. Then he noticed that he didn't address any of the highlights, so he read the first highlight and estimated to talked about it one minute. He spent 2 minutes talking about the topic (+the highlight) while initially he estimated only a minute. By the end of talking about the first highlight, he was 100% off with his estimation talking about the topic. When he got to the second highlight, it was the same story. I created a table to visualize how much his estimations were off. Consider this estimation was regarding a simple task of discussing the topic, which presumably he prepared for it.

By the end, it took the speaker 7 minutes to go over the whole topic. He estimated the talk would be only 1 minute. There was no one angry about it, why? Didn't the speaker waste 6 minutes of their life? while he promised that he is only taking one? No one was enraged either. Everyone seemed to be enjoying the talk and the results! No one complained and the audience seemed to be satisfied with the talk. No one really cared about the estimates at the end but the outcome! It was adding value to their lives and that was the important part.

We are humans. We are not good as estimations. It is not something new, it is something that we were born and lived with. This might seem like a disadvantage, but it is a characteristic we need to appreciate and cherish. Without the lack of precise estimation, our lives won't be ambiguous, indeterministic and full of surprises. If we were good at estimations, we could have planned for future to our liking, and to some extent even predict the future. I am truly happy that we are not. You should be happy too. So the next time someone complains why we are not good at estimations, tell him to be thankful for it!


Challenge, Estimate or Override (CEO) Game for Effective Estimations

You don't want to spend so much time with your team on estimating user stories, I totally understand that. However, the only way you know to do that is through planning poker.

True, planning poker is a great way of bringing up the conversation for user stories but it's not the most effective way to estimate those. I can assure you that if the originators of Planning Poker idea had more time spending on that, they wouldn't even introduce the concept. Or they will introduce it only as an introductory estimation activity.

What I am going to share with you is what I tried and I believe is really effective. I am calling it "Challenge, Estimate or Override" or for short the CEO game.

Using the CEO game you can reduce the amount of user story estimation activity in fourth or even less. Isn't that the point of being human and suck at estimations? To have less time spent on estimation and more on collaboration?

The rules are as followings:
  1. Printed out user stories as cards. I call them the pile. 
  2. Everyone stands next to one preferably long table. 
  3. The bottom of the table shows the stories that are estimated the smallest, and the top of the table the stories that are estimated the biggest.
  4. Each person on the team takes a turn to do one of the following
    1. Read a card from the pile and estimate it by placing it on the table. The lower the card is placed the smaller it is. (Estimate)
    2. Take one card that is already on the table and move it on the table. (Override)
    3. Take a card and challenge the person who put it on the table on their estimate (Challenge). It is then his/her (the person who is challenged) responsibility to argue on his/her estimate and then correct his/her estimate. 
  5. Team members take turn following the instructions above until there is no card to place on the table.
  6. When there is no card in the pile, team members get one last chance to play the game if they want. 
Note 1*: The play can only use Challenge option once every two turns. This action is most useful when a player doesn't agree with the estimation and he/she doesn't know where exactly it belongs to.

Note 2: You want to ask your team members to stand for the whole exercise. Otherwise, they tend to lean and be passive on passing the pile. Think about it, who could have fun sitting down!

Note 3: At the end of this exercise you can assign Fibonacci numbers to the user stories if you need to. Fibonacci numbers begin with 1 and 2. The next number in the series would be the sum of the two previous numbers: 1,2,3,5,8,13,21,34,55 [3=2+1, 5=3+2, 8=5+3 and so on]

*Note 4: A good alternative to the first rule is the following: Team members can only Challenge or Override twice (not every two turns) so that people can't get carried away (and they pick their battles). (Cheers to Nima Honarmandan)

That's it! Now you have a list of user stories estimated in a fraction of the time you used to play poker. I suggest using a projector if you are using an electronic board, in case team members disagree on the terms of user stories and you want to refer to them. Then, any question regarding a user story can be clarified by discussing it in more details. 

The following pictures show the progress of estimation over the time (45 minutes) to get all the user stories (around 70).

Initial round
Next round
Final round - [I used Fibonacci numbers to quantify complexity]

You can use this method to print out user stories as cards if you are using JIRA.

Update: It seems that JIRA has taken down the page linked line above. You can take a look at the Google cached version here (PDF version embedded below as well).

As an alternative solution, you can use Agile Cards for JIRA plugin and print out the user stories as cards.

Update 2: It seems that I wasn't the first person to think of such a game, duh!. A similar game to what I introduced was introduced by Steve Bockman at 2008 called The Estimation Game.


A wonderful stop in the midst of my journey - Agile Coach Camp Canada 2015

Agile Coach Camp Canada has turned 6 this year. It was held at two location, in the east and west. With the east one, started one week earlier than the west. The ACCCA east was held in Cornwall Ontario. You can find more information about who attended the ACCCA this year on ACCCA website. The format of the conference was an open space format.

ACCCA15 at Nav Centre
To be filled with lots of agile people
You can see the marketplace for the first day. There were all kinds of games to be played at the unconference.

Lots of games!


Quick intro to Scaling Agile with focus on SAFe

Several weeks ago I presented an introductory talk on how to scale agile in an organization, with the focus on SAFe and how the framework works. I am sharing the presentation here. I hope this will be a good intro for those interested in SAFe and how it works.

This presentation can be found on Google Slides.

You can learn more about scaling agile looking into other frameworks too. Some of them are as follows:


Agile is an art and Agile Coach is an artist, be an awesome one!

I was listening to an interview with a well known DJ years ago. The interviewer has asked the DJ what kind of music would he enjoy listening to. The DJ responded that he wouldn't enjoy listening to music anymore. He used to enjoy music before becoming a DJ. Now that he became a DJ, he had to listen to all kind of music and in many genres. He needed to do that to be able to energize the crowd that he was playing music for. He enjoyed the fact that people listening to the music are enjoying it. 

Agile coaches are like DJs. You are trying to bring joy in the team you are coaching. You are doing that by coaching them to be agile and live agile values. Achieving that, you need to know many different techniques and solutions. Not every technique will work for each team. Similar to a good DJ, you have to understand your crowd and find the right music for them, to play for them so that they enjoy it. If you find the right music (i.e. the right technique) for them, not only they will perform in a joyful manner (i.e. in an agile way) but also will enjoy themselves doing that. 
In a similar manner, we can compare chefs and agile coaches.
Please vote this lightning talk for Agile 2015 if you feel it is worth spending three minutes of your time listening to it.


How to engage tight-lipped team members? Or the unspoken secret of Speed Dating in Retrospectives!

In every team, there have always been one or two people that are tight-lipped. It is not easy to get them talking and participating in team discussions. You need to rely on your facilitation skills to get them involved in. The more experienced you are in understanding different personalities and dealing with them, the easier it gets to engage them in team activities.

However, if you just started working with a new team or you are yourself a novice Scrum Master (or a facilitator in general) it might be hard to engage tight-lipped team members; the solution: Speed Dating Retrospective style!

In the following section, I am sharing with you the steps to run a successful Speed Dating Retrospective. Use this as a template and customize it based on your team.

The Topic
  1. I asked everyone to come up with two topics, write them on sticky notes and keep it to themselves.
    • Note: There is no mention of speed dating yet. You can keep it secret until later on and surprise your team!
  2. After everyone was done with their topics, I asked one by one to come to the wall (or whiteboard) and stick the most important topic in their hand on the wall and discuss it. I asked team members if the topic is already on the wall (or something similar to it on the wall) to discard their topic and use the second one. 
    • Note: In rare cases that both topics are on the wall, ask your team members to come up with a third topic. Alternatively you can ask them to choose one of the two topics in spite of being a duplicate. It is up to you to decide based on the topics and the dynamic of the team at that moment.
The Discussion (Speed Dating)

Once everyone has their topic on the wall, it is time to describe the rules. The rules are easy and simple to comprehend (extremely simple if you know the rules of speed dating):
  1. Ask everyone on the team to find a partner; to group teams of two (in case you have an odd number of team members, one team will be three).
  2. Ask team members to discuss their topics with their partner, one on one, as if they are dating. You will give them 10 minutes time, and let them know midway to switch. In the first half of 10 minutes, the first person is talking about his/her topic and why he/she picked it up; second person is listening and giving feedback on the first person's topic. Then ask them to switch roles in the second half.
    • Note: It is up to you to decide how much time is needed for a dating discussion. You can change the 10-minute dating time based on the time you have and the discussions complexity. As a rule of thumb, you want to allocate 1 hour for each week in a sprint.
  3. After 10 minutes, ask team members to switch partners and find new ones. A new date, a new topic!
  4. The speed dating continues until everyone talked to every other person on the team.
You might ask what's the benefit of playing this game? Playing this game gives everyone a chance to talk to every other person in the team in person. People in the smaller group tend to be more relaxed and talk more freely, especially since there is a buzz going on in the room. No one is listening to them other than their partner. You would see them listening and more importantly talking actively. It will mesmerize you how this technique work, just give it a try.

Get them talking by asking them to talk to only one person at a time
Are you in an agile environment? Are you thinking of using this as one of your retrospective technique? If so, the next step after the speed dating round would be to ask your team members to choose two or three of the most important topics and focus on them. Since they have heard every other person and their topic, it will be much easier for them to pick the most important ones. You can use a dot-voting, vote by hands or sticky note voting technique, up to you. Afterwards, you would focus on the most important topics selected. As a team, you then would try to come up with ideas on how to tackle / incorporate them in the next sprint (or iteration). At this point, as a team you need to come up with action items for each topic. Also, make sure that team members volunteer to pick up action items identified. Again, note that how much more the tight-lipped team members are vocalizing. 

This was how I once ran a Speed Dating Retrospective
  • Intro – 5 Minutes
    • Why retrospective?
    • Three Words; everybody sums up the last sprint in 3 words
  • Proud & Sorry – 15 Minutes
    • What are team members proud or sorry about?
  • Group Discussion – 50 Minutes
    • Speed Dating (5 minutes and then switch partner)
    • Action Items; Dot Voting - Start, Stop, Continue
  • Feedback – 5 Minutes
    • Feedback Door