novembre 2009Monthly :

Agile lessons learned #1 : Challenge everything.

Grown-ups never understand anything by themselves, and it is tiresome for children to be always and forever explaining things to them – Le petit prince by Antoine de Saint Exupéry

Jonathan was in a rut. Despite his best efforts on FreeFall’s brand new mega-project, nothing seemed to click. Everything just felt wrong. He could not quite put his finger on it, but he just knew something was going terribly wrong. Feeling powerless, everyday he got more and more anxious about the whole ordeal.

Once the project started to go haywire, FreeFall started to panic. Having a limited budget for outside ressources, despite losing millions on the project, they decided to hire Erol as a single Agile coach to do an assessment of the situation.

One day Jonathan and Erol met at the cafeteria where Erol had basically set up his office. Erol felt there was no better place to start conversations with people than the cafeteria. Things that people would never of said in official meetings, Erol was told in a matter of minutes. This jump-started his information collection like nothing else.

“I know you are here to help us” said Jonathan.
“I also feel that everything seems wrong but I can’t quite put my finger on it. Can you help me with that ?”
“If you’ve got five minutes, I’ve got a real story that might help you.”

Jonathan grabbed himself a coffee while Erol told him the following story:
“When I was young, I grew up in Haiti. I lived on the same street as all of my family. This was great when parties were thrown. We’d just get all together outside and party until the sun came up and then we’d party some more.”

“Christmas tradition was to cook a huge turkey based on the family recipe that came all the way from my great-grandmother.”

“The final step of the recipe was to chop a part of the turkey off before putting it in the oven”

“At six years old, my sister asked my mother why she was cutting off a part of the turkey. She said it was because her mother did it like that”

“So my sister asked my grandmother why she did it like that.”
“She said because your great-grand mother did it like that.”

“She then went on to see her great grand-mother”
“She asked her why she cut off a part of her turkey”
“She said, that she used to do it like that because her oven was too small to fit a turkey back then”

“You see, for generations, my family had been throwing away a part of their turkey for no good reason. If my sister did not challenge every member of my family until she found the root of the problem, we would of been throwing away turkey for generations to come even though the answer had lied next door for years.”

“Maybe I should start challenging what seems wrong” – said Jonathan
“Maybe you should Jon, maybe you should…”

-Nicholas Lemay

Charte du développeur

Tout a commencé à la fin de ma première mission en clientèle.
Fort d’un an et demi passé à apprendre, à coder, à m’essayer dans le TDD, à observer des développeurs de différents horizons…, je me suis rendu compte que le métier de développeur parfois dénigré est en réalité une profession à part entière qui nécessite beaucoup de compétences et de rigueur.

À la fin de cette mission je me suis beaucoup questionné sur le rôle de développeur à Pyxis. Je me suis notamment demandé :

  • En quoi se différencie-t-on des autres?
  • Qu’est-ce que peut espérer un client en confiant un projet à des développeurs de Pyxis?
  • Quelles sont les valeurs d’un développeur de Pyxis?
  • Comment fait-on pour être des exemples de ce que l’on propose à nos clients?

À la suite d’une discussion à l’interne sur la place d’un développeur à Pyxis, il y a une réponse qui m’a particulièrement plu et que j’ai voulu approfondir.
Dans sa réponse, Vincent Tencé a défini un ensemble de valeurs caractérisant sa vision du développeur de Pyxis.
Cette vision m’a éclairé sur la nécessité de définir une Charte du développeur que j’ai élaborée après un an de travail collaboratif.

Bonne lecture!

Agile Lessons Learned #1 : Challenge Everything.

Grown-ups never understand anything by themselves, and it is tiresome for children to be always and forever explaining things to them – Le petit prince by Antoine de Saint Exupéry


Jonathan was in a rut. Despite his best efforts on FreeFall’s brand new mega-project, nothing seemed to click. Everything just felt wrong. He could not quite put his finger on it, but he just knew something was going terribly wrong. Feeling powerless, everyday he got more and more anxious about the whole ordeal.

Once the project started to go haywire, FreeFall started to panic. Having a limited budget for outside ressources, despite losing millions on the project, they decided to hire Erol as a single Agile coach to do an assessment of the situation.

One day Jonathan and Erol met at the cafeteria where Erol had basically set up his office. Erol felt there was no better place to start conversations with people than the cafeteria. Things that people would never of said in official meetings, Erol was told in a matter of minutes. This jump-started his information collection like nothing else.

“I know you are here to help us” said Jonathan.
“I also feel that everything seems wrong but I can’t quite put my finger on it. Can you help me with that ?”
“If you’ve got five minutes, I’ve got a real story that might help you.”

Jonathan grabbed himself a coffee while Erol told him the following story:
“When I was young, I grew up in Haiti. I lived on the same street as all of my family. This was great when parties were thrown. We’d just get all together outside and party until the sun came up and then we’d party some more.”

“Christmas tradition was to cook a huge turkey based on the family recipe that came all the way from my great-grandmother.”

“The final step of the recipe was to chop a part of the turkey off before putting it in the oven”

“At six years old, my sister asked my mother why she was cutting off a part of the turkey. She said it was because her mother did it like that”

“So my sister asked my grandmother why she did it like that.”
“She said because your great-grand mother did it like that.”

“She then went on to see her great grand-mother”
“She asked her why she cut off a part of her turkey”
“She said, that she used to do it like that because her oven was too small to fit a turkey back then”

“You see, for generations, my family had been throwing away a part of their turkey for no good reason. If my sister did not challenge every member of my family until she found the root of the problem, we would of been throwing away turkey for generations to come even though the answer had lied next door for years.”

“Maybe I should start challenging what seems wrong” – said Jonathan
“Maybe you should Jon, maybe you should…”

-Nicholas Lemay

GreenPepper 2.6 now available

This new release includes a new Scenario interpreter that have a BDD style, XWiki integration (use XWiki to write your executable specifications), a plugin for Grails, a better compatibility with Confluence 3.0 and up, many improvements to the PHP extensions (Thanks to folks at Astria) and bug fixes.

See the release notes for more details…

The Scrum Hawks

I guess you’ve all heard about chickens and pigs in Scrum.  A client of mine just offered me a new one: The Scrum Hawk. He explains it like this :

“When SCRUM is new to an organization, the first couple of sprints will likely not go as well as planned. At this point, the scrum chickens magically transform into hawks, ready to pounce on the scrum team. “Pouncing” may include attending the daily standup meetings to put pressure on the team.”

Who are these Hawks?

What are Scrum Hawks doing to your new (or not so new) team?

How are they affecting the team?

How do we ground these Hawks and get them to cluck again?

Pyxis Snow Team participe au 24h Tremblant

Le 24h Tremblant, cette année à sa 9e mouture, recueille plusieurs centaines de milliers de dollars pour les enfants malades ou défavorisés. En effet, la Fondation Centre de cancérologie Charles-Bruneau sera bénéficiaire de l’événement pour une 6e année.

Cette année le Pyxis Snow Team a décidé de participer à l’événement pour contribuer à amasser des fonds pour la recherche. L’équipe est composée de 6 Pyxissiens (Dominic Danis, Jean-François Proulx, Marie-Eve Trempe, Sami Dalouche, Tremeur Balbous et Yvon Frongillo), qui vont descendre les pistes de ski du Mont-Tremblant en relais pendant 24 heures les 12 et 13 décembre.

Soutenez notre équipe et la Fondation en faisant un don à http://pyxis-tech.com/24h-tremblant/. Venez aussi nous encourager durant cette fin de semaine du 12-13 décembre 2009. Vos cris et sourires nous motiverons dans nos descentes.

Agile lessons learned #3 : The red pill.

A man’s life is primarly interesting when he has failed.
For it’s a sign that he tried to surpass himself.

– George Clemenceau.

Tim was an agile coach. One morning he bumped into Andrew, a senior manager over at FreeFall inc, a fortune 500 company.

“Hey Tim ! How bout that Agile thing ? Do you guys still do the scrum in the morning ?
“How’s that coming along ? ”
“I don’t know how to put this Andrew, but we don’t ‘do the scrum’ in the morning.
Being agile is way more than doing daily meetings.”
“Oh really? What else is there to Agile ?”
“You might wanna grab a doughnut with that coffee, I’ve got a few things to show you”

Tim went on explaining the different aspects of scrum, the roles and the different ceremonies. But the knew the selling point to the manager was the continuous improvement brought by the frequent inspection and adaptation the teams puts itself through.

You see, with Scrum all you problems will become apparent. Think of the problems as cream being poured into a coffee. If you just keep on pouring and stirring all the time everything stays in a confused mess. But if you take time to stop stirring your mess, the cream will rise to the top and you’ll get a clearer view of what’s goin on.

For this to happen here are some important steps :

Courage :
You can call yourself Agile if you want to. For that matter you can call a cat a dog if you want to. But you are not Agile without frequent introspection and a true and deep desire to be better tomorrow than you are today.

This all start with courage. Courage to admit that you can be wrong. Courage to tell someone else that he/she was wrong. Courage to truly listen when someone is criticizing you. Courage to take what is on the table and make yourself a better you. A better team starts with a better you.

Desire :

Why do you desire to become better today than you were yesterday ? What is you’re source of motivation ? Are you so disgusted by you current situation that you wish not to have to experience it in the future ? Have you seen better and want to recreate it ? Do you see change as a desirable thing ? As a source of motivation ?

Napoleon was once quoted as saying :”Men are Moved by two levers only: fear and self-interest”. This might give you food for thoughts in finding the real reason why you desire change.

Failure must be an option:
If you are now allowed to fail, you cannot become better. You must be allowed to fail in order to be able to freely admit your failure in order to get feedback to help yourself get better. You should never seek failure, but you should not fear it.

Awareness of the consequences :

Once you start into this continuous self-introspection game you will be cursed. Cursed for life. You see, most teams have exactly the same problems as you go through and might still go through for the rest of your life. But you WILL see them. Just like Neo in the Matrix can see the code of the Matrix, you will see the problems when people within the mess have no idea how deep they’re in.

So you have two choices. To quote Morpheus talking to Neo :

“You take the blue pill, the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill, you stay in Wonderland, and I show you how deep the rabbit hole goes.

So what’s it gonna be ? The red pill or the blue pill ? Cause once you take the red pill, there is no turning back. Trust me.

Tests UI Web avec FluentSelenium

Si vous avez l’habitude de faire des tests d’interface Web avec Selenium, vous savez sûrement à quel point ces tests deviennent difficiles à maintenir ou sont difficiles à lire (voire déchiffrer). FluentSelenium est un projet Open Source offert par Pyxis (http://fluentselenium.codeplex.com) pour améliorer la lisibilité de ces tests et par la même occasion, en faciliter l’écriture avec l’utilisation d’un langage dédié (Domain Specific Language ou DSL).

Les meilleures pratiques proposent qu’un développeur soit capable de comprendre le comportement d’un test très rapidement. Dans l’exemple suivant, on veut tester l’ajout d’un ‘post’ sur un forum. Pour y arriver, on doit passer par la liste des ‘posts’ et remplir les champs du formulaire pour ensuite cliquer sur le bouton de sauvegarde et revenir à la liste. Si on regarde le code que l’on produirait avec Selenium directement, on obtiendrait ceci :


[Test]
public void TestAddNewPostCanSeeInTheList()
{

selenium.Open(“Forum/AllPosts.aspx”);
selenium.WaitForPageToLoad(“2000″);selenium.Click(“//a[contains(@id, 'newPost')]“);
selenium.WaitForPageToLoad(“2000″);

selenium.Type(“//*[contains(@id, 'txtAuthor')]“, “Paul”);
selenium.Type(“//*[contains(@id, 'txtSubject')]“, “Simple example of the library.”);
selenium.Click(“//*[contains(@id, 'btnSavePost')]“);
selenium.WaitForPageToLoad(“2000″);

Assert.AreEqual(“Paul”, selenium.GetText(“//table[contains(@id, 'grdPosts')]//tr[2]/td[2]“));

}

Je crois que tout le monde s’entend pour dire que ce test n’est pas très lisible. Il y a plusieurs façons de l’améliorer, comme par exemple extraire les XPath dans des constantes ou se créer une espèce de framework pour découper les parties de notre application. Toutefois, ce serait encore mieux si on pouvait lire le test comme si on lisait des phrases. L’exemple suivant montre un peu comment on peut « phraser » le même test en utilisant FluentSelenium :


[Test]
public void TestAddNewPostCanSeeInTheList()
{

forumUser.Goto(“Forum/AllPosts.aspx”);
forumUser.For(PostListPage.AddPostButton).Clicks();forumUser.For(NewPostPage.AuthorTextBox).Enters(“Paul”);
forumUser.For(NewPostPage.SubjectTextBox).Enters(“Simple example of the library.”);
forumUser.For(NewPostPage.SavePostButton).Clicks();
forumUser.For(PostListPage.AllPostsTable).Row(2).ShouldSee(postDate, “Paul”, “Simple example of the library.”);

}

De plus, dans cet exemple, on peut très bien imaginer que l’action d’ajouter un ‘post’ reviendrait dans
plusieurs tests différents. Alors, notre test ressemblerait plus à ce qui suit :


private static readonly ITask AddNewPost = new AddNewPostTask("Paul", "Simple example of the library.", "");

[Test]
public void TestAddNewPostCanSeeInTheList()
{

forumUser.Goto(“Forum/AllPosts.aspx”);
forumUser.Do(AddNewPost);
forumUser.For(PostListPage.AllPostsTable).Row(2).ShouldSee(postDate, “Paul”, “Simple example of the library.”);

}

À ce point-ci, on pourrait expliciter un peu plus la commande en ajoutant une Factory :

 

forumUser.Do(AddNewPost(“Paul”, “Simple example of the library.”));

 

Ultimement, l’idée est de rendre les tests le plus lisible possible. FluentSelenium est un API simple pour écrire des tests d’interface, mais l’utilisation d’un langage dédié pour écrire des tests unitaires ou d’intégration est une pratique puissante pour les tests unitaires et d’intégration.
Pour avoir plus de détails sur les exemples utilisés, vous pouvez accéder au code du projet sur codeplex : http://fluentselenium.codeplex.com.

Nous sommes des adultes responsables

J’aime le magazine Wired, je le lis religieusement depuis 2005. Tous les articles ne génèrent pas le même niveau d’intérêt pour moi, certains sont lus distraitement. Par contre, certains autres se révèlent être inspirants. Comme celui de l’édition d’octobre 2009 à propos de Netflix.

On y décrit l’entreprise, sa croissance, son modèle d’affaires et son modèle de gestion.

A quiet, hands-off leader, he sets the tone and objectives and lets his employees figure out how to execute them. His main directive is that everyone act like an adult: Netflix has no vacation policy (take as much as you need, when you need it), pay is flexible (stock or cash, your choice), and though firings are unusually common, severance checks are unusually generous. Hastings is comfortable creating his own rules for how to run a business; you don’t see any management tomes in his office. In fact, he doesn’t even have an office. The CEO prefers to stroll around, a ThinkPad in hand, pitching camp in an empty conference room or huddling in an engineer’s cubicle to whiteboard some formula.
source: WIRED MAGAZINE: 17.10

Un modèle de gestion responsabilisant. Les employés sont des adultes et sont suffisamment responsables pour décider eux-mêmes comment mettre en œuvre les objectifs de l’entreprise et la faire avancer.

À Pyxis, nous construisons un modèle similaire et lorsque nous le décrivons, la réaction est parfois un regard quelque peu incrédule. “Ton patron ne te dit pas quoi faire!?!” Et bien non! Mon “patron” pyxissien ne me dit pas quoi faire, il m’encourage à prendre une décision réfléchie et de façon responsable.

Votre patron vous encourage-t-il à prendre des décisions ou bien est-il LE responsable ?

Pyxis and FIAN: When Agility meets human rights!

Lire la version française.

What link is there between an IT company managing Agile software development projects and an international human rights NGO fighting for people’s right to food? A priori none, however sometimes it only needs two individuals (let’s suppose a couple where Mrs. works for Pyxis and Mr. works for FIAN…) for a relation to become possible and for realizing that even if their activities are obviously very different, Pyxis and FIAN strive to put the human in midst of preoccupations, searching for dignity and improvement of living and working conditions.

Pyxis’ raison d’être is the following: “Pyxis helps software development companies to become places where results, quality of life, and fun coexist sustainably by being first and foremost an example of what it proposes to its clients and by coaching them.” Furthermore, Pyxis publicly shows in its blog its commitment to increase the growth of the organization while improving people’s life and having fun.

FIAN is working hard for the right to food with, among others, letter campaigns addressed to authorities violating this right. Therefore, when peasants are being expulsed without any compensation or when native people are forced to flee their ancestral territories to allow for agricultural or natural resources exploitation projects, FIAN intervenes in order to handle situations endangering the daily nutrition of thousands, indeed millions of people. FIAN’s activities are not limited to this since FIAN is very active in international forums (United Nations Food and Agriculture Organisation (FAO)) in order for the right to food and nutrition to be defined as one of the pillars of development and co-operation policies of ‘Northern’ countries, whose goal has been for over 40 years now to eradicate hunger worldwide. And this goal is far from being achieved: in 2009, humanity has for the first time exceeded the symbolic level of billion of people affected by hunger and malnutrition (1.02 billion according to the FAO in June 2009). This situation is simply unacceptable on a planet that could feed 12 billion persons if food resources would be distributed equitably.

In July 2009, I had the opportunity to meet many employees of Pyxis in Laval (Quebec), and I was quite surprised of their interest for FIAN and our activities. Personally, I wanted to take advantage of this encounter to tell them about the communication challenges within FIAN’s structure, i.e. between our different components (salaried employees, board of directors, voluntary workers, translators, European colleagues…). Potential solutions were quickly found since communication challenges within an NGO are quite similar to those of a team of computer engineers. What stood out is the installation—above all the use—of a wiki as a first step in order to no longer waste this very precious resource called time. I imagine that Pyxissians (people at Pyxis) are still asking themselves how an NGO like FIAN is able to work with the very few efficient information sharing tools they have… And yet, it is possible because people at FIAN are passionate persons in the same way as Pyxissians are in their domain.

Because of these common passion and goal to put the human in midst of preoccupations, Pyxis decided to financially support FIAN by developing an iPhone application and donating to FIAN all revenues generated by its sale.

Xavier Papet