Category : Vie @ Pyxis

L’équipe nSemble au codapalooza

La fin de semaine dernière (26-27 novembre), l’équipe nSemble a participé au codapalooza pour développer AgileRoom v1.0. Un peu de café, quelques séances de modélisation Agile,  un objectif à atteindre sous forme de tests automatisés de bout en bout et hop … on est parti pour un 32 heures de développement en se relayant au sein de l’équipe.

À l’aide des technologies comme ASP.NET MVC et Entity Framework 4.0, nous avons réussi à démontrer un premier prototype qui a répondu aux attentes de notre PO malgré la durée relativement courte de l’itération. On se dit à l’année prochaine pour le prochain codapalooza.

De la théorie à la pratique

Cela fait maintenant 4 mois que je travaille à Pyxis et les bancs de l’Université me semblent déjà bien loin. Pas forcément en terme de temps, mais plutôt d’un point de vue pratique.  Lors de mes études en management et communication j’ai trouvé la transition entre la théorie et la pratique évidente et facile mais en ce qui concerne cette transition dans le domaine de l’informatique, c’est une autre paire de manche.

Qu’est ce qu’on nous apprend au département informatique de l’université? Des langages de programmation majoritairement, des mathématiques, de l’algorithmie, des notions de sécurité ainsi qu’une approche du montage vidéo et des outils de DAO. Évidemment c’est un passage obligé et comme la plupart de ces concepts étaient nouveaux pour moi, j’ai pris beaucoup de plaisir à me plonger dans ce milieu qui m’avait toujours attiré. Je buvais donc les paroles des professeurs qui me disait que Java était un langage émergent, que l’abondance de commentaires dans du code était synonyme de qualité et que de prévoir la conception d’un projet sur le long terme évitait les surprises désagréables.

Étape numéro 2 : j’arrive à Pyxis. Tiens, c’est bizarre les gens autour de moi parlent de concepts légèrement opposés à ce que j’ai appris précédemment. “Java? C’est dépassé, trop lourd et pas assez élégant! Oriente toi plutôt vers Ruby, d’ailleurs apprend le on en a besoin pour le store d’Urban Turtle :) “. D’accord, c’est parti pour la programmation artistique alors. “Des commentaires dans ton code? Ca veut dire que ce que tu écris n’est pas clair, epic fail!” Oui c’est vrai en fait, ça parait logique. On va faire des micros classes et fonctions et du code ultra explicite. “Préparer et prévoir des projets sur le long terme? Va falloir que tu t’intéresses de près à Scrum!” En effet, le concept est fascinant. “D’ailleurs le TDD tu connais?” A moins que tu parles de Tranches De Dinde fumées non pas vraiment, mais je vais m’y intéresser!

Actuellement je baigne dans ces nouveaux dogmes, et en apprends tous les jours sur ces sujets passionnants. Notamment grâce aux cours de ScrumMaster et ScrumProfessional Developer offert par Pyxis qui m’ont permis de beaucoup progresser. Néanmoins, appliquer et intégrer tous ces schémas demandent du temps et du travail et il aurait été souhaitable qu’ils fassent partie d’une manière ou d’une autre des formations informatiques proposées à l’Université. Dans un domaine autant versatile que le développement logiciel, je pense qu’il est nécessaire d’adapter les formations proposées à la réalité du marché et que les responsables de programmes devraient se remettre en question régulièrement pour fournir à leurs étudiants un bagage complet correspondant aux attentes des entreprises les plus avant-gardistes comme Pyxis.

Gaël Luisier

Does YOUR organization have personality?

Personality can be defined as a dynamic and organized set of characteristics possessed by a person that uniquely influences his or her cognitions, motivations, and behaviors in various situations - Wikipedia

 

Yesterday, Pyxis Technologies celebrated its 10th anniversary, launched a new web site, released 2 video clips (How do you explain Agile approaches in 1 minutes? and Software development according to Pyxis) and threw a great party.

Over 200 guests attended the celebration. Many of the people I had a chance to speak with during the evening told me they really noticed the personality of our organization – some of which even asked if we would hire them. François has done an amazing job at attracting passionate individuals who share a common goal and that truly reflects a Pyxis personality.

Does YOUR organization have a personality?

Let’s make Job Offers not suck

As you may have realized by reading my previous posts, when it comes to managing software projects, my ideas are largely inspired from the Open Source movement, especially if we are talking of big, distributed projects involving many developers. When it comes to managing companies, my inspiration comes from incubators.

Now, if we are talking of hiring developers, I seem to forge my opinion based on what happens in the startup world.

Here are a few interesting pointers on hiring developers that I find inspiring :

And of course, salary is an important aspect of hiring. Did you know that the old proverb “money does not make happiness” has been proven wrong by researchers ?

Agile in a Command-and-Control Organization : What to do when upper management forces overtime?

Image by MyLifeStoryMy colleague François Perron launched a very interesting discussion on our private wiki – “As a coach, what to do when executives and upper management force the project team to do over time in order to meet deadlines?”.

As you can probably guess, this initiated very interesting discussions and an obvious reaction to such an approach.

Everyone agreed that due to the project visibility and the position of the organization within its market, the project launch date was critical. Everyone also understood that the organization had very few options so nobody debated the need to achieve results. The discussion was strictly around which measures to use in an Agile context.

I’ll admit up front that I am biased toward intrinsic motivation (I really loved Drive by Dan Pink) and the fact that it is well suited for an agile environment.

As such, my first impression to the conversation that was going on were:

  • Does the organization wish that employees spend more hours at the office (attendance) or would they prefer more engagement (commitment)?
  • If their choice is to increase the hours of attendance, imposing overtime will achieve this goal while giving them a false sense of increased performance. People will show they are working longer hours but the real throughput is unlikely to be much higher. In addition, software development is a brain intensive activity and reducing the amount of rest people get is likely to increase the number of mistakes they make.
  • On the contrary, if the organization wanted more involvement, the inclusion of team members in determining the best way to achieve the results would probably come to a better decision – even possibly leading the willingness to do over time

It appears to me that by forcing overtime, the executives and senior managers will probably collect their bonus and congratulate each others in the short term only to realize in the longer term that they have simply pushed the problem forward for others to deal with – and possibly request more over time in the long run.

Share

You might be interested in these related posts:

  1. I don’t feel so good – I’m a people manager in an Agile organization
  2. Does your organization support prostitution?
  3. Defining Agile Management – part 1

We need a business blog. But how do we get people to contribute?

Everybody now knows that a business blog is essential to be found on the world wild web, essential when you are an innovator who wants to share new ideas and a new way of doing things, essential for people to know what you are offering.

More than a year ago, a group of people sharing the same interest for Internet marketing decided it was time for Pyxis to have its own blog. But how the h… was it going to be possible to get people to blog? At Pyxis, many people are influencers and are used to speaking at conferences and addressing user groups, (that is why we have launched the podcast Vox Agile). But speaking and writing are two different stories.

The first thing we did to get started was to launch a contest that would last 4 weeks. People who would blog the most would win an iPod touch. Several people started to throw their ideas in writing. That is how it really started. It worked really well. Tremeur was the winner! (he now has his own blog). Then, Martin started his own and syndicated it to the Pyxis blog. He blogs constantly with great content. I’m sure that his blogs influence many others.

A main concern that first prevented people from contributing was the fear to be out of context. We emphasized in our communications that we did not want to impose a corporate guideline. We wanted the posts to reflect each person and to represent the culture of our company. The diversity of our employees is the wealth of our company. Talking about different subject is OK.  All people working at Pyxis are professionals. So far, we have never seen a post that was out of context or out of line. Surprisingly, another concern was making typo mistakes. To address this matter, a group of people offered their help to correct mistakes before publishing.

Also, we constantly provided statistics to encourage people. We wanted them to see that people are reading their posts. Posting comments (from co-workers to start with) helped a lot for bloggers to realise that what they have made an impact.

Today, Pyxis’ blog is an aggregation of 12 pyxissians’personal blogs.  We often read a post per day; on Agile project management, on scrum, on software development and many other topics.

Training On Hold – For Now

I planned on continuing my training sessions while I was on vacation. However it seems that I am even more tired after a day in the sun than I am after a day at the office. Go figure.

Anyway I decided to put the training on hold until I come back. A guy has to take a break from time to time. And it gives me more time to read and think about my objectives for the next year. That’s what I’m going to do for the next two weeks.

I’ll continue to do katas and small projects when I come back.

Journée Mira à Pyxis

Le 16 juillet dernier, Pyxis Technologies a organisé la deuxième édition de la journée Mira.

Cette journée permettait aux employés d’amener leur chien au travail en échange d’un don minimum de 20 $.

Avec les dons, nous avons pu amasser 335$ mais surtout nous avons pu avoir un environnement un peu plus énergique pour ne pas dire chaotique.

Merci, donc à tous les Pyxissiens qui ont participé et nous vous invitons à faire la même chose dans votre milieu de travail enfin d’aider la cause Mira.

Pour ceux qui ne connaissent pas, je vous invite à regarder Mira TV

Touch-Typing Training – Results

As I wrote a week ago, I trained touch-typing this week. My objective was to attain 85 wpm. Here’s a recap of my week:

Monday : I decided to use Typeracer as my baseline. It’s an online game that allows you to race others. The fastest typist wins. I had not played in 6 months or so – and it showed. My score for the last ten races dropped a bit. This was not a good start. Result after the day : 74 wpm

Tuestday : I did some drills on goodtyping.com to get back to speed. It must have helped because I raised my speed to 78 wpm.

Wednesday : mostly played Typeracer. I managed to cut down on typing errors and I’m up to 81 wpm.

Thursday : I tried to practice at night instead of during lunch time. Without much success – 80 wpm. My fingers were not obeying me. I did a few drills on goodtyping.com to increase accuracy.

Friday : Success! I managed to consistently type over 80 wpm today by concentrating on typing slower but with less mistakes. I managed an average of 87 wpm on my last 10 races.

The week is over and I achieved my objective of 85 wpm. I did this mostly by reducing mistakes – they can get really slow you down.

Thanks to my colleagues who followed in my track and helped me focus on this challenge.

Asking powerful questions to hire right

Many organizations spend a significant amount of time defining the experience, education, skills and other factors required for open positions. Most of the time, though, their hiring process fails to make sure they hire right. If you’re looking for a different way, you might be interested to know how it works at Pyxis.

This morning I sat down with François to prepare the first hiring interview of a candidate looking for a software developer position. We decided to not have a look at his resume just yet. Since one of our colleague had recommended the applicant, we trusted he was a good candidate and wanted to understand if there was a cultural fit.

We talked about the values, characteristics and behavioral traits we wanted to find in a potential colleague. We figured out we wanted someone who shared the following characteristics:

  • Accountable
  • Humble
  • Passionate
  • Intelligent
  • Team-oriented
  • Continuous improvement orientated

We then devised a series of powerful questions to help us figure out if the applicant was someone we wanted to work with. Below are some of the questions we used during the interview process. Keep in mind that those questions are no more than tools we used to orchestrate the conversation. How we frame the questions is decisive. To make sure we hire right, the questions have to be ambiguous, personal, and stressful:

  • Tell me why it is more important for you to be having this conversation with us, rather than being doing something else?
  • What are the things you hear yourself most often complain about in your current (or last) position?
  • What have you done to change the very things you complain about?
  • What would be an extraordinary accomplishment for you?
  • What is the greatest contribution that you plan to make to the organization?
  • What will you hold the organization accountable for?

With answers from the candidate to questions such as these, we now have a pretty good idea whether the candidate is a good fit for our organization or not.

The next step is to validate the technical skills of the candidate. I know of no other way to validate the skills of a developer than to orchestrate a conversation around code. So we will give the candidate an opportunity to show us what kind of developer he is through his code. But that’s another story.