Sif E. Elharti's Blog

Even small acts can have a great impact…

About the “50% of what you think is wrong by Jeff Sutherland”

leave a comment »

As Jeff said in his post : “50% of what you think is wrong…” and you can prove it to yourself. I’ll try to summarise and give my opinion about knowledge.

Great and deep thinking Jeff, thank you for sharing. The animation is a bit fast which may distract from focussing more on what is said, but it’s nice – very good job -.

To summarise my understanding from the text and the presentation (and maybe it’s 50% wrong!)

1-      50 % of our thinking is wrong

2-      Motivation in most organisations is based on rewarding and punishing – (not so productive ways and even obvious in some cases).

3-      For better performance, people need

  • Autonomy
  • Mastering
  • Purpose

I totally agree with 2 and 3 and they are the main idea behind this post. But, if you don’t mind, I would like to add a note about the first one (Philosophical thinking about knowledge).

Indeed, maybe 50 % of one’s knowledge or common knowledge is wrong and history of science is here to enforce this position. But if we push the analysis a little forward we will have two problems ( or results depending on how you qualify them) with that:

1-      There is no absolute knowledge: 50 % of our thinking is wrong, and since we have no idea which thought is in which context (wrong or right), we can say that no thought is absolutely right.

2-      Maybe the statement that “50% is wrong” is part of the 50% that is wrong: This is the case of recurrent logic which rejects its parent and ends to rejecting itself.

In my opinion, it’s not about wrong or right at absolute level. It’s rather about better or worse at relative and local level. To keep going, we need to choose our path and this is done by each one using his personal reference of better or worse from his point of view. And this last can only be a relative and a local one.

Thus, sharing our thoughts is the best way to check how far they are “right” and learn from each other!

Sif E. Elharti

Even small acts can have a great impact…


Written by selharti

June 22, 2010 at 2:43 am

Traduction du guide Scrum en Arabe (version finale non officielle)

leave a comment »

 (Texte en Français plus bas)

Here is the final but non official version of the Scrum guide translation to Arabic:

Scrum Guide – Arabic.trans (final non official Version)

Thanks to everyone who participated or showed his interest to accomplish this project.


Sif E. Elharti

– If you notice any error or have any comment please let me know. –

===== French ==========

Voici la version finale non officielle du Guide Scrum (en attendant la publication sur

Scrum Guide – Arabic.trans (Version finale non officielle)

Merci à tous ceux qui ont participé ou montré leur intérêt pour  la réalisation de ce projet.


Sif E. Elharti

– Si vous trouvez des erreurs ou avez des commentaires, n’hésitez pas à me contacter svp.-

Written by selharti

June 19, 2010 at 12:25 am

Posted in Agile, Scrum

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

Traduction du guide Scrum en Arabe (Version non officielle)

leave a comment »

Voici une version non officielle du Guide Scrum pour relecture avant publication: 

Scrum Guide – Arabic.trans (Version non officielle)

Merci pour votre contribution.

Written by selharti

May 13, 2010 at 12:13 am

Posted in Agile

How far is your project “Agile”?

with 6 comments

The field of software development, like any other one, cannot escape the fashion effect. Suddenly! Everyone wants to become “Agile”, because a patron has read an article, or because a competitor did the transition … or many other reasons. I would say, in this case, that any reason is good, as long as we do so in the rules of art. And one of the basic rules of agility is to see the reality as it is and self-criticise! And that’s the purpose of this reflection.

Here are some questions that I find interesting for a first self-assessment of Agility in your organization. By answering honestly to this list (you do not need to do so publicly!), you will find the answer by yourself, if it’s not the case ask for help. The “you” used can be any person involved in or who has the opportunity to follow a project that wants to be “Agile”.


1-      Has your customer the right to change his mind during the project?

2-      Your customer – or someone who can make decisions on his behalf – participates in the project? (launch and delivery are excluded)

3-      Your relationship with the customer is contract or collaboration oriented?


4-      Is your product developed in incremental way?

5-      If your project is stopped today (assuming it started a will ago), will you have something to deliver?

6-      Is there one person who decides about the product’s contents and their priorities?


7-      Is your team dedicated to the project? (Not disturbed for everything and nothing.)

8-      Is your team self-organized? (There is no one who shows her how to do her job.)

9-      Does your team act as a single unit (like the three musketeers: all for one and one for all!)

10-   Is your team independent? (She has all the resources and skills necessary for project success.)

11-   Do you see any interaction between members of the team?

12-   Are there any members in your team who refuse to code? (No, I do not touch this …!)


13-   Do you have regular meetings, brief and subject to time constraints or rather long and unexpected?

14-   Do you spend more time on the layout (PowerPoint…) than on the content of your communications?

15-   Do you write documentation just to follow protocol or rather because it is needed and useful?


16-   Do you have any support from your organization to fulfil your project needs?

17-   Does your organization promote people or processes?

18-   Do you have always to struggle to bring together all stakeholders of your project?

Technology and Environment

19-   Is your team in an open working space? (large distributed teams are not considered in this list)

20-   Is your team up to date (aware of changes and new products) related to the technologies you are using or may use?

21-   Do you have at least three environments (development, testing, and production)?

22-   Do you have automated tests?

To Finish

23-   Are you and members of the team happy to go to work every morning? (Especially Mondays!)

But it’s not over!

Of course, this checklist does not cover all aspects of Agility, but it can at least give an idea about your environment and, I hope, may help to improve it.

If after answering, you think your organization is “Agile” or pretty “Agile”, stay on your guard because being “Agile” is also about being vigilant!

Sif E. Elharti

Even small acts can have a great impact…

Written by selharti

April 15, 2010 at 12:41 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 ».
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?
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?
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…!)
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?
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

%d bloggers like this: