Pages

16 October 2015

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!

18 August 2015

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:

Printed out user stories as cards. I call them the pile.

Everyone stands next to one preferably long table.

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.

Each person on the team takes a turn to do one of the following

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)

Take one card that is already on the table and move it on the table. (Override)

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.

Team members take turn following the instructions above until there is no card to place on the table.

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.

18 June 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.

17 June 2015

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.

9 June 2015

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.

27 May 2015

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

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!

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

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

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.

After 10 minutes, ask team members to switch partners and find new ones. A new date, a new topic!

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.

5 May 2015

Have you ever tried to make sure that your team is completely aware of what the Scrum Master's role is about. Are you looking to educate your team members through playing a game on that? You are in the right place, once I played a game with my team to go over Scrum Master duties. There was good discussion going on and most of all we had fun playing the game.

What was the game you are asking? The game was me reading out statements and asking Team members to shout if they are True or False. I am calling it the "Scrum Master is Responsible for" game. After asking each question, if there was disagreement between team members regarding the answer, I would let them to discuss and challenge each other and at the end it was my duty to jump in and make sure everyone understood the topic correctly and the right answer for it.

Game: "Scrum Master is Responsible for v1.0"

These are the questions to consider for "Scrum Master is Responsible for?":

Scrum Master is responsible for successful delivery at the end of each Sprint.

Team is responsible

Scrum Master is responsible for preparing for the demo and presenting it.

Ideal demo is the one that stakeholders can do it themselves.

Scrum Master is responsible for removing impediments.

Scrum Master is responsible for facilitating the scrum events. The events include but not limited to the followings:

11 February 2015

Are you hearing that? Everyone is going Agile? Do you want to get on-board fast? This is a really quick guide for you to follow and figure it out. Obviously it lacks so many things in it. It might not even touch the basics. However, if you claimed you know Agile and you don't, this is the best cheat sheet you can find out on the net.

9 February 2015

Looking for real life interview questions for a Java Developer? These are the ones from the one I have conducted recently. The length of the interview was limited to an hour.

B = Beginner
I = Intermediate
A = AdvancedIntroduction
-Introducing him and what he has done + his experience

Technical questions:

OOP related questions
1-What are the OOP's main characteristic? (B)
1b-how do you support polymorphism in Java? (B)
1c-When do you use inheritance in Java (instead of using an interface)? (I)

JAVA related questions
2-What is Overriding and Overloading?
2b-and when do you recommend to use each?
3-What is a thread? (B)
3b-How would you create a thread in Java (3 ways you can do that) (I)
3c-Which one do you prefer to use for creating a thread (A)
4-What is the difference between a synchronized method and a synchronized block (A)
4b-which one do you suggest to use and why? (A)
5-What is an Iterator ? (I)
6-What is hashCode() and equals() methods ? (I)
6b-When do you override these functions and why?
7-Describe a particular shortcoming in Java you've encountered? and how did you resolve it? (Any Java Shortcoming?)
8-What is the meaning of Transient keyword and how is it used?

JEE related questions
10-What do you know about JSP?
11-What is a layered architecture?
12-What is MVC? Have you used any framework MVC in your past experience?
12b-Any experience in an MVC architecture? Please give us an example of your work.
13-Talk about different JEE framework you used and tell us their advantages and disadvantages? Which one do you prefer and why?
13b-What are the design patterns used in Spring? (Dependency injection)
13c-Dependency injections implementations? (By Method, By Construct ...)
14-Any experience with EJB? do you know the difference between stateless and stateful EJB?
15-What is SOA? Is it related to OOP?
15b-What is a web service?
15c-Have you experience with SOAP webserice? How about REST? Can they be used interchangeably?
16-What is JMS?
16b-What is the difference between queue and topic?
17-What is the difference between EAR, JAR and WAR file
18-What is a JavaBean?
18b-Difference between JavaBean and EJB?

DB related questions
20``- What is a primary key?
20'-What is FOREIGN KEY?
20- What is normalization?
21-What is E-R model?
22-What is Object Oriented model?
23-DDL and DML, what are they? (I)
24-What is difference between DELETE and TRUNCATE commands?
25-Define Join and explain different type of joins?

Continuous Integration
41-What is a source control? (have you any experience using that)
42-Why do you think we need a sourc control?
43-Maven vs Ant? Any experience?
44-Any experience with test suites? TestNG? JUnit? What are those? Any one you prefer?
45-What is continuous integration? Any experience with Jenkins? Continuous Integration Tools?
46-Experience with Bash? (Linux commands?)

Agile questions
51-What is your experience with Agile?
52-What are the main attributes of the Agile?
53-Can you name some of the methodologies under Agile? (scrum, extreme programming, kanban ...)
54-If something goes wrong in the development process who would you go to first? (the best answer is it depends)
55-Do we have different roles (such as QA, Developer) in an Agile team?

General Questions: (20 minutes)

what will he bring to this job and why this job is suited for him?
Why do you want to work for us?
what is he seeing himself in 5 years?
What are your major strengths?
What are your greatest weaknesses?
Tell me about a time that you failed at something and what you did afterwards.
Describe a time that you works on a team project. What was your relative position? Were you satisfied with your contribution? Could it have been better?
Why did you choose this field of work?
Tell me about a situation in which you had to resolve a conflict / failed.
What do you know about our team?
Do you have any questions for us?
Tell me about a project that you had either at work or school. Describe in detail how you managed it and what was the outcome?

6 January 2015

The answer is really simple. You should be able to do that unless the user-story you want to convert already has sub-tasks under it. You can not convert it to a sub-tasks with sub-tasks underneath.

So check if there is any sub-tasks, and if there is, probably you shouldn't be changing the user-story to a sub-task. The user-story has sub-tasks, meaning that it was not that small. So rethink before deleting the sub-tasks and converting.