Sif E. Elharti's Blog

Even small acts can have a great impact…

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.

Regards,

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

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.

Cordialement,

Sif E. Elharti

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

Advertisements

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

Customer

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?

Product

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?

Team

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 …!)

Communication

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?

Organization

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

Project Management: Part 4 – Basic concepts Project / Program / Portfolio

leave a comment »

For a large organisation, projects can be gathered in two kinds of collections: Program or Portfolio.

The PMI definitions are as following PMBOK (4th Ed.):

A “Program is a group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually. Programs may include elements of related work outside of the scope of the discrete projects in the program.”

 “A portfolio refers to a collection of projects or programs and other works that are grouped together to facilitate effective management of what work to meet strategic business objectives.”

 An easy way to figure it out is to imagine portfolios and programs as containers that can include projects.

Portfolio, program and project organization

A portfolio is at business strategy level. Its scope is larger than any program or project within the organization and has strategic goal to reach. Thus it contains a set of project or programs that complete each other for that purpose. Nevertheless, those programs and projects are not necessarily related or dependent.  The main raison for creating a portfolio is to centralize, synchronize and prioritize all the components needed to carry out the business goal.

A program is a component of a portfolio that groups a set of related projects that need to be coordinated to accomplish a larger target than the target of the projects individually.

Let’s apply this to an example:

Suppose a developing country “Alpha” has identified tourism as major axe to develop to enhance its economy. “Alpha” has identified also that a large number of pediments that act against this opportunity such as:

  • Bad infrastructure: few international airports with limited capacities, missing highways and roads.
  • No easy access to natural parks and historical sites
  • Limited high standing Hotels.
  • Poor marketing
  • Restrictive lows
  • Etc…

So “Alpha” creates the following projects (to keep it simple, we will stop at this infrastructure and hotels level)

  • Portfolio: “Welcome to Alpha”

    • Portfolio1.1: “Transportation program”

      • Program 1.1.1: Highway between cities “A” and “B”

        •          Project 1.1.1.1: Highway Section 1 (“A” to “N”)
        •          Project 1.1.1.2: Highway Section 2 (“N” to “M”)
        •          Project 1.1.1.3: Highway Section 3 (“M” to “B”)


      • Project 1.1.2: Highway between cities “A” and “C”
      • Project 1.1.3: Enlarge the international airport of city “A”
      • Project 1.1.4: Add a road from city “B” to the historical site “H”
      • Project 1.1.5: Add a road from city “C” to the natural site “N”


    • Portfolio1.2: “Hotels”

      • Project 1.2.1: Build Airport hotel in city “A”
      • Project 1.2.2: Extend hotel “X” in city “B”
      • Project 1.2.3: Build hotel near the site “N”
      • Project 1.2.4: Build hotel near the site “P”
      • Project 1.2.5: Build hotel in city “C”





The role of the portfolio managers is to coordinate and prioritize all these programs and projects by providing all the necessary infrastructure, processes and assistance needed to facilitate the accomplishment of the main goal.

But one has to keep in mind that applying this model of projects hierarchy requires a maturity in the organization. In fact, a bad implementation or misunderstanding can lead to more chaotic results and can go against the original purpose for which it was undertaken.

See you later.

Sif E. Elharti,

Written by selharti

March 6, 2010 at 2:52 am

%d bloggers like this: