mars 2011Monthly :

Agile relies and promotes the concept of self-organized teams but the concept is still misunderstood – except maybe for Jurgen who explains it very well in his book.

Even within Pyxis where we push the concept of self-organization to the entire organization, people often mistake independence and self-organization.

Here’s an attempt at distinguishing the two perspectives.

Independence is a condition of a nation, country, or state in which its residents and population, or some portion thereof, exercise self-government, and usually sovereignty, over its territory. – wikipedia

Independence is strongly tied to self-governance which is defined as:

(…) an abstract concept that refers to several scales of organization. (…) It can be used to describe a people or group being able to exercise all of the necessary functions of power without intervention from any authority which they cannot themselves alter. – wikipedia

On the other hand, self-organization is defined as:

the process where a structure or pattern appears in a system without a central authority or external element imposing it through planning. This globally coherent pattern appears from the local interaction of the elements that make up the system, thus the organization is achieved in a way that is parallel (all the elements act at the same time) and distributed (no element is a coordinator). – wikipedia

Although in both cases, no authority interferes with the organization of the people, self-organization emerges when there is no planning of how people will work together. In addition, the notion of imposed constraints appears when discussing self-organization.

As such, while independence could mean “We can do what we want, how and when we want”, self-organization means “We are free to operate how we wish within the defined constraints in order to achieve the established objectives”.

As I recently described, immature self-organized teams are often selfish and irresponsible:

Team members are happy to take advantage of being self-organized but only as long as it benefits them and that there are no increased responsibilities. Once a situation negatively impacts them (while benefiting the team), they aren’t willing to cooperate and when they are asked to take accountability for something, they shy away from the responsibility. In a nutshell, these individuals want the best of both worlds. To successfully transition to self-organization, it is critical to explain that they will need to make a decision and pick self-organization with responsibility or freedom outside the self-organized team.

Consequently, true self-organization means that people take full accountability for their actions and do what ever it takes to get organized as a group in order to operate within the imposed constraints.

Once presented with self-organization, people and teams quickly assume that they now fully control their destiny – which is incorrect. The additional detail that needs to be added is “within the imposed constraints” which means resources are limited and an objective has been established. So unless you are in control of the resources or have officially been delegated authority for the resources, you have the option of self-organizing, not becoming independent.

Ce message est à destination des gestionnaires, architectes, conseillers, directeurs, ou de toute autre personne ayant une fonction lui octroyant l’assurance d’avoir l’écoute des développeurs.

Si vous accueillez pour la première fois dans votre équipe des développeurs agiles, si vous collaborez pour la première fois avec une équipe agile, il est des réactions qui peuvent vous surprendre.

Je parle des moments ou vous vous voyez répondre un :

Pourquoi?
Dans quel but?
Qu’est ce que ça apporte?
Afin de…?

Avec un collègue français, on aimait aussi caricaturer ces moments avec le “Eeeeeeeeeet donc?” de nos collègues québécois, mais je m’égare, veuillez donc excuser cet interlude inter-culturel.

Pourquoi cette réaction vous surprend-t-elle? Parce que vous étiez, de par votre position dans l’organisation, habitué à ne pas avoir à convaincre un développeur. Après tout, vous aviez plus de responsabilités que les développeurs dans la conduite du projet. “Votre équipe” reconnaissait cette prise de responsabilité qui pouvait à n’en pas douter se retourner contre vous à la rencontre du premier obstacle, du premier échec.

Maintenant que l’équipe s’engage, qu’elle est responsable du projet, il faut vous attendre à voir chacune de vos décisions  discutées ou évaluées par cette même équipe.

L’insolence que l’on peut parfois ressentir d’un tel comportement peut fatiguer, on peut le trouver futile et chronophage. On aimerait bien trouver la switch et accélérer les choses, convaincre sans discuter, faire accepter sans confronter et finalement revenir comme AVANT. Il est pourtant garant d’une réussite partagée (entre chaque membre de l’équipe). Il est aussi synonyme de défi pour vous, pour votre position, et il permet aussi de s’améliorer en évitant de se reposer sur des préjugés, des reflexes et en prenant la bonne décision, en prodiguant le bon conseil, au bon moment.

J’aurais aimé avoir cette switch lors de certaines discussions, lors de certains projets. Je remercie aujourd’hui chaque personne qui l’a activée et qui me permet de m’améliorer.

Demand for software developers is unlikely to drop over coming years. I suspect the contrary is more likely to happen as demand for technology workers will continue to increase while North American universities produce less graduate developers.

That’s good news if you are a software developer as the demand is likely to continue exceeding the supply for many years. If you are on the market for a new job, your chances of finding another job are pretty good.

That’s also good news if you are an organization who offers software development services to customers. The trend showing that organizations are not staffing up to their full need and prefer to hire external temporary help (consultants) to complete their projects.

So all is well in this perfect world, right?

Well, it depends. If your goal is simply to get “a job” things are OK for you – send your resume to an organization that is recruiting and if you successfully go through the various steps of the recruiting process, you’re in. Congratulations! If at first you don’t succeed, try again a few more times and chances are you will get into one of the hiring organization.

If you are looking for interesting projects or projects inline with your personal goals and aspirations things might be more complicated. How do you ensure you are the one selected for that special project?

If you haven’t realized it yet, software developers are commodities. There simply isn’t much differentiation between software developers. I don’t mean to be disrespectful and as such, I won’t attempt to compare software developers to other commodities but the fact remains that there are very few ways to distinguish software developers.

In marketing, product differentiation is the process of distinguishing a product or offering from others, to make it more attractive to a particular target market. This involves differentiating it from competitors’ products as well as a firm’s own product offerings – Wikipedia.

The question that comes to mind is “What are you doing to stand out of the crowd?” and “What are your differentiating factors?”.

One differentiating factor that is slowly appearing in job descriptions is the requirement for “Agile software developers”. Although a step in the right direction, this is likely to mean very little in the near future as the definition of an agile software developer still needs to be agreed upon.

If you are part of an organization that offers software development services, what are your differentiating factors? Ours is simple, we offer immersion and highly performing software development teams that are ready to make a substantial impact from day 1.

What are your differentiating factors?

C’est avec grand plaisir que j’ai accepté l’invitation d’Éric à participer à leur première rétrospective. Un projet dont l’objectif est de déposer une offre de développement ET un incrément de logiciel pour le client, c’est quand même pas tous les jours qu’on voit ça!

Je prends donc ici quelques lignes pour vous faire part d’un échange avec Xavier lors de cette rétro.

André: Et puis Xavier, c’est particulier une offre de service qui inclut du logiciel fonctionnel, qu’est-ce que tu retiens de cette première itération?

Xavier: Expérience intéressante.  Ça a été un challenge de partir de ce point de départ sans avoir un accès continu au client.  D’un autre coté, le fait qu’il s’agisse d’une évolution d’une application existante grand public, ça nous aide car on peut aller voir quel est le contexte de départ, sans avoir besoin d’organiser une rencontre ou de se déplacer.

Une autre chose qui était intéressante étant donné ce contexte de working proposal, c’est que ça nous a amené à retravailler la condition du done, surtout en ce qui concerne les données déployées avec les versions de l’application.  Nous avons décidé de déployer des données réelles pour permettre au client d’avoir un meilleur feeling de ce que serait (sera)(est )  son application.

André: Intéressant.  Est-ce qu’il y a d’autres aspects techniques que ce working proposal vous a appris ?

Xavier: Absolument.  Dans un contexte ou nous devons démontrer rapidement de la business value, nous avons décidé d’utiliser l’environnement de Ruby on Rails et de déployer les versions intermédiaires du logiciel sur Heroku.  Le choix d’Heroku est très intéressant car il nous a permis de facilement permettre au client d’utiliser le logiciel.

André: Et finalement, comment entrevois-tu la prochaine itération?

Xavier: En enrichissant la fonctionnalité déjà livrée, en en ajoutant une nouvelle.  Tout ça en pilotant le développement par les tests, parce qu’il ne faut pas l’oublier, ce n’est pas un prototype mais du working software.  On s’attend aussi dans cette itération à améliorer notre compréhension de comment le client travaille, de manière a être mieux outillé pour lui faciliter la vie.

André: Et bien c’est super! Il ne me reste plus qu’a te souhaiter une bonne seconde itération !