Articles de françois :
- Nouveau rôle pour les gestionnaires : de controleur à facilitateur ;
- Coordination du travail : d’une hiérarchie bureaucratique à des équipes liées dynamiquement ;
- De valeur à valeurs : transparence radicale, amélioration continue ;
- Communication interactive : de commander et contrôler à une conversation d’adulte à adulte.
- Where do we put the time for meetings?
- Do we need to have absolutely all tasks in the sprint backlog?
- When we are pairing, do we do time entries for each of us?
- When we plan, do we create tasks for all the available hours we have? (more on this in the post Sprint and Compelling Goals)
- How people perform correlates to how situations occur to them.
- How a situation occurs arises in language.
- Future-based language transforms how situation occurs to people.
Le gagnant est…
Dernièrement, j’ai donné ma présentation intitulée « De l’individu à l’organisation en passant par l’équipe » à Agile Québec. J’ai demandé aux participants
intéressés de rédiger un texte sur leur appréciation de cette présentation. Parmi les textes reçus, une personne choisie au hasard était pour obtenir une participation gratuite au premier cours Management 3.0 qui aura lieu à Québec les 18 et 19 avril prochains.
Vers de nouvelles possibilités
Nous avons communiqué, au cours des derniers jours, un changement important concernant la direction de Pyxis. L’annonce de ma nomination à titre de président de Pyxis a fait suite à la décision de Martin et Yves de quitter Pyxis en juin pour poursuivre leur rêve de démarrer leur propre entreprise.
Je m’arrête régulièrement pour réaliser la chance que j’ai d’évoluer à Pyxis avec des collègues combinant un niveau d’excellence élevé et des qualités humaines exceptionnelles. Plus particulièrement, j’ai travaillé avec Yves sur une base quotidienne à faire évoluer notre offre pour les gestionnaires Agiles. Yves : “Ce fut un vif plaisir de travailler avec toi et d’évoluer ensemble. J’ai déjà hâte aux occasions de collaboration que nous allons créer dans le futur.”
De l’individu à l’organisation en passant par l’équipe Agile
Le 25 janvier dernier lors de la rencontre de la Communauté Agile de Montréal, j’ai donné ma présentation « De l’individu à l’organisation en passant par l’équipe Agile ». Ça fait déjà quelques années que je donne des conférences. J’en ai fait plusieurs sur des sujets propres à l’Agilité et, chaque année, j’aime bien faire une conférence qui présente à haut niveau mon point de vue de praticien de l’Agilité. L’an dernier, c’était la conférence « L’Agilité qui réduit l’Agilité ».
Dans « De l’individu à l’organisation en passant par l’équipe Agile », je présente un point de vue intégral relativement à l’Agilité et fais un survol de plusieurs éléments que je trouve fondamentaux. La présentation a été captée sur vidéo et nous avons retenu quelques extraits que nous vous présentons ici.
Et les gagnants sont
La semaine dernière, j’ai présenté à Agile Montréal ma conférence L’Agilité de l’individu à l’organisation en passant par l’équipe. J’ai profité de l’occasion pour faire tirer 5 laissez-passer pour assister à la toute première édition canadienne du cours Management 3.0 que je donnerai sous peu. Pour avoir une chance de gagner, les participants devaient écrire un texte d’environ 500 mots afin de donner leur impression sur la présentation.
À la suite du défi que j’ai lancé et à la lumière des textes reçus, j’ai décidé de me lancer dans la blogosphère. Surveillez le blogue de Pyxis, mon blogue personnel arrivera sous peu. J’y partagerai en toute simplicité mon point de vue et mes réflexions sur le monde de l’entreprise.
Le but de votre entreprise… Enchanter vos clients… En fait non!
Mon collègue Martin a déjà publié un billet au sujet de la présentation que nous avons préférée jusqu’à maintenant à Agile 2011. Il s’agit de Making the Entire Organization Agile par Stephen Denning.
Je vous conseille fortement de lire le billet de Martin avant de lire ce billet car il fait un survol complet de la présentation. Ne ratez pas la courte vidéo de 1 minute.
Le bouquin Radical Management de Stephen Denning est dans ma liste de bouquins à lire depuis quelques temps. Depuis la présentation de hier, j’ai pris un peu de temps pour commencer à absorber le contenu, valider des hypothèses, intégrer les implications sur d’autres modèles d’organisation, etc. En d’autres mots, mon cerveau est en cinquième vitesse. Le bouquin de Denning se retrouve maintenant en première position dans ma liste de lectures !
Denning propose cinq changements fondamentaux qui s’imbriquent et se renforcent. Le premier étant que le but de l’entreprise (bottom line) passe de générer de l’argent pour ses actionnaires à enchanter (delight) ses clients. C’est en fait le changement fondamental que propose Denning et celui sur lequel il a passé le plus de temps durant la présentation.
Ce changement a des implications profondes car il demande entre autre de passer d’une logique de production (output) qui génère des profits à une logique de produire un résultat (outcome). Je crois que c’est absolument génial que des entreprises réalisent ce changement fondamental qui amène à prendre une perspective plus globale.
Il est important de rappeler que Denning nous dit que de simplement adopter ce but d’enchanter nos clients ne fonctionnera pas et qu’il est nécessaire d’adopter les quatre autres changements suivants :
J’ai bien hâte de lire le bouquin de Denning pour comprendre plus spécifiquement ce qu’il propose et mettre tout ça en parallèle avec les modèles d’organisation apprenante (The Fifth Discipline) développé par Peter Senge et Management 3.0 développé par Jurgen Appelo.
Lorsque je prends un point de vue systémique, comme mentionné plus haut, je suis ravi d’intégrer une mesure d’enchantement des clients en priorité sur les résultats financiers et mobiliser l’organisation vers cet objectif. J’ai d’ailleurs suggérer à Martin qu’il serait une bonne idée pour Pyxis de mettre en place une mesure similaire au Net Promoter Score (voir The Ultimate Question) dans notre cadre de suivi des résultats. Je lui également dit à la blague qu’il devrait passer de Chief Executive Officer à Chief Delighter Officer !
Je souhaite vigoureusement ajouter que je crois qu’il est important voire essentiel pour une entreprise d’avoir un futur envisagé (une vision) établi collectivement qui met l’entreprise en mouvement dans une direction cohérente.
De façon plus fondamentale, j’aimerais ajouter que la perspective systémique m’amène à dire que le but d’une entreprise ne doit pas être d’enchanter ses clients ; elle doit selon moi avoir cet objectif et cette préoccupation bien présente dans sa culture. Je crois qu’une organisation doit avoir une clarté de la part de l’ensemble de ses participants sur ce qui constitue sa raison d’être (sa mission). Rémi Tremblay dans son bouquin J’ai perdu ma montre au fond du lac nous invite à réfléchir et clarifier ce qu’il nomme le bien commun de l’organisation.
Dans le cas de Pyxis, la raison d’être est notre guide depuis plusieurs années :
Pyxis aide les organisations de développement logiciel à devenir des endroits où les résultats, la qualité de vie et le plaisir coexistent de façon durable en étant en premier lieu un exemple de ce qu’elle propose à ses clients et en accompagnant ceux-ci.
Nous devons trouver comment nous assurer que nous accomplissons notre raison d’être ; que nous respectons entièrement notre définition du bien commun. Des suggestions ?
Implementing Scrum and Agile … Tools, please disappear!
Assisting teams and organizations adopt Scrum and Agile practices for many years, I have realized, sometimes the hard way that Agile is a culture change. If you are interested in exploring more the topic of cultures and their implications, there are many resources available. I suggest you have a look at Bill Schneider’s work. I also suggest this blog post from Michael Spayd.
I have found Schneider’s core culture model very useful to assess the culture in place in a group that wants to adopt Scrum and Agile. Depending on how much time you want to allow, you can do an intuitive assessment or have some people go through the questionnaire that you can find in the book The Reengineering Alternative. By having the questionnaire by multiple persons at various levels and with various roles in the organizations, you can develop a good understanding of the culture in place. With the assessment results in hand, you have a marvelous tool to drive conversations and start identifying the challenges of the transition to Scrum and Agile and where to focus efforts.
Adopting Agile will certainly bring significant challenges in creating a team/collaboration culture, solid incremental software engineering practices, value driven planning, etc. Therefore, the last thing you want is tooling to get in the way. I have found that people put too much focus on the tooling for managing their scrums and not enough focus on the core issues. My advice, especially in the early stages of a product or project, is to use the tools that will provide the highest level of collaboration and interactions. Those are collaborative sessions where you use flip-charts, post-its, whiteboards, etc. Until we have tools that support a very high level of interactions and allow teams to create story maps and other models collaboratively and efficiently, I think it is wise to stick with those simple tools in those product exploration and definition sessions.
For various reasons, a significant portions of the Scrum / Agile teams will want to use an electronic tool to do planning and tracking. Again, I think the best tools are the ones that do not get in the way of collaboration. As outlined in Scrum and Agile Built Into Microsoft Team Foundation Server I presented how we design Urban Turtle to blend much like a chameleon into the existing environment for organizations that are using Team Foundation Server. The Urban Turtle team is committed to enabling software teams to create kick-ass software fast and we are always striving to make the user experience seamless and simple. Give Urban Turtle a try and please let us know what you think we need to improve in Urban Turtle or what you think we completely got wrong. Please be candid. We have done a release per month (5) since the release of TFS 2010 and intend to continue sustaining this pace. Therefore, there is a high chance that if your suggestion is great, it will be included in the product soon.
I value a lot exchanging points of view and experiences. Please do not hesitate to comment here, or send me an email to setup a live conversation.
In a previous post, Sprints and Compelling Goals, I expressed my opinion on why I think commitment driven planning is much more powerful than capacity planning. In the next post I will present why I think compelling goals drive collaboration and creativity. Stay tuned!
Cheers,
~françois
Effectively Tracking Cost in Scrum
Note that the ‘Scrum Team’ refers to the Product Owner, the ScrumMaster and the Team. The Team consists of developers with all the skills to turn the Product Owner’s requirements into a potentially releasable piece of the product by the end of the Sprint.
Last week I was discussing with Mathieu and he started to talk to me about a friend who is now Product Owner (previously project manager) on a Scrum project. This person wants to make sure he is doing a good job and wants to continuously improve. I said, this is really awesome!
Mathieu, then says that his friend asked him the specific question: if I want to track the time I am investing in creating user stories and prioritizing the product backlog, which work item type and fields should I use to enter actual time spent if I am using the new Scrum process template from Microsoft.
My reaction is … Interesting, why don’t you ask your friend how he is going to use this data to effectively improve as a Product Owner? If the Team is producing software that the users consider high value at an ever increasing and sustainable pace, don’t you think that those are great indications that the Scrum Team is doing good work? I believe those are much more interesting metrics to track than the actual effort he is putting in creating and prioritizing the product backlog.
Mathieu: Sure, I will suggest him that but I think he also wants to track cost.
Ha! This is getting even more interesting now. Because it leads to the questions of time and cost tracking in Scrum; a question I often get in my scrum classes, especially from participants working in large corporations.
When I started teaching Scrum in 2004, I used to answer in my classes that time tracking is not part of Scrum but if you want to track actuals on sprint backlog items for administrative purposes, you can go ahead.
Observing Scrum Teams doing time tracking on sprint backlog items invariably leads them to questions like:
And the list goes on. All these questions are a struggle for the Scrum Team and answering them does not help them in creating high value software fast. Therefore, my answer now is: Tracking actual work on sprint backlog item is not part of Scrum. Period.
The reaction I usually get is either “this is impossible in real life” or “you are telling us that a Scrum Team is not responsible for its cost”.
I think that a Scrum Team IS responsible to be aware of their cost and the value they bring to the organization; they are software professionals and therefore they strive to maximize the ROI of their work. The Product Owner is specifically accountable for maximizing the ROI by appropriately prioritizing the product backlog.
The reaction is usually “I don’t get it. You are saying not to track actuals on sprint backlog items and at the same time that the Scrum Team is responsible for its cost.”. Here is the suggestion I usually provide. Most organizations are interested in knowing how many hours their people work to be able to produce the pay checks. Therefore they have a timesheet system where people enter their time. My suggestion is to have time entries per project (much higher level of granularities than the sprint backlog items). Therefore, a team member working on a single project will produce one time entry per period. Timesheet system or not, you should be able to easily query your enterprise systems to know salary costs for a given period. May be you are lucky enough to have a cost tracking system in place that is able to give you the answer to how much expenses directly related to the product development were made during the same period.
My point is that it should be possible to identify the total cost of an iteration and have the Scrum Team track this. Considering all of this, I have a request to make to Microsoft : Add the fields ‘Scrum Team Cost’ (numeric) and ‘Other Costs’ for iterations in the Scrum process template. This will be useful for enterprise Scrum. May be it is not too late to put it before version 1.0 goes final ![]()
Cheers,
~françois
Sprints and Compelling Goals
There has been a debate in the Scrum and Kanban communities about having iterations (sprints) or not. I am worried that this blog post will generate flame wars and rants. Thus, there will certainly be some energy that will be lost. My hope is that this post will generate real debates and discussions so we can learn from each other’s opinion.
I have been developing software in Scrum for a long time and coaching many teams and organizations adopting Scrum. Therefore, I have been exposed to a lot of situations and feel I have integrated the fundamentals and the theoretical foundations of Scrum.
My general feeling, which you will see expressed throughout this blog post is that the Agile community is falling into the trap of looking for optimizations everywhere and is losing sight of some fundamentals about complexity, creativity, teamwork and commitments.
When I first heard about Kanban, I was intrigued and read about it and even applied it in some situations I felt it could be helpful. There are a couple of nice things that Kanban brings to the table but I also think that it breaks some fundamental things that make Scrum work.
Within sprints, Scrum suggests a simple workflow with sprint backlog items going from ‘To Do’ to ‘In Progress’ to ‘Done’. I have certainly seen some Scrum teams have way too much work ‘In Progress’ and using Kanban techniques to limit the amount of work in progress can certainly help. I also do not think it is necessarily a bad idea that a mature team establishes a more defined workflow and uses Kanban techniques to control its flow of work but going too far (I have seen a Kanban board with 10 columns corresponding to stories’ statuses) in that direction will reduce the possibilities of emergence that creates true performance in self-managing, multidisciplinary teams.
Getting to the actual debate of having sprints or not. Some Scrum proponents say that not having sprints may be problematic because the team needs to hold regular retrospectives to accelerate learning. While I do agree that holding regular retrospectives is absolutely essential, I think that a Kanban team could do regular retrospectives while not completely applying sprints.
I think Ken Schwaber has a much stronger point. In his Waterfall, Lean/Kanban, and Scrum blog post, he presents sprints from the point of view of the complexity theory.
A container is a closed space where things can get done, regardless of the overall complexity of the problem. In the case of Scrum, a container is a Sprint, an iteration. We put people with all the skills needed to solve the problem in the container. We put the highest value problems to be solved into the container. Then we protect the container from any outside disturbances while the people attempt to bring the problem to a solution. We control the container by time-boxing the length of time that we allow the problem to be worked on. We let the people select problems of a size that can be brought to fruition during the time-box. At the end of the time-box, we open the container and inspect the results. We then reset the container (adaptation) for the next time-box. By frequently re-planning and shifting our work, we are able to optimize value.
Vincent also brings an interesting viewpoint in his recent post Scrum is not about project management
.
While explaining the notion of container, Ken mentions above: “We put the highest value problems to be solved into the container.” I would like to push this a little further and relate it to planning and commitment. I have always insisted in my Scrum classes that a successful sprint planning is not about delivering a sprint backlog, it is first and foremost about having a team committed toward a goal that is compelling for them as a whole including the ScrumMaster and Product Owner. I believe, this is one of the fundamentals to create creative hyper-performing, self-managing teams that can sustain.
I have felt during the last few years that as a community we are putting too much focus on the concept of velocity and, therefore, many teams are un-passionately identifying their commitment based on their velocity and do not get to the true nature of what it means to be committed toward a compelling goal.
Before you throw tomatoes at me, I am not saying that measuring velocity is useless. I am saying that while it is useful for a team to measure and be aware of its velocity, I think we let it drive too much the commitment decisions of the team. Some tools are in my opinion putting too much emphasis on using velocity to drive the sprint planning process.
This belief of the importance of being committed toward a compelling goal was reinforced recently while reading the following book: The three laws of performance. Here are the three laws presented in the book:
I will not try to summarize the book here. I thought it is useful to mention this reference because I think it links the importance of creating an environment in planning sessions that enables the team to choose a goal that is compelling for them to some fundamentals of human beings.
In summary, I suggest to use sprints as defined in Scrum because when done in the true spirit of Scrum, they enable a team to look at the highest value problems, imagine a compelling future, and use all of the thinking, collaboration, and creativity possible to put together solutions and plans. Then, you leave the people alone within the container of the sprint to apply their professional skills, without interruption so they can concentrate and focus on their work. This is the core of them being creative people doing creative work rather than resources being managed to optimize productivity.
Scrum and Agile Built Into Microsoft Team Foundation Server
In Answering some common questions about Urban Turtle we answer some questions and present some of the orientations we took in designing Urban Turtle.
One of the main orientation is to build Urban Turtle into TFS (as opposed to integrate with). All our design decisions are made to bring as much value-added as possible while creating a seamless experience for existing TFS users and grow with TFS as Microsoft adds new features.
We believe this orientation is what allows us to have a product that installs on the server in less than two-minutes and gets a team to use it right away. We are very interested in hearing your stories and get your feedback about how we can further improve the experience.
Help us make our Urban Turtle a Chameleon ![]()
Also, our tight integration in the Web Access user interface makes the user feel at home and perceive TFS with new capabilities (as opposed to using an extra product). This is a big plus to have a smooth user adoption. We know that adopting scrum is already an interesting challenge; you do not need tools to get in your way but be a possible accelerator.
In the release that we have for you this week (June 2nd), we deliver a bunch of enhancements including a productive way to use Areas. The upcoming release will most likely focus on a feature we call Perspective that will allow you to work seamlessly in Urban Turtle on a subset of work items making it a charm to do multi-teams and grouping projects together. We will also focus on enhancing user experience in a couple of key places.
Again, give Urban Turtle a try and let us know how we succeeded in turning it into a Chameleon.
Entrepreneur
Je souhaite partager avec vous le discours que j’ai prononcé la semaine dernière à titre de président d’honneur lors du gala de remise des prix du Concours québécois en entrepreneuriat, région Laval.
Bonsoir Mesdames et Messieurs,
J’aimerais dans un premier temps demander à toutes les personnes présentes qui travaillent à titre d’employés, de bénévoles ou de membres du CA du CLD ou de Laval Technopole, à celles qui travaillent à l’organisation du concours et à celles qui travaillent pour une fondation ou un organisme qui promeut et soutient l’entrepreneuriat de se lever.
Pour en avoir côtoyé plusieurs, je peux vous assurer que ces gens sont tous des passionnés dotés d’une générosité hors du commun et qu’ils sont un rouage important de notre société. Je demande donc de leur donner notre appréciation en les applaudissant.
Cet après-midi, j’ai utilisé Antidote sur mon iPhone pour chercher la définition du mot ‘entrepreneur’ car c’est selon moi la meilleure suite de dictionnaires de langue française. Antidote est d’ailleurs édité par Druide informatique, qui est une firme québécoise dirigée par André d’Orsonnens, un entrepreneur d’exception qui a su construire une équipe d’exception…
J’y ai évidemment trouvé une définition très terre à terre, c’est-à-dire : ‘Personne qui engage des capitaux et utilise une main-d’œuvre salariée en vue d’une production déterminée; chef d’entreprise’.
Je vais devoir communiquer avec André pour voir si nous pouvons ajouter à Antidote une définition un peu plus sentimentale :
Personne qui décide de prendre sa vie professionnelle en main en mettant de l’avant un projet créateur de valeur, qui fait cela de manière à la fois passionnée et pragmatique et qui invite d’autres personnes qui se sentent interpellés par la mission de ce projet d’entreprise à y participer avec leurs propres passions.
Je profite de l’occasion pour vous glisser un mot sur ma vision des entreprises de demain. J’ai la ferme conviction que les entreprises qui auront du succès dans la durée pour la prochaine génération seront celles qui auront un modèle équitable de redistribution de la richesse créée.
Notre société vit des changements substantiels et j’invite les dirigeants à innover en mettant en place des structures et moyens novateurs comme des coopératives de travailleurs actionnaires ou autre.
Je souhaite en terminant souligner le mérite des finalistes et lauréats que nous honorons ce soir pour leur courage d’entreprendre dans ces temps de turbulences énormes. Je vous dis à tous un sincère bravo et vous souhaite le plus grand succès possible dans la réalisation de chacun de vos projets.
Bonne soirée à tous!











