Sif E. Elharti's Blog

Even small acts can have a great impact…

Posts Tagged ‘Agile

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

Jusqu’à quel point votre organisation est-elle « Agile » ?

leave a comment »

Le domaine de développement logiciel, comme tout autre d’ailleurs, n’échappe pas à l’effet de la mode. Et soudain! Tout le monde veut devenir « Agile », parce qu’un patron a lu un article, ou parce qu’un concurrent l’est devenu ou … plein d’autres raisons. Dirais-je, dans ce cas-ci, que toute raison est bonne, du moment qu’on le fasse dans les règles de l’art. Et l’une des règles de base dans l’Agilité est de se voir dans un miroir pour contempler la réalité telle qu’elle est et s’autocritiquer! D’où l’idée de cette réflexion,
Alors, voici quelques questions que je trouve intéressantes pour une première auto-évaluation de l’Agilité dans votre organisation? En répondant honnêtement à cette liste (vous n’avez pas à le faire publiquement!), vous trouverez la réponse par vous-même, si non demandez de l’aide. Le « vous » utilisé peut être toute personne impliquée ou qui a l’occasion de suivre un projet qui se dit « Agile ».
Client
1- Est-ce que le client a le droit de changer d’avis en cours de projet?
2- Votre client – ou quelqu’un qui le représente et qui peut décider en son nom- participe t-il au projet? (sans compter la demande et la livraison)
3- Votre relation avec le client est-elle orientée contrat ou collaboration?
Produit
4- Est-ce que votre produit est construit d’une façon incrémentale?
5- Si votre projet est arrêté aujourd’hui (en supposant qu’il a commencé depuis un bout), est-ce que vous aurez quelque chose à livrer?
6- Y a-t-il une seule personne qui décide du contenu du produit et des priorités?
Équipe
7- Avez-vous une équipe dédiée au projet? (qui ne se fait pas déranger pour tout et n’importe quoi.)
8- Votre équipe est-elle auto-organisée? (Il n’y a personne qui lui dicte comment faire son travail.)
9- Votre équipe travaille t-elle comme une seule unité (comme les trois mousquetaires: tous pour un et un pour tous!)
10- Votre équipe est-elle autonome? (a t-elle toutes les ressources et les compétences nécessaires pour réussir le projet.)
11- Votre équipe travaille t-elle dans un environnement ouvert et rapproché? (le cas d’équipe répartie n’est pas pris en charge dans ce questionnaire)
12- Voyez-vous de l’interaction entre les membres de l’équipe?
13- Votre équipe a t-elle des membres qui refusent de se « mouiller » dans le code? (Non! moi je ne touche pas à ça…!)
Communication
14- Avez-vous des rencontres régulières, brèves et soumises à une contrainte de temps ou plutôt longues et à l’improviste?
15- Passez-vous plus de temps sur la forme (PowerPoint) que sur le fond de vos présentations?
16- Écrivez vous de la documentation juste pour suivre le protocole où plutôt parce qu’elle est nécessaire?
Organisation
17- Avez-vous le support de votre organisation pour faire le nécessaire pour la bonne marche du projet?
18- Votre organisation favorise t-elle les personnes ou les processus?
19- Avez-vous toujours du mal à réunir toutes les parties prenantes de votre projet?
Technologie et Environnement
20- Votre équipe est-elle à jour (au courant des changements et des nouveautés) vis–à-vis des technologies que vous utilisez.
21- Avez- vous au moins trois environnements (développement, test, production)?
22- Avez-vous des testes automatiques?
Pour Finir
23- Est-ce que vous et les membres de l’équipe êtes contents de rentrer travailler chaque matin? (surtout le lundi!)
Mais, ce n’est pas fini!
Cette liste de questions ne couvre pas bien sûr tous les aspects de l’Agilité, mais elle permet au moins de se faire une petite idée sur son environnement et pourrait aider à l’améliorer.
Si après avoir répondu, vous pensez que votre organisation est « Agile » ou assez « Agile », restez sur vos gardes parce qu’être « Agile » c’est aussi être vigilant!
À la prochaine,

Sif E. Elharti

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

Written by selharti

April 1, 2010 at 12:47 pm

Project Management: Part 5 – Basic concepts – Mapping Project Management Process Groups and Knowledge Areas

leave a comment »

Manage a project is a hard to summarize task. By the PMBOK standard, it’s about managing the following NINE areas, but not restricted to: Integration, Scope, Time, Cost, Quality, Human Resources, Communication, Risk and Procurement. 

Each area has a defined set of processes. The set of all the processes for all the areas can be partitioned in FIVE process groups: Initiating, Planning, Executing, Managing and Controlling and Closing. 

PMBOK definition: “A process is a set of interrelated actions and activities performed to achieve a pre-specified product, result, or service. Each process is characterized by its inputs, the tools and techniques that can be applied, and the resulting outputs.”  

Thus, project management consist of selecting the processes that apply for the underlying project and execute these processes in order to achieve the target of the project. 

Many factors can influence the subset of selected processes and the way they are applied. But the main elements to consider are: The organization process asset and the enterprise environment factors. Those two must be watched all over the project life. 

 

You may wonder where all these are coming from. Recall, from our previous posts, that a lot of projects have is undertaken, and a large common experience was developed during ages. And this is the common experience as seen and addressed by the PMI. 

We’ll see each the process groups, the knowledge areas, and the processes listed progressively (fig. above). 

But keep in mind the here following points: 

  • Even if we are talking about processes here, the job is actually done by people. So the focus on process will help define a path to follow but will never replace the special care to be given to people to make that path leading to the projected target of the project.
  • On the other hand, each project is unique, and one must not be flowed thinking that if he applies religiously all the processes, the result is guaranteed. It takes some “Agility” to take the “right” decisions, or may I say the “best”, at the right time depending on the information available and the special context of the project.
  • And the last one: if you are new to the domain do not try to be so much innovator. Try first to understand, apply and experiment and find your way smoothly. But most of all, learn from others and share your experience.

See you later.

Sif E. Elharti,

Written by selharti

March 16, 2010 at 6:27 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: