Motiver des équipes agiles (et les autres...)

Préambule : Ce post est la traduction d’un autre post d'Aaron Bjork Principal PM chez Microsoft.
Merci à Visual Studio Magazine de m'avoir autorisé à traduire cet article

Article original : Motivating an Agile Team


Aaron Bjork nous  parle de la façon de motiver vos équipes agiles sans les entraver.

La première, et probablement la plus importante déclaration dans le Manifeste Agile, parle directement aux équipes de développement: 

Les individus et leurs interactions sont plus important que les processus et les outils.

En résumé, les gens sont plus importants que toute autre chose.

Etrange introduction de la part d'un 'tools guy', puisque je travaille chez Microsoft en tant que Program Manager sur Team Foundation Server et Visual Studio. Il ne fait aucun doute que je veux que les équipes de développement utilisent ces outils que je fabrique.

Toutefois, il serait idiot de suggérer que les équipes vont réussir grâce aux outils à leur disposition.

Comme le Manifeste Agile l’indique clairement, le succès de l'équipe est d'abord assuré par la valorisation des membres de l'équipe et par leurs interactions. Les  outils et processus sont importants, mais ils ne sont pas plus importants que l'équipe elle-même.
 

Cet accent mis sur les gens est une raison majeur pourquoi j'aime la méthode Agile.

Elle nous dit de sortir les outils de nos esprits et de regarder l'équipe qui nous entoure.

Elle nous dit que si nous voulons trouver ce trésor au pied de l’arc en ciel du développement de logiciels, nous devons travailler ensemble et valoriser chacun d’entre nous.

Elle nous dit que le succès dépend de l'équipe.

L'année dernière, j'ai lu un livre écrit par Dan Pink intitulé "Drive: The Surprising Truth About What Motivates Us".

Ce fut une lecture fascinante, un de ces livres que l’on ne peut pas refermer; je le recommande à tous. Je me souviens de nombreuses soirées où je m'arrêtais mi-chapitre pour dire à ma femme: "Ecoute ça", avant de lui lire à haute voix une partie de l'ouvrage. Elle m’a finalement dit qu'elle le lira quand je l’aurai terminé, et m'a donc demandé d'économiser ma salive.

Ce livre m'a captivé, et il m'a ouvert les yeux sur certaines vérités concernant la motivation.

Dans Drive, Pink met en opposition les techniques de motivations traditionnelles (récompenses et punitions), avec trois nouveaux principes essentiels à la motivation dans les industries innovantes : autonomie, maitrise et objectif.

L'idée, c’est que les gens recherchent ces trois caractéristiques dans tout ce qu'ils font, et quand ils les trouvent, des bonnes choses se réalisent.

Dans ce post, je veux expliquer rapidement pourquoi  l'autonomie, la maîtrise et l'objectif sont essentiels à la  constitution d’une équipe agile saine.

Autonomie.

Le premier principe présenté par Pink est l'autonomie: la capacité de chacun à prendre ses propres décisions.

Pour une équipe de développement de logiciels, c’est essentiel.

Une équipe a besoin de se sentir responsable, et une équipe a besoin d'être responsabilisés. Pourquoi? Parce Agile nous enseigne que le changement est inévitable lors du processus de développement logiciel.

Dès le moment où l’équipe a démarré, elle va apprendre sur le produit,  sur l'architecture, et sur les clients. L'équipe doit se sentir habilitée à réagir au changement et à communiquer sur ce qu'elle est en train d’apprendre.

Cela ne signifie pas que l'équipe doit pouvoir faire ce qu'elle veut, mais plutôt, qu’elle a la liberté de faire ce qui est juste.

Une équipe manquant d'autonomie est plus susceptible de suivre aveuglément un plan transmis par le haut, tout en ignorant la réflexion critique.

Maîtrise.

Le concept de maîtrise est assez simple: les gens veulent apprendre à mieux faire ce qu'ils font.

Nous trouvons cela dans tous les domaines de la vie.

Une partie de notre ADN nous donne l’envie de nous améliorer. Les tout-petits travaillent sans relâche pour maîtriser l'art de la marche. Ils n’ont, généralement, besoin que d’un peu d'encouragements. Par nature, ils ont un réel désir de maîtriser la marche, et ils y travaillent jusqu'à ce que ça devienne une seconde nature.

Cela ne change pas en vieillissant. J'aime jouer au golf, et j'aimerais être un meilleur golfeur, année après année. Cette amélioration est une partie de mon amour pour ce jeu. Je ne suis certainement pas un maître (ma carrière sur le PGA Tour ne s’est pas encore concrétisée), mais je continue à m'entrainer pour m’améliorer, trou après trou, tour après tour, et année après année. Le processus et les résultats sont tous deux exaltants.

Les équipes de développement ne sont pas différentes.

Toute équipe dispose d'un goût naturel pour trouver des nouvelles et meilleures façons pour accomplir son objectif.

Les membres de l'équipe aiment écrire des logiciels et ils aiment résoudre des problèmes difficiles. S’ils n’aimaient pas cela, ils ne travailleraient pas dans un secteur difficile.

Ils sont motivés par le défi et l'art de bâtir une solution élégante et fonctionnelle.

Cependant, trop souvent, nous traitons les équipes et leurs membres comme s'ils étaient des pions sur un échiquier qui peuvent être déplacés, décalés et changés sans conséquences. Nous remanions les ressources, nous changeons les objectifs et nous chamboulons leurs priorités. En faisant cela, nous enlevons leur capacité à devenir maîtres. C'est un modèle que je vois répété encore et encore dans notre industrie.

Objectif.

Ce dernier principe énoncé par Pink est l’Objectif.

Les équipes ont un profond désir de comprendre comment leur travail s'inscrit dans une vue d’ensemble. En tant qu'ingénieur, je veux comprendre à quoi le logiciel que je vais construire va servir.

Nous avons besoin d'une raison et d’un objectif.

En tant que leader dans votre organisation, trouver des façons de vous assurer que votre équipe sait que ce qu'elle produit est de contribuer au business.

Communiquer à propos de l'importance des nouvelles fonctionnalités livrées dans le dernier sprint. Montrez-leur les clients ravis utilisant leurs solutions. 

Trop souvent, nous déconnectons  nos équipes de développement du business et des clients.

Nous le faisons parce que nous pensons cela ne les intéresse pas, ou nous ne voulons les distraire avec ça.

Mais, le plus souvent, nous finissons par les aliéner et par détruire leur sens de l’objectif.

Conclusion

A mesure que vos équipes grandissent, mûrissent et s'efforcent d'être plus agile,  travaillez pour créer un environnement « autonomie, maîtrise et objectif ».

Je n'ai aucun doute que vous témoignerez, à mesure que vous avancerez, d’améliorations sur le moral, dans l’innovation et l'efficacité.

My method : a Task driven and scored method

Pragmatic Task-driven & scored method

Historic

For years, I have used a pragmatic method for producing software in small companies with small teams.

In this context, I always wore many hats: product manager, project manager, R&D manager and lead senior programmer. In this post, I resume these roles as a "manager", a multi-hats manager, capable of multitasking...

Without a lightweight and self-propelled system, it would have been very difficult to do my job.

More than an "innovative and revolutionary" method, it's rather a blend of good practice and pragmatism. It is mainly based on the classic "Agile Methodology", but adapted to very versatile "mini-teams".

With a lot of different roles tp juggle, I had to make choices and fix priorities.

It is not the quantity of work that determines the success of a project: it’s the quality of the work, the organization, the commitment of its team and passions for the product.

In various management roles, I overlooked features kept only the essentials:

·         Product manager: inspired by Agile Method, no big and formal requirement, just short and explicit specifications, the famous "user stories"

·         Product manager: no planning, just cutouts of "user stories» in tasks, and priority estimations. These tasks allow a self-management by the team, headed by the tasks and priorities, but without imposed order.

Task-driven & Task-centric

The Tasks

My method is based on tasks and autonomy of the team and its members.

The key is the possibility or rather, the duty of developers to choose the tasks they want to realize, according to their inspirations, their skills, their moods or their ambitions.

Having a choice in the selection of tasks gives great autonomy to team members and allows them to adjust their efforts and aspirations in order to achieve greater productivity.

When developer choses his own job, he does it according to some criteria:

·         Its relevance to the topic of the task:

"Look, this task looks interesting; it's really in my skills"

Example +: good expertise on the topic => good productivity and satisfaction

Example -: challenge may fail=> poor productivity and loss of confidence

·         The state of fatigue and motivation:

« I am very tired this week, I'll do all spelling corrections and forms alignment »

Example +: choice of short and fast tasks => remaining productivity

Example -: confinement in a long task without the requisite skills => decreased productivity

In order for a developement team to achieve the goal of delivering high quality software within the given delay. The ability of team member to express their free will within the organization can help preserve high productivity and positive motivation, despite long work hours or other organizational issues.

In this context, the manager can (I would even say should) assign himself tasks, and assign the score to the team, thus the manager plays a support role to his team.

Scheduling

It does not exist as such. Only a few milestones are fixed.

As I use Agile principles, my milestones are end sprint and end of the release dates.

I don't know whahat project respects its deadline just because it was scheduled, but rather because the project team was mobilized on a clear and shared goal: the deadline.

The detailed planning of all tasks is often a way for all stakeholders in the project to reassure themselves.

To borrow a citation from Reworks: « Planning is guessing ».

The manager's role is to lead and motivate the team to keep those deadlines.

But above all, its role is to properly quantify the number of tasks and difficulties in order to "fit" in the sprint or release.

The realism in the estimation of labor to provide is a key point of the job of manager of development team.

«I think I know what I'll do this week, but what imponderables will fall on me and change my beautiful schedule? »

Let's move on, since I'd much rather talk about targets, and goal dates.

The Goal: Little Reminders

The goal of every development team is:

To deliver high quality software within a set period of time

Only reach the goal, reach objective, and for that alone the motivation, mobilization around the goal are the keys.

Even though autonomy via choice and the exercising of free will are the basis of this method, the manager must be able to assign and impose choices and decisions to team members to benefit the project, and especially with the objective of achieving the goal.

How do you reach the goal? Finishing and testing all tasks. Everything evolves around the tasks.

So despite a form of self-management for developers, the manager is still the manager.

New feature: the Score

Why a Score?

My idea is that the motivation of team members can be animated and boosted by providing them with a score per a given period (week, month, release, sprint, etc... according with the organization).

"My method" has its limitations, particularly due to the lack of measures of performance and evaluation of team members. And without indicators, there are no axes for improvement, thus no proactive detection of malfunctions.

The idea of scoring induces a small degree of competitivity that can stimulate a team, help it to advance.

Score using

By team

A minimum average score (MAS) per team member is given. A minimum score to be achieved should also be set to encourage teamwork.

The ideal is to set a reward for each MAS reached, individual and collective, thus rewarding individual effort and collective efforts. This difference between "individual" and "collective" is important; a member who provides great efforts and obtains a good score shouldn't to be penalized by the poor performance of the team.

On the other hand, if the overall, team productivity was good, everyone should be rewarded so that nobody feels excluded, even if an individuals on the team wasn't as involved as other in the effort achieved.

At the end of each period, an analysis of the worst score should be made ​​in a positive spirit.
It is necessary to rule out "bad scores”, low scores obtained because of personal or external factors (eg sick = bad score).

By the manager

It helps to estimate tasks.

The score is very similar to the velocity (based on points of Agile user-stories), and therefore allows its use for planning sprints and releases.

Score Definition

The score of a task is the result of a calculation based on criteria. It is used to tell developers how many points they will win in performing those tasks.

There are three criteria with three values ​​that determine the score of the task.

Expert level:

Easy= 1, Normal=3, Hard=5

Task duration:

Short=1, Normal=3, Long=5

Task priority:

Low=1, Normal=3, High=5

Subjectivity in the evaluation.

Though it exists it is limited due to the low number of choices and task choice's transparency. In case of disagreement, the choices should be debatable by all team members and at any time of the process, even when it is completed. Most important thing is that this disagreement is motivated.

Exceptionally, like the "planning poker", the "scoring" can be collective, by imitating the same method as the "planning poker".

What’s next

Some tools

I haven't found a tool for management based on the scores. For the task-driven management, a number of tools are avalaible and I've only used or evaluated:

TFS, Mantis, Jira and the very promising Asana

My Choice  : TFS

I find that the integration of TFS and Visual Studio on the wholes makes a formidable platform for productivity and efficiency.

What I also like in the TFS is the idea of being able to relate the code "WorkItems" including archiving (check-out), which is an aspect I beleive is lacking in Mantis.

TFS is a very good source controller but the management of "WorkItems"is not adapted to managing with task-driven method and it does not handle scoring, so I'm working on a web interface and a "process template" which will correlate well with my method of work.

That’s what the project ScrumPilot is about

ScrumPilot

ScrumPilot's initial idea was to create a simple, more user-friendly dashboard than those that exist.

Stitches in time, I have added read-only "workitems, projects and users" features.

At this point, with my best understanding of the TFS API facetious and with a little elbow grease, I should be able to make a mix between Mantis and Asana, TFS, my method and my scoring to give a "small agile teams focused on tasks" varnish to the TFS

There will be another more detailed article when I will make progress on it.