Seminaire sur l’agilité à Limoges
Ca fait quelques temps qu’on parle d’agilité hors du sérail parisien, avec les SigmaT à Toulouse, avec l’Agile Tour un peu partout en France… C’est maintenant le cas à Limoges puisque l’IUT du Limousin, en partenariat avec le pôle de compétitivité Elopsys, organise un séminaire gratuit d’information sur les méthodes agiles le vendredi 26 Février 2010 de 16h15 à 19h30.
Ce séminaire s’adresse à toute personne désirant découvrir ou mieux connaître le développement agile : étudiants, développeurs, chefs de projet, DSI, clients et utilisateurs de l ’outil informatique. Il a pour but de vous présenter les méthodes agiles, d’apporter des réponses concrètes aux questions que vous pouvez vous poser et de permettre les échanges entre participants.
J’y serais puisque j’aide à l’organisation de l’événement et ferais une petite présentation. Ca me fera très plaisir de reparler un peu d’agilité et de pouvoir échanger sur Limoges. On y retrouvera Thierry Cros, Claude Aubry et Bénédicte Taillebois qui nous fait l’amabilité de venir parler de son expérience en matière de transformation agile à la DSI d’Astria.
Retrouvez le programme détaillé sur le site de l’IUT et inscrivez-vous ici
Et peut-etre bientôt, comme le dit Claude, un groupe de praticiens agiles sur Limoges… En tout cas, on vous réserve une surprise !
Reflections on Kanban and Iterations
As you may noticed, it’s not the first time I mention Jeff Patton’s work. In this post, I’m writing in answer to Jeff Patton’s last article “Kanban oversimplified”, which is a direct and concrete presentation of Kanban concepts. So if you haven’t read it, click “Kanban oversimplified” and do so, before reading further…
With the teams I work with, we usually include rows in the kanban for ready stories (after ux) and another one for validation, we limit the work in progress (wip), we try to shorten our cycle time and to identify the bottlenecks, but we continue to use iterations, and to keep track of velocity for planning purposes…
Pull your stories with a kanban and limit your WiP.
So the core of his article all makes sense to me. But when as a preamble Jeff talks about smaller stories, I still had the feeling that it only said half the story… So here’s my constructive reply, hoping that because I’m a frenchman it won’t look too much like criticism =;] …
Jeff tells us that there’s a pressure towards shrinking stories for easier estimation and planning. It’s something that I’ve witnessed and I agree that there can be pression to shrink stories.
In addition to estimation and planning, I’d mention the tendency that some organizations may have to “study” and “research” a lot around the business (or ux) side of stories before implementation. This may result in overdesign often characterized by small solution-oriented stories… But I hear you saying that this kind of phased research only occurs in organizations without transdisciplinary teams and they are not very agile… You’re right.
One nice side effect is there’s easier room for only half a story to complete at the end of an iteration. Well then you only have time to begin it, you won’t demo it this iteration but only on next one. But hey wait, you’ll have a slower velocity this time and a faster one after ? And then ?… Remember : velocity as any measure (such as throughput) only has meaning once averaged over time. And of course there’s no short-sighted velocity-obsessed manager around pressing you into producing crappy code… Because you’ve watched screencasts of Uncle Bob. Because you are professionals.
Ok, so far so good : there’s a tendency to shrink down stories for not so good reasons. Then Jeff begins to criticize using small stories. And this is where I want to raise some other arguments.
First, smaller stories means a bigger backog. Yes I agree, but how much bigger ? You’re surely trying to limit your stock, so you don’t cut/slice your stories very long in advance. So you’ve got lots of epics that you know you’ll have to split later. And a few smaller ones but only for 2 maybe 3 iterations in advance, which doesn’t make your backlog explose. Ok, you can go further and introduce a formal fixed limit to the number of stories to be considered for dev and then slice you epics just in time… As long as you pay attention to your stock…
Let me explain why by saying that I like small stories ! Small, ok but how small ? Certainly small enough not to always be MMF’s. Why ? Because I want to be able to slice my stories according to various degrees of service. And I want to have the choice between delivering a broad range of shallow features or delivering a deep and refined feature. I want to have the possibility to push a very basic feature to users, get feedback from them, learn about how we managed to do that, and maybe change my mind.
MMF’s are good… but keep using small stories as opportunities to learn and adapt.
Having big stories is nice when you’re sure which ones you want to push out, when you’re sure about what has to be delivered. As often quoted : “knowing precisely what to build is the hardest single part when building software”. I see small stories as an opportunity to learn more about what to build. I see it as an opportunity to choose how iteratively/incrementaly my application will be built. But this way, not all my stories will be big or refined enough “to be announced on the corporate blog”, and I’m fine with that.
Another interesting point mentioned by Jeff is the nature of activities on the product owner side. Those activities, dealing with both business logic and user experience, are threefold : * researching about future stories to be developped, * validating developped stories, * conversation with developpers on stories being developped. Keeping a good balance between all three sure requires constant attention. As this cannot usually be carried out by one single person, it also requires careful communication and synchronisation. I’ve found that often not enough time is invested around one central coordination focus spot such as the kanban board. In my experience combining the use of a kanban and of a storymap enables you to balance a short tactical and a longer strategic perspectives.
Balance strategy and tactic by using a storymap and a kanban.
So in the end, this is all highly theoretical as Jeff and I haven’t worked together on a real project, writing and organizing stories… Maybe his big stories are my small ones, who knows ? Or maybe we’ll someday have the opportunity to work together and solve this in front of a storymap and kanban board…
We hear lots of discussions around iterations about whether they are needed or not. The argument is : they just prevent us from getting some fast feedback. This is a non issue : iterations or not, you’ll still need to have these conversations to refine things that are unclear, apart from having a clear Definition of Done. And you can still interrupt your iteration or reorder your backlog if needed. If it happens and if it’s a big deal : it doesn’t mean that iterations are getting in your way. It means that you may have some problems with your PO and the way you regularly manage your backlog.
So, in my opinion, iterations are actually quite useful. The first quality of having fixed length iterations is that it establishes a rhythm and makes room for rituals. Whatever might happen, every other week, the team will demo the new features of a working product. You can’t escape that and it helps avoiding the student syndrom. However busy they’ll be and even if they don’t show up, sponsors and clients will know about this rythm. And this rythm is not only about the demo. It’s also about taking some time to groom the backlog, taking into account new information learned on the course, whether about the market or the building itself. It’s also about taking some steady regular time to inspect and adapt during retrospectives. Having iterations says : we don’t build software without reflecting on our process. This is at the heart of Lean.
Use iterations to create a rythm for all stakeholders
One argument is that, instead of using velocity and losing time at estimation, you could use can use cycle time for planning and still predict how much time it’ll take to complete the bunch of stories in the roadmap. Yes I agree that for most planning, some close enough approximation is mostly good enough.
Actually, estimation is good because it enables you to grasp the various complexities behind building (and not only developing) a feature : business, ux, development… Having all these people in the same room and doing planning poker keep things efficient without taking too much time. Doing that, you’ve got the opportunity to balance all those perspectives and make trade-offs… Maybe there’s a simple solution that will be good enough. Or maybe you hadn’t anticipated all the technical difficulties behind this nice and minimal gui…
Planning poker is more important for conversations about what to build than for planning
I actually see more value from planning poker as a basis for discussion rather that as a basis for planning. And for the same price you’ve got some relative estimation of stories that you can use for planning purposes anyway.
Here you are. I hope I manage not to fall in the “Kanban vs. Scrum” “named cloud” trap described by Ron Jeffries. I hope you’ll pay attention to your WiP and cycle time, use a kanban board and learn about lean. I also hope that in the end you’ll think again about several things : * iterations are not only about timeboxing but also play a role as rituals for establishing a rythm for all stakeholders * how you write and slice your stories is not only about delivering value but also about feedback, learning and managing risks.
Design with User-Stories - the curse of the technical/UI story !
No Technical or UI Stories
I’ve been hearing lots of conversations or read posts lately where people mention “technical stories. We even can spot some of these “technical stories” in the invaluable Scrum and Xp From the Trenches, p9 . And reading this thread on agile UCD made me react on this concept of “UI stories” ! To me, it makes the same feeling as “technical stories” do : it makes me shudder !
As I see it, a story is something across all layers that “provides some value” to a user. Let’s rephrase it : “something that brings an actor using the software closer to (at least one of) its goal(s)”. Stories should stay “above the water”, as mentioned in Cockburn’s Writing Effective Use Cases . They should avoid dealing too much with the solution and focus on dealing with a problem the user has.
User-stories should stay “above the water”
Some people write “technical stories” to creating a new table in a DB or add a button. These are not stories, but merely tasks that need to be done in one solution to such stories. Actually, I consider it pointless to talk about anything other than “User(/actor) Stories” (actor because stakeholders, admins, deployment and other software also interact with the product). Since Kent Beck coined the term “user story” and thanks to Mike Cohn’s book spreading the use, working with stories was imho a great step as it brought back some focus on the user side, away from “the system shall…”. Let’s not forget that.
That being said, it’s true that some stories have a greater focus on usage (and thus the UI), some on a complex business logic, some involve technical feats underneath… But all should be user stories.
USER stories
What are user-stories ? It’s not just about using flashy post-it notes or cards, to prevent us from writing lengthy specs to bury somewhere. It’s not just about doing things fast and dirty. It’s not a matter of dividing the work to come in “sprint items”. It’s a matter of design.
User Stories should be the focal point (as illustrated in this article about the product owner), enabling communication between all perspectives : UX, design, dev… Here I’m using the term “design” on intent, refering to its two perspectives, as in “apple products have a great design” and “a well refactored oo design”. These two perspectives are not opposite. They are the two sides of the same coin.
User-stories should be the focal point between all perspectives
Design is finding a solution to a problem. User-stories enable us to have conversations (as in cards, conversation, confirmation by Ron Jeffries) about design : how do we solve things for users ! They are anchors for conversations
So, how we phrase user-stories, how we slice them (like Maven and Motley), how we picture them should not be dealt carelessly !
Organizing stories
First, how do we picture and organize them ? For that, storymaps are a great concept that have been gaining popularity lately thanks to InfoQ, initially brought forward by Jeff Patton and Todd Warfel through his Task Analysis grid. Whereas a classical backlog is a 1-dimensional list of stories, storymaps help you organise them in two dimensions. On a horizontal axis, the workflow of user activities. On a vertical one, the necessity of stories, from bare necessities to luxury.
Do you try to avoid building your application in a horizontal component-layered structure one component at a time, to favor a vertical one providing some value to the user across all layers ? Just step back and there you can see the vertical slices of your application. This helps a lot ! You can still have horizontal slices but they have a different meaning. You use them to iterate and refine features.
User-stories are organised in a storymap
This provides a big picture of features for a whole product, enables you to outline a functional roadmap. I also use that to visualize and litterally pinpoint risks… I’m curious of your experience : any other usage of your storymaps ? The backlog is dead : long live the storymap !
Phrasing stories
Let’s focus a little about specifically on how to phrase them. So, my user-stories don’t look like those for instance of the story card template described by Scott Dunn, or like the standard “as a
You don’t have to state why its’s valuable to the business because you only write one when answering one need of an actor toward its goal. Should we begin by considering technical constraints, as usual from an architect perspective, as most IT departments do ? My answer is a clear NO !
I prefer to see how technical constraints and risks map on the functional and incremental view of the product : the storymap.The order by which you pick up stories is made obvious through a storymap by outlining a release plan.
Dealing with constraints
User-stories should not mention the tool, that is the UI or the technical solution used : this should only feed the constraints, whether directly in the DoD (for the french crowd) (Definition of Done) or for specific stories. If it’s not obvious to you, yes UX (user experience) considerations should also appear in the DoD.
Constraints are for the validation part of User-stories
Any business rule/data requirement/whatever constraint (UX, performance, *ity) is specified in the validation part of the story. This should be succinct enough to fit in one or two lines of an spreadsheet cell. If not, work on stating clearly what is the intent behind and question that. When dealing with a business logic that is not straightforward, this is all transposed in some acceptance tests one iteration at a time, ready for discussion at sprint planning time. Of course, there are some issues uncovering some potential complexity that have to be anticipated. Anyone remembers the work on software reuse from the 90’s and axis of variability ? Discussions on design again !
What process do I follow ?
So how do I use user-stories ? I first define the actors and their objectives, which is a first take at personas, that may be refined later. Other actors or roles may be later added or divided into more specific roles or profiles, but franckly, the few ones appearing at the first pass will already provide you lots of insights.
As all cards refer to at least one actor whose goal has been stated, the value doesn’t have to be stated for each story : away the “in order to” from the canonical from. They can thus focus on the action part of the story. A little step toward literally drawing stories : a symbole or picture in a top corner of a card is a good way to do that. Directly using names of personas is a very good idea that I’ll use next time ! Any card that doesn’t provide and fit in an actor’s goal will be thrashed, it’s as simple as that. They are grouped into activities, ordered by necessity, may be sliced with varying “conditions of validation” from a minimal service to the full monty. They are then estimated on a “just-in-time” basis for the next release, that is one or two iterations in advance.
User-stories enable us to have conversations about design
All this is subject to lots of conversations. The cards may be rephrased as the intent behind the stories becomes clearer. As the solution for a problem of a user becomes clearer. As the design becomes clearer.
I emphasized the importance of user-stories, as a support for conversations for design. But knowing that we’re visual animals, I’m also convinced (thanks to Dan Roam talks ) that we must use more our visual potential. Crafting “Product Boxes” is a one step toward that. Appart from traditional oo diagrams and other potatoids, I’m convinced that we should draw more to support our designs.
Any examples of what and how you draw to support your stories / your designs ?
Agilité : utopie du consensus ?
En réponse à l’article d’Emmanuel Chenu sur les critiques courantes faites à l’agilité, j’essaie de revenir pour 2009 derrière le clavier pour mon blog. Emmanuel, dans son article, répond à tout un ensemble d’idées fausses : manque de rigueur, absence de conception notamment… Assez d’accord sur l’ensemble des arguments qu’il apporte, je réagis sur le dernier point qu’il aborde : “Ces démarches vivent sur l’utopie du consensus dans l’équipe”.
On évoque la notion de consensus pour les équipes agiles, parce que celles-ci mettent en avant l’idée d’équipes auto organisées, portant collectivement les décisions prises. Equipes auto-organisées, où chacun dans le groupe est prêt à accepter les opinions divergentes et à faire le deuil de ses positions, privilégiant l’écoute et le dialogue plutôt que la discussion, où chacun cherche à faire triompher son opinion.
Cela ne se fait pas bien sur sans travailler à long terme sur la dynamique d’équipe, point sur lequel l’agilité met justement l’accent.
Concrètement, je connais peu d’équipes qui évoluent sur un mode purement collectiviste, indépendamment de toute autorié susceptible de trancher. Dans les faits, questions de hiérarchie mise à part, il y a souvent un expert qui fait autorité sur le sujet et qui départage les positions. Par contre, il peut arriver que la personne en position n’ose pas assumer son rôle et trancher justement. Ça nous ramène à la question du courage et de la responsabilité individuelle.
Au niveau de l’équipe, il ne peut y avoir de responsabilité collective que si chacun assume sa part de responsabilité individuelle.
Aparté systémique sur la question. On peut étendre ces questions de responsabilité à tout système : l’organisation, la société, le couple… En l’absence de responsabilité individuelle, on obtient que de l’irresponsabilité collective et pas grand chose de bon. Alors quelles considérations pour qu’un système tourne un peu ? S’entendre sur les valeurs qui unissent les parties, s’assumer soi en respectant l’autre dans son individualité et être prêt à l’introspection individuelle et collective… D’aparté systémique en réflexion personnelle. En fait, je pensais au couple parce que je n’ai justement pas été exemplaire récemment, que j’en constate directement les conséquences et que la question était là omniprésente à mon esprit ; certains auront lu “société” et ça me va ; les autres auront lu “équipe” sans que la digression nuise trop au propos j’espère.
Revenons à nos moutons et à la notion de consensus pour lui tordre un peu le cou. Non une équipe agile n’est pas guidée par la recherche du consensus. Le consensus est un effet de bord de son auto organisation. Par contre l’équipe agile est guidée par la volonté de délivrer de la valeur à son client, dans le respect des valeurs qui l’anime.
Dans le doute, c’est donc la voix du client, du responsable produit qui tranchera toujours, guidé par les autres expertises (notamment techniques) nécessaires.
Vous me direz, et si cette décision est en opposition avec le processus/l’équipe ? Le scrummaster, le coach est justement là pour protéger l’équipe. Encore une manière agile de gérer la chose : deux responsables distincts pour deux dimensions orthogonales : celle lié aux objectifs produit et celle liée au processus et à la dynamique d’équipe. Une façon d’éviter la schizophrénie usuelle du chef de projet (celui qui n’a pas renoncé à l’idée de prendre soin de son équipe en tout cas). Mais lorsque l’on en arrive là, à une opposition entre ces deux perspectives, c’est vraisemblablement qu’il y a un problème d’alignement entre les objectifs du produit et l’équipe qui le porte, et que l’on a peut être pas compris que l’un ne va pas sans l’autre.
C’est justement une des clés de voute de l’agilité : Produit = Equipe !
Voila sur l’utopie du consensus. Pour tout dire, l’appétit vient en bloguant et j’ai maintenant aussi envie de réagir sur un autre point : la vision à long terme. Ca me fera l’occasion de bloguer de nouveau. Comme quoi, si vous n’avez pas blogué depuis longtemps, n’hésitez pas à réagir sur ce post =;]
Coopérer : être plus efficace et mieux vivre face au changement
Merci à tous ceux qui ont répondu à cette étude en psychosociologie sur les impacts de la coopération. Les nombreuses réponses à travers le monde (plus de 260 dans une vingtaine de pays) ont permis d’aboutir à des résultats très clairs.
Ceux-ci sont présentés dans le mémoire (Document .pdf) de Delphine Allin : “Comment concilier performances et bien-être au travail ? Les effets de la culture organisationnelle coopérative sur les comportements citoyens organisationnels, la performance adaptative et l’épuisement professionnel.”
Qu’est-ce qu’on peut en retenir dans une perspective agile ?
Tout d’abord l’étude montre clairement que les employés d’organisations basées sur une culture coopérative souffrent de moins d’épuisement et ont de meilleures performances adaptatives. Ils sont en effet plus efficaces pour la résolution créative des problèmes, la gestion de l’incertitude et de l’imprévisible, l’apprentissage de nouvelles tâches, technologies ou procédures, et la gestion du stress et des situations de crise.
Pour ce qui est des entreprises agiles, on constate que les employés ont une plus grande loyauté : ils ont plus tendance à agir de façon innovante pour améliorer le fonctionnement du département ou à travailler au-delà de ce qui est attendu. Sans doute le reflet d’équipe autonomes et responsabilisées (”empowered” en anglais), capables de réfléchir sur leurs pratiques.
Etonnament, on constate une absence de lien spécifique entre agilité et à la fois la culture organisationnelle coopérative et performances adaptatives. C’est surprenant au regard du manifeste agile !…
Plusieurs raisons à cela. Tout d’abord le fait que, selon le modèle utilisé dans l’étude, les entreprises agiles mixent des caractéristiques de plusieurs cultures différentes, en étant non seulement centrées sur le groupe, mais aussi sur les besoins du client et avec un parti pris d’innovation et de réactivité au changement. L’agilité, ce ne sont pas que des équipes auto-organisées, mais aussi des équipes coopérant avec le client pour la production rapide de valeur.
La deuxième raison vient sans doute du fait que les équipes agiles font partie d’organisations plus larges dont la culture n’est pas cooperative. D’où l’importance de ne pas faire évoluer les comportements vers plus d’agilité qu’au sein des équipes, mais d’infuser au-delà dans les modèles de pensée et de fonctionnement, notamment des équipes dirigeantes.
La coopération : une stratégie gagnante ! Cela veut dire des équipes moins fatiguées et mieux à même d’être efficaces faces à des situations nouvelles. En fait, on en revient à ce qui est montré par le dilemme du prisonnier : j’ai tout intérêt à coopérer, à condition d’être dans cadre propice à la confiance.
Coopérer : travailler mieux pour vivre mieux ?
Tout est dit dans le titre ! Voila une étude internationale qui va s’intéresser aux effets de la coopération sur les conditions de travail, et leurs répercussions sur les comportements citoyens, la performance, les réactions de stress et de burnout.
Pour cela, il suffit de répondre au questionnaire ici (en anglais).
Les résultats devraient permettre d’en savoir un peu plus sur le sujet, peu exploité, de la coopération. Ca devrait aussi permettre de répondre a la question : les équipes agiles sont-elles vraiment plus coopératives ? Quelles conséquences pour les collaborateurs ?
Vous avez un avis sur la question ? Ca m’intéresse !
Comment libérer les projets du triangle de fer
Lorsque je fais le point avec un client sur la situation de son organisation, on en arrive souvent à faire un même constat : les équipes sont à fond en production, cravachent dur pour livrer tout ce qui est dans le cahier des charges et tenir les délais. Trop de fonctionnalités, trop peu de temps… des previsions ne seraient-ce qu’un peu depassées et les marges diminuent… Ce n’est pas l’envie qui manque de developper d’autres axes, mais le temps manque tout simplement. On est pris dans le triangle de fer !
Le triangle de fer
Parmi les décideurs d’un projet, chacune des parties prenantes a une perspective différente sur le projet : * la perspective financière qui cherche à obtenir un produit/système à moindre coût, * la perspective managériale dont le but est de respecter les délais et de manager les personnes. Cela se résume dans la figure suivante, dite du “triangle de fer”.
La réussite d’un projet repose donc sur la satisfaction de ces trois critères : livrer l’ensemble des fonctionnalités, dans les délais et au budget prévu.
Faire varier les ressources ?
Ce triangle est qualifié de triangle de fer car il ne peut évoluer. Un projet doit aboutir dans les délais en livrant l’ensemble des fonctionnalités. Classiquement, la seule variable d’adaptation sur laquelle on peut jouer passe donc par l’ajustement des ressources.
Si les délais et le périmètre sont fixes et que le projet prend du retard, on peut alors avoir l’impression qu’assigner des personnes supplémentaires permettra de résoudre les problèmes et de livrer dans les temps. C’est le genre de solution d’autant plus facile lorsque l’on dispose d’une ressource abondante (et les mauvaises langues diront corvéable à merci =;]) : on rajoute des stagiaires. Toutefois, cette approche a des limites. Comme on dit : “9 femmes ne peuvent avoir un enfant en 1 mois” .
On sait, notamment depuis le livre “Mythical Man-Month” de Brooks que le fait de rajouter des personnes sur un projet en retard est d’ailleurs avant tout une source de complexification et d’échec des projets. Comme il le dit lui-même “Adding people to a late project makes it later.”
“Rajouter des personnes sur un projet en retard ne fait que le retarder d’avantage.”
Ca parait bête à dire, mai les ressources humaines ne sont pas interchangeables. Ou alors seulement dans le cas de projets sans vraies contraintes de ressources, de délais ou de complexité.
Une dimension cachée : la qualité
Le triangle de fer contient une dimension cachée, implicite : la qualité. Ce n’est plus un triangle : c’est une pyramide ! Autant il est facile de quantifier les ressources, de surveiller les délais ou de lister les fonctionnalités, autant pour évaluer et garantir la qualité d’un projet informatique, on entre dans l’irrationnel, les cncantations vaudoues, les rituels mysterieux…
“Pourvu que ca tienne !”
C’est regrettable à dire, mais dans le monde logiciel : la qualité tend à être un élément à part des fonctionnalités. Parlez à un client de qualité et il vous dira qu’il la veut… mais sans être prêt à en payer le prix. Si l’on cherche à figer à la fois les délais, les coûts et le périmètre d’un projet, on ne dispose d’aucune marge de manoeuvre et on risque vite être déçu. Quand les échéances se rapprochent et que les budgets explosent, on a plus aucune marge de manoeuvre et c’est justement elle la première victime : la qualité.
Autant se tirer une balle dans le pied. A long terme, c’est le genre de situation synonyme d’un client insatisfait car les méchantes bestioles (1 et 2) refont toujours surface! Tant qu’on est sur une note humoristique, Mike Vizdos lui aussi aborde le sujet avec ses cartoons.
La dimension humaine
Comment tenir les délais en essayant de ne pas trop bâcler la qualité, si l’on ne tombe pas dans le piège de rajouter du monde dans l’équipe ou tout simplement lorsque l’on ne dispose pas de personnes supplémentaires à mobiliser ? En fournissant ‘un dernier coup de fouet’… ‘en se mobilisant’… ‘en faisant le forcing’…
C’est le genre de comportement courant, voire même valorisé ! Il faudrait presque ériger un monument à la mémoire des héros infatigables qui à grands renforts de café tapote sur leurs claviers des nuits entières et livrent l’oeil hagard une application impeccable au petit matin…
Nous le savons tous, ce n’est jamais un bon présage sur le plan de la qualité. Ni à long terme pour l’ambiance et l’épanouissement au travail…
Comment s’en sortir ?
Comme nous le rappelle Alistair Cockburn, il y a une dimension supplémentaire : le processus. Comment donc s’en sortir ? Grâce à une approche agile bien sur.
Etre agile : “Cheating legally to win” !
Le point essentiel est de se débarrasser du “Big Design Up-Front”, qui consiste à recueillir l’ensemble des besoins avant la conception et le développement. C’est un aspect que j’avais aborde précédemment et que je risque de répéter…
L’approche agile propose à la place de privilégier un raffinement progressif des besoins en s’appuyant sur des discussions fréquentes. On recueille juste ce qu’il faut de besoins et on développe les fonctionnalités correspondantes pour obtenir un feedback rapide sur une application fonctionnelle.
On prend ainsi en compte le fait que les besoins évoluent fatalement non seulement en même temps que l’environnement métier ou le marché, mais surtout avec la connaissance que l’on acquière au fur et à mesure du projet.
Pire, prendre en compte l’ensemble des exigences dans une même livraison, c’est courir droit vers l’explosion des besoins. Cela revient au mieux à livrer des fonctionnalités inutiles. Au pire, à ne rien livrer, parce que l’on est tout simplement débordé.
Voila pour aujourd’hui. Je répondrais dans la deuxième partie à la question : comment l’agilité aide-t-elle concrètement dans tout ça ?
Methodes Agiles et Design d’interaction
J’ai fait Mardi dernier pour Designers Interactifs une présentation que j’avais annoncée dans un précédent billet sur les méthodes agiles et le design d’interaction.
Le public était varié puisque l’on y trouvait des directeurs artistiques, développeurs et graphistes. Dont certains qui avaient déjà entendu parler de l’agilité. Il y avait même quelques pratiquants dans l’assemblée. La présentation avait plusieurs objectifs.
Tout d’abord montrer les problèmes que soulèvent les pratiques classiques de gestion de projet et ce qu’apporte l’approche agile. Ensuite montrer les points communs avec le Design centré utilisateur : approche centre sur le client, importance des tests et du feedback utilisateur.
Mais aussi montrer les changements de comportement que ça implique. Le principal est d’abandonner le fonctionnement traditionnel par phases pour une approche itérative ou le produit est progressivement raffiné. Enfin donner une idée des pratiques agiles qui peuvent être mises à profit par les designers interactifs pour évoluer. C’était presque un manifeste pour une ergonomie agile.
La présentation est disponible sur slideshare en slidecast, c’est a dire avec une bande son qui l’accompagne. Seul petit hic, en ce moment il ne fait pas bon courir dans les bois pendant des heures sous la grêle et ma voix n’est donc pas des plus claires… Pour ceux qui veulent creuser un peu la question de l’utilisabilite agile, Scott Ambler en donne un bon apercu.
J’étais très curieux à la fois de l’accueil que pourrais recevoir une telle présentation et des échanges qui pouvaient s’ensuivre et je n’ai pas été déçu. On a eu des témoignages, avec notamment celui d’une graphiste qui travaille dans une équipe XP avec une itération d’avance par rapport aux développeurs et à qui l’approche agile semblait très naturelle.
On a aussi abordé les obstacles que chacun pouvait voir à passer à une approche agile. Celui qui est le plus revenu est celui de l’implication des clients non matures : - des clients qui ne s’impliquent pas dans la boucle, - une perspective client bicéphale, - des clients qui veulent se décharger de toute responsabilité, - des clients qui veulent tout, tout de suite…
C’est vrai, l’approche agile demande d’éduquer le client, de lui faire comprendre qu’on ne peut avoir le beurre et l’argent du beurre : un produit qui me correspond, mais sans m’impliquer… Toutes les fonctionnalités, maintenant ! Pour ça, il faut mettre en place les choses progressivement, en lui donnant une visibilité sur l’avancement, en l’assistant pour piloter le projet par la valeur, et surtout en effectuant des livraisons fréquentes de produit bien concret.
Viens ensuite l’inévitable question des contrats. J’aurais d’ailleurs pensé que cette question se serait invité au débat avec plus d’ardeur, je suis positivement étonné. En effet, les participants n’était pas trop inquiets à l’idée de fonctionner par lot.
Bref, un accueil très positif. Certains seraient même conquis par l’agilité et pourtant, je n’ai pas parle de télépathie…
Mettre les exigences en boite
Dave Nicolett nous présente une méthode très intéressante pour structurer l’expression des besoins dans une approche agile, sous forme de user-stories ou scénarios. Je préfère utiliser ce dernier terme car à mon sens plus pratique et évocateur.
L’idée est d’organiser le déroulement d’une interview client en 9 étapes successives, de façon à cerner l’ensemble des facettes des scénarios envisagés. On voit ça dans le schéma ci-dessous, retranscrit à ma manière.
On définit ainsi le problème, puis qui il affecte, puis comment serait la situation une fois le problème résolu (sans présager de la manière de le résoudre).
On retrouve ce principe de se projeter dans l’avenir dans l’exercice que j’aime bien utiliser Design the Box ou on imagine le produit une fois réalisé (Décidément on parle beaucoup de “box” !). Dans le même style, Claude Aubry évoquait récemment Remember the future qui fonctionne sur les mêmes principes.
Revenons à nos moutons. Pour chacune des facettes, l’interview pose trois types de questions. D’abord des questions ouvertes pour dégrossir le problème et découvrir les préoccupe sous-jacentes. Ensuite, on essaie de quantifier les choses et enfin on s’assure que l’on a bien saisi en reformulant. C’est l’occasion de se rendre compte s’il y a des éléments à préciser auquel cas on revient en arrière. Et en plus, comme on le voit dans le schéma, cette technique permet justement de faire ressortir les besoins non fonctionnels.
On a alors tout ce qu’il faut pour exprimer directement notre scénario. Dave Nicolett envisage de les exprimer sous leur forme “canonique” :
"As a <role> I want to<action> so that <value>."
Ce qui donne en français
"Comme <rôle>, je veux <action>, de façon a <valeur>."
Personnellement, j’énonce les scénarios différemment et c’est justement ce qui m’a marque dans cette technique, c’est qu’il suffit de prendre les colonnes dans l’ordre pour les formuler sous la forme :
"Pour <valeur>, comme <rôle>, je veux <action>."
On a ainsi une expression des scénarios explicitement 1. conduite par la valeur, 2. centrée sur l’utilisateur et 3. independant de la solution ou des taches.
C’est justement tout l’intérêt d’exprimer ses besoins au moyen de scénarios ! Reste en plus à le faire de manière itérative, selon un raffinement progressif qui l’imite l’inventaire…
Présentation - méthodes agiles et design d’interaction
Je ferai une présentation sur les méthodes agiles le 4 Décembre prochain au Cafe Dune de 20h à 21h30 dans le cadre des Designers Interactifs.
“Un cahier des charges respecté mais un client pas 100% convaincu… La motivation et la créativité engluées dans le ventre mou des projets qui s’allongent… Un marché, des besoins, des technologies, des usages en évolution constante…”
Voila quelques-uns des problèmes que cherchent à résoudre les méthodes agiles par une approche basée sur la collaboration et des livraisons rapides et régulières au client.
Cette présentation dressera donc un aperçu des méthodes agiles, des valeurs qu’elles mettent en avant et des pratiques sur lesquelles elles reposent. Elle devrait être l’occasion d’engager un débat autour des questions telles que : - la place du design d’interaction au sein des projets - la collaboration au sein des equipes et avec le client, - les rapports entre expérience utilisateur et feedback, - la relation entre livrables et valeur produit.
Elle s’adresse a tous ceux - DA, webdesigner, chef de projet - qui souhaite échanger sur leurs expériences et pratiques en matière de conception centrée utilisateur et conduite de projet ou tout simplement découvrir de nouvelles perspectives. N’hésitez donc pas d’ici la à faire part en commentaires de vos questions, attentes ou témoignages pour rendre l’échange le plus interactif et fructueux !
