Sif E. Elharti's Blog

Even small acts can have a great impact…

Posts Tagged ‘Scrum

Planning Poker Game

leave a comment »

One Agile hidden principle is to shift hard, annoying, and unpleasant work to amusing game. Thus, whether is it for teaching, practicing or using Agile, playing games (also called Serious Games) is widely used to simplify these activities and make them more attractive and fanny.

Are you serious? How can you be productive while playing?

A straightforward answer is that you are more productive when you like what you are doing and when you are forced to do some task your productivity goes down. Agile professionals understand that very well and try to use it as much as possible in practice. To mention only some games that are used, we have :

  • The marshmallow challenge to teach elementary concepts for successful project;
  • The Business Value Game to practice customers and features selection techniques;
  • The Planning Poker that teams use as a technique (or game) for voting, for estimating, and for leveling feature’s or task’s understanding.

If you have ever played Poker, you would have notice that participants play in rounds using cards distributed to them. For the Planning Poker, we will keep only these two elements. -I am not qualified to show you how to play and win real poker game. But if you insist on me to do so, be sure to end up washing dishes in the casino :(-

Let take an easy example to practice this game. Suppose you, me and three other organizers are preparing a party for the next Sunday and we want to estimate how many people will show up this day. -It happens that while writing this, the next Sunday coincides with Valentine’s Day !-

To answer the estimation question, let’s do the following:

  1. Four from us (organizers) will participate and one will be a moderator
  2. We write down on cards, with the same size and color, values like: 5, 10, 15, 20, 25, 30, 35, 40, 45 and 50 (we suppose the number will not exceed 50). We make 4 copies of this deck one for each player.
  3. The moderator will ask the question: “how many people will attend?”
  4. The moderator will ask players to play a round by selecting a card form their deck without showing it to the others
  5. The moderator will ask players to show their cards to everybody at the same time
  6. If the values are equal, no need to go further. The game ends and the estimation is set to the common value.
  7. If the values are different (which is in general the case for the first rounds), two people with the highest and lowest values will explain why they choose their values. The moderator must keep an eye on the running time so that explanations do not exceed few minutes.
  8. The moderator will ask players to play another round as in step 4 and we continue looping until we all agree on some reasonable value for the estimation.

Wait here! if some players stick to their selected different values, this can go forever!

  1. If we don’t agree on a common value after some rounds (2 or 3 ) we can apply 1 of these 2 possibilities:
    1. Take the mean of the values as estimation, or
    2. Take the most common value (majority)

Let’s play:

Player

Round

Organizer 1 Organizer 2 Organizer 3 Organizer 4
1

 

Explanation

15

20 35

40

Talk first: Valentine’s Day, people will prefer to spend it with their beloveds. Talk after: 2 months ago, we had around 40, but I forgot about the Valentine’s Day!
2

 

Explanation

25

25

35

35

Talk after: I took in account Organizer 4 comments but I did not add that much since the proposed music is different and especially adapted to Valentine’s Day. Yet, I forgot about the bad weather! Talk first: Most people cannot travel because of the announced bad weather.
3

30

30

30

30

 

In fact, this leads us to estimate the number of attendees but more important if generates all the discussions around that helps us to have a better understanding of the party conditions.

For the planning Poker, we use a deck of cards a little bit different from the one used for our party. We prefer a nonlinear reparation of the values in order to magnify the differences.

These values are inspired for a well-known Fibonacci’s sequence defined using this formula: Un+2 = Un+1 +Un. First elements are: 0, 1, 2, 3, 5, 8, 13, 21, 34….

For our Planning Poker game, we can use this sequence for example:

0 1 2 3 5 8 20 40

The selected values after 5 or 8 might vary depending on author or team. Some teams add cards with values as ½, 100 or infinity and card with “?” mark. This is to allow half value of the metric unit, to reflect a huge amount as a value or to request more explanation about what is under estimation.

PlanningPokerCards

Planning Poker Cards

Two last points regarding Planning Poker:

  • The metric unit used is defined and agreed between participants and must stay still for the whole project,
  • Using Person-Day to estimate a task duration for example might not be a good choice since it depends on the developer working on it; thus we suggest using the following technique:
    • Between all the items to estimate, select a small (but not too small ) one that everyone understand very well and set it as reference,
    • When voting, every participant gives an estimation by comparing the item being estimated to the reference one. So one might vote the card “2” to indicate that, for him, the estimation for this item is 2 times the estimation for the reference item.

Have fun … 🙂

I hope this helps,

Sif E. El Harti

Written by selharti

February 12, 2016 at 7:19 am

Agile hidden mindset

leave a comment »

No need to convince you about the benefits of Agile methods and how they can help you build the software that your customer really needs in incremental and iterative way. mindYou can easily find a lot about this subject everywhere. In this paper, we will focus on some principles unmentioned openly in Agile Manifesto. This thought came to us from real failed and successful experiences about Agile implementations.

Values and principles, defined in Agile Manifesto, are not only some rules to follow in order to have the label: ‘We are Agile!’. We have a deep conviction that behind the scene there is a fundamental consideration for person as a human being. Indeed, the central actors for any organization are the people behind it. Thus, in order to be productive and to keep being productive for a long time, there is a real need to take care of the building blocks of your organization. You will agree, for sure, that foundations have to be considered first.

Therefore, here is a first draft about some principles we think are necessary to comply with Agile hidden mindset. We noticed that when some of them are missing, this leads to Agile implementation failure. We propose these principles under three sets: “as a person”, “as a team” and “as an organization” and we give no explanations in order to keep it open to your interpretations.

As a person

  1. I have fun while working
  2. I respect my life (personal one)
  3. I respect my customers and coworkers
  4. I learn that learning has no ends and I learn that I can learn from everything
  5. I wish for the others what I wish for yourself
  6. I’m brave
  7. I’m honest
  8. I believe in myself
  9. I challenge myself
  10. I keep in mind that I’m professional and that I have to act as a professional
  11. I never underestimate the others
  12. I regularly think about these questions: how am I doing? How can I become better?

As a team

  1. We talk the same language (exp.: be sure to share the some definitions)
  2. We are all for one and everyone for all
  3. We know that : 1 mind plus 1 mind gives 3 minds
  4. We interact positively
  5. We share: knowledge, ownership, responsibility
  6. We make team decisions
  7. We agree on objectives
  8. We challenge our team
  9. We believe in our team
  10. We are suggestive rather than directive
  11. We accept differences
  12. We regularly think about these questions: how are we doing? How can we become better?

As an organization

  1. We trust our employees
  2. We enhance belonging to the organization
  3. We respect your employees
  4. We share success, and we share failures also (with moderation)
  5. We share the same vision
  6. We regularly think about these questions: how is our organization doing? How can our organization become better?

Et Voilà!

For sure, as usual, your comments and suggestions are welcome.

Sif E. El Harti


 

Even small acts can have a great impact.

Written by selharti

February 8, 2016 at 12:56 pm

Premier séminaire Agile Maroc

leave a comment »

Agile Maroc et l’École Mohammadia d’Ingénieurs organisent le 24 novembre à l’EMI – Rabat – Maroc le Premier séminaire Agile Maroc. Je suis fier de participer à l’organisation et l’animation de cette première rencontre qui j’espère, sera à la hauteur des attentes de nos invités. Merci à toutes les personnes qui se sont inscrites et à  toutes celles qui œuvrent pour la réussite de cet événement.

Ceci m’a donné l’occasion de faire la connaissance et de mieux connaitre des personnes formidables, très dynamiques et pleines de bonne volonté.

Id Moubarak pour tout le monde

Cordialement,

Sif E. Elharti

Même les petits actes peuvent avoir un grand impact.

Written by selharti

November 17, 2010 at 10:05 am

Agile main best practices – with Ron and Chet –

leave a comment »

I had a great occasion to attend a conference animated by Ron Jeffries and Chet Hendrickson, and organized by Agile Quebec. Ron is one of the authors of the Agile Manifesto and Chet is one of the first signatories of the manifesto. Both of them have a huge experience with software development and agile adoption.  It was not hard for me, and I believe for anyone in audience, to figure the confidence and the large mastering they have about agile practices.

After a short introduction about the main reason for adopting an agile approach versus a classical one, specifically early delivery in incremental way, they focused on the best practices to ensure a successful project.

Key points are (but not limited to) the following:

First of all: Testing. This is not something to be done will the customer is using your product. It’s done during all the project life time. There must be, at least, two kinds of tests: Unit tests at any piece of code level and Acceptance test at product level. Ron and Chat went further and suggested that the Acceptance test must be available before any code is written for given feature.

Second: Refactoring. This is to handle the design challenge. Since the team is working with a short visibility about the upcoming features, they have to adapt their architectural design for any new feature. And once again, this must be done continuously; other ways, the design and the product itself will become an uncontrollable spaghetti.

 Third: Continuous Integration. This is to avoid the overhead of late integration when one discovers that each piece of his product is working fine but only individually and once tied together none is working.

And for sure, all of this can’t be done without a High technical skills and a good Collaboration between team members and the customer.

Enjoy agility, it’s a mindset!

Sif E. Elharti

Even small acts can have a great impact…

Written by selharti

June 3, 2010 at 11:42 pm

Être Agile, c’est une réalité chez Pyxis…

leave a comment »

Pyxis est un grand acteur « Agile » dans le monde francophone. D’ailleurs, François Beauregard, fondateur et président de Pyxis, est l’une de toutes premières personnes francophones certifiées « formateur Scrum ».

J’ai eu l’occasion de rendre visite à François dans les locaux de l’entreprise. Et, je ne vous cache pas, j’ai été frappé par la matérialisation d’éléments clés de l’approche Agile.

La transparence. L’espace des bureaux est grand ouvert. Personne ne se cache et personne n’a rien à cacher (à l’exception, peut-être, du lait pour les invités surprise! ). Nul besoin de passer un coup de fil avant d’aller poser une question à un collègue. Ainsi, la communication et la collaboration se voient renforcées sans effort. Un peu partout sur les quelques murs disponibles, il y a des « post-its » avec plein de couleurs, sans doute les résultats de discussions sur des items sortis directement du backlog d’un produit et qu’on a essayés de prioriser en utilisant les couleurs et les positions. Mais, ce qui est plus marquant, ce sont les bureaux sur des roulettes! Rien n’empêche des collègues qui travaillent ensemble sur un même projet de s’organiser comme ils veulent, à même les positions et les dispositions de leurs bureaux!

Je n’ai pas eu l’occasion de passer plus de temps avec les collègues de François, mais je ne doute pas que la même dynamique et philosophie d’agilité régnent dans leurs quotidiens.

Sif,

Même les petits gestes peuvent avoir un grand impact.

Written by selharti

January 29, 2010 at 3:40 am

Posted in Misc.

Tagged with , ,

%d bloggers like this: