Mercredi dernier, j’ai facilité un Forum Ouvert* pour le groupe Agile Montréal**.
Nous étions une trentaine de passionnés de l’Agilité à partager nos expériences. Nous avons eu 2 séances de 40 minutes, sans pause. Nous avons ouvert l’espace pour une infinité de séances en parallèle, et il y en a eu 5, et parfois 6, ou 7… On peut dire qu’il a été pleinement utilisé, cet espace!
Parmi les sujets discutés, en voici 5 dont je me souviens.
- Comment composer avec les développeurs junior dans un environnement agile?
- Comment composer avec du code Legacy?
- Qui tire avantage de l’agilité dans un contexte de transition?
- Quels sont les outils utiles pour une équipe distribuée?
- Qu’est-ce que Kanban? Comment puis-je en tirer profit?
Sylvie Trudel en pleine explication
Comme vous pouvez le voir, les sujets étaient variés et s’adressaient à différents profils : développeurs, experts agiles, scrum master. D’ailleurs, si les participants de l’événement ont envie de relater ce qui s’est passé dans leur session, je vous invite à le faire en laissant un commentaire ici.
Certaines choses m’ont marqué, comme ce point rappelé par Éric Mignot (@ericminio) comme quoi il faut constamment rappeler à l’équipe les raisons de son choix de l’agilité. Il propose de le rappeler à chacune des rétrospectives. J’ai contribué sur plusieurs sujets, et surtout, j’ai mis des personnes en contact: vous avez besoin d’un bouquin pour les projets distribués? Lisez celui de Steffan Surdek! Vous avez besoin de lire sur la gouvernance des projets agiles? Il y a quelques chapitres sur le sujet dans le bouquin “Choisir l’agilité”, de Sylvie et Mathieu! Vous voulez entendre une expérience pratique sur Kanban? Contactez Benoit Lapointe, chez IBM Bromont. Souvent, dans ces événements, je me sens comme une entremetteuse. Je suis une réelle butineuse, à aller de séance en séance, ébruitant ce qui s’est dit ailleurs et faisant des liens.
Le plus important : j’ai fait de nouvelles rencontres, et j’ai retrouvé des anciens collègues de mes anciens mandats ou emplois. Bref, j’ai vraiment aimé ma soirée.
En tant que facilitatrice, je suis toujours surprise de voir la richesse des discussions et le niveau d’écoute. Certaines discussions se terminent rapidement et évoluent vers d’autres préoccupations plus importantes. Ainsi, dans la session sur les projets distribués, nous avons évacué rapidement la question des outils pour parler de démarrage de projet. D’autres groupes avortent subitement, ou ne démarrent jamais, faute de participants. Mais toujours, ce qui est arrivé est la meilleure chose qui devait arriver.
J’ai essayé une nouvelle façon de placer les groupes de discussion : j’ai laissé les initiateurs de discussion, les 5 responsables des premières séances, choisir leur emplacement dans la salle et l’afficher. L’exercice s’est très bien passé, les groupes se sont retrouvés facilement en quelques secondes. J’imagine que cette pratique a ses limites par contre en termes de nombres de personne; je n’imaginerais pas une telle pratique avec 1000 personnes, ni avec un édifice où les salles peuvent être distribuées sur 3 étages.
Avez-vous déjà essayé de demander à un groupe de 30 personnes de replacer une salle dans son état initial? Combien de temps leur accorderiez-vous? 5 minutes? 10 minutes?
J’ai été épatée de voir le groupe replacer la salle dans l’état exact où je l’avais trouvé 2h30 plus tôt en moins de 2 minutes. Après leur avoir expliqué verbalement l’état final (leur objectif) à retrouver, j’ai laissé le groupe s’auto-organiser pour accomplir cette tâche. Le résultat m’étonne toujours. Je n’aurais jamais été capable de les diriger dans cette tâche ou de trouver une façon (planifier) de les organiser par équipes, puis sous-équipes, pour y arriver. Et je n’aurais jamais eu cette efficacité avec un plus petit groupe. Il y a de ces tâches pour lesquelles l’auto-organisation est imbattable.
Au plaisir de vous y revoir la prochaine fois!
Agile Partnership peut organiser des événements Forum Ouvert pour vos entreprises. Songez à nous la prochaine fois que vous voulez organiser une “journée colloque”. Encore mieux que du team building, vous atteindrez un objectif que vous définirez et vous aurez un groupe uni, mobilisé et énergisé.
*Le Forum Ouvert est un format permettant aux participants de choisir leur sujets de discussion et laissant la place à l’improvisation, à la créativité et à l’émergence de moments riches et passionnants. Le format convient aux groupes de 10 à 2000 personnes et est utilisé partout dans le monde pour atteindre des objectifs ambitieux en peu de temps tout en mobilisant des groupes. Plus d’information sur Wikipedia: article en français sur les Open Space .
**Agile Montréal est un groupe ouvert à tous les passionnés de l’agilité au Québec. C’est un OSBL géré par un CA bénévole. Des événements de type Forum Ouvert pour des discussions ouvertes sont organisés régulièrement depuis l’automne 2008. Plus d’information sur agilemontreal.ca.
+10
Tout d’abord, demandons-nous pourquoi une entreprise de services croît généralement.
En générant des revenus supplémentaires, elle pourra se permettre une structure d’opérations qui contient des gens qualifiés et spécialisés (marketing, ventes, finances); elle pourra permettre à ses employés d’approfondir leurs connaissances ou de faire diverses activités qui ne génèrent pas de revenus. L’entreprise dégage de meilleures marges pour le même type d’activité : c’est le principe d’économie d’échelle. Ainsi,
- on a une masse critique qui permet à l’entreprise d’être reconnue sur le marché, ce qui génère des demandes des clients
- on s’assure de pouvoir répondre à des demandes du marché à tout moment
- on a plus de contrôle sur le choix des clients, la fixation des prix
- on s’offre un environnement physique de choix pour les employés, ce qui attirera les meilleurs candidats
- on diversifie les produits et services de l’entreprise : en allant chercher des nouveaux marchés, on se protège des hauts et des bas de l’économie
Mais surtout, tout cela a pour effet d’augmenter la valeur de l’entreprise en plus de donner un sentiment fort de satisfaction aux fondateurs. Malheureusement, certains ne le font que pour ces deux dernières raisons.
J’ai lu sur un site gouvernemental canadien un paragraphe qui expose les raisons pour faire croître une entreprise:
« Vous êtes peut-être satisfait de la situation dans laquelle se trouve votre entreprise et n’éprouvez pas le besoin de la faire croître. Cependant, dans le monde des affaires comme dans la vie, si vous ne bougez pas, ne changez pas ou ne vous améliorez pas, vous êtes peut-être mort. Les entreprises doivent analyser le présent et évaluer le futur. Pour faire face à un marché et à un monde des affaires changeant, elles doivent planifier pour survivre et croître. Une entreprise qui ne croît pas peut devenir complaisante, paresseuse, incapable de s’adapter et éventuellement incapable d’opérer. »
Personnellement, j’ai rarement vu un discours aussi peu convaincant : « Il faut grandir, car vous deviendrez paresseux ». À la base, ce sont de très bons conseils : c’est vrai que la stagnation amènera probablement votre entreprise à risque. Mais en quoi les améliorations passent nécessairement par la croissance? En quoi s’adapter constamment au marché et ne pas s’asseoir sur ses succès passé doit-il passer par la croissance?
Ce qu’on oublie souvent, c’est qu’il y a plusieurs risques majeurs qui peuvent facilement annuler tous les gains théoriques. Il y a des risques de dérive à plusieurs niveaux : expérimentation sur des marchés inconnus, complexité de la structure financière, complexité de la gestion des relations humaines, désirs divergents, manque d’aptitudes, laxisme au niveau des dépenses…
Et puis qu’en est-il des 5 effets recherchés de la croissance ci-haut mentionnés?
- La reconnaissance de l’entreprise sur le marché ne dépend pas seulement de la quantité d’employés mais aussi de la qualité des services ainsi que de la visibilité sur les divers réseaux (virtuels ou non). La capacité d’avoir du repeat business est un bon indicateur de la qualité du service offert.
- Les demandes du marché peuvent toujours attendre. Si votre marché est aussi volatile que vous ne pouvez pas vous permettre de refuser les mandats ou opportunités quand elles passent, alors il y a probablement un problème avec votre crédibilité, donc votre marketing et vos ventes.
- Le contrôle sur le choix des clients et des prix dépend grandement de la réputation de l’entreprise et encore une fois, de la qualité des services offerts. Pas de la taille de l’entreprise.
- Offrir un environnement de choix aux employés et de bonnes conditions salariales est une condition nécessaire mais non suffisante à leur niveau de satisfaction. Un environnement stressant, démotivant et déresponsabilisant dû à une croissance mal contrôlée peut convaincre vos meilleurs employés d’aller voir ailleurs. J’ai constaté dans ma carrière qu’un employé de qualité est généralement motivé s’il est entouré de collègues compétents et qu’il peut participer à des projets où il peut s’accomplir réellement. Ces projets comportent des défis techniques et humains et lui permettent de s’investir totalement.
- Pour se protéger des hauts et des bas de l’économie, vaut mieux avoir une entreprise qui ne dépense pas plus qu’elle ne rapporte. Certes, ici, la croissance peut aider : c’est vrai qu’en diversifiant les services on peut se protéger. En utilisant l’effet de levier, on peut aussi avoir un meilleur retour sur l’investissement. Mais du même coup, on est moins centré sur la vision initiale, on risque de perdre beaucoup d’énergie sur des domaines / marchés qu’on maîtrise moins bien. Ce qui nous place davantage à risque. C’est une question de choix.
À Montréal, et c’est encore plus vrai en informatique, on entend souvent que nous sommes dans un « petit marché ». Les contrats qu’une compagnie obtient sont ceux qu’une autre compagnie n’obtiendra pas. La croissance d’une entreprise se fait donc aux dépens d’une autre, car nous avons un pool de ressources limitées, autant au niveau des développeurs que des gestionnaires, ainsi qu’un nombre de clients limités. Le monde est grand toutefois, vous pouvez toujours viser les marchés internationaux!
Alors comment savoir quel est le nombre idéal d’employés dans une entreprise de services? Pour chacune, selon moi, il y a un moment où le nombre idéal est atteint, et où il serait sage de ralentir la croissance. Il n’y a pas bonne réponse valide pour toutes les organisations. Mais déjà, se poser la question, c’est un signe de saine gestion!
En agilité, une valeur importante est la capacité à s’observer et d’adapter constamment ( « inspect and adapt »). Nous avons des mécanismes pour améliorer la structure et les pratiques d’une équipe de développement logiciel : la principale est une rétrospective, où on discute en groupe de ce qui s’est bien passé et ce qui s’est moins bien passé, et où on propose des améliorations pour l’avenir. Je pense que pour une entreprise qui cherche à croître, ce genre de question pourrait faire l’objet de réflexions périodiques avec toute l’équipe. En analysant en détail et sous tous ses angles les conséquences d’aller de l’avant avec la croissance, on s’assure de prendre une décision plus éclairée. En bonus, on obtient un meilleur buy-in de tous les employés, ce qui facilitera le chemin et diminue les chances de démotivation. Je crois donc que c’est un investissement qui vaut la peine.
Posez-vous les vraies questions, et ayez le courage d’y répondre honnêtement. Ensuite, allez de l’avant.
+10Samedi, 29 octobre 2011, 7h30. Jour de l’Agile Tour 2011.
Quand je me fais déposer au pied des marches du 200 Sherbrooke Ouest en ce magnifique samedi matin, il n’y a absolument rien qui me rappelle la folie du quotidien de semaine. Les bruits sont sourds et le calme règne. Avez-vous déjà conduit au centre-ville à cette heure-là le week-end? C’est apaisant.
Mais pourtant, une colonie de fourmis est en train de peaufiner la préparation de la journée depuis 6h : ce matin, ils devront s’assurer que les salles sont correctement identifiées, correctement indiquées. Plus tard, ils devront répondre aux questions des participants et surtout celles des conférenciers. Ils devront s’assurer que les responsables de la sonorisation sont là en cas de besoin. Ils devront s’assurer que la nourriture arrive à la bonne heure et que les gens soient servis à un rythme régulier. Bref, ils devront tout mettre en œuvre pour que les conditions soient idéales pour les 19 conférenciers qui vont s’adresser à plus de 200 personnes aujourd’hui. Des Scrum Masters, quoi!
Merci aux bénévoles et organisateurs
À la fin de la journée, à part les bénévoles, je suis partie la dernière à 17h30; heureusement, car sinon j’y aurais oublié mon chapeau! La salle était déjà nettoyée, les tables parties, les manteaux remis à leurs propriétaires. À ce moment, personne n’aurait pu dire qu’il y avait eu une journée de conférences dans ce building. Mais tout était dans la tête et le cœur des participants.
Voici quelques éléments que j’ai retenus de cette journée très enrichissante.
The Alignment of Agile Management Methods with Corporate Governance Models (Kevin Aguanno).
Il n’y a pas de contradiction fondamentale entre les processus de gouvernance standards (le fameux « gating ») et les méthodes Agiles. La clé est de transformer la longue période de « préparation de projet » par un court « sprint zéro » suivi d’une succession de « early sprints » qui vont permettre d’amasser de l’information réelle sur le projet.
Quand on se fait opposer de la résistance dans une organisation qui doute de la faisabilité de commencer immédiatement la phase de « développement » d’un projet après quelques semaines, voire quelques jours de démarrage, M. Aguanno suggère de présenter cette phase ainsi : avec l’équivalent de la durée nécessaire pour démarrer un projet waterfall et avoir le plan initial, nous aurons un plan plus précis, des variables de projet plus fiables et en bonus, un premier incrément de logiciel terminé. Plutôt que de produire des documents, du vrai travail de développement va permettre beaucoup plus efficacement de réduire les risques et d’avoir des données réelles sur la vélocité de l’équipe et sa maîtrise de la technologie. Le coût du projet estimé après 3 sprints de travail reste une estimation, elle est donc fausse par défaut, mais elle sera bien plus précise car elle repose sur du travail concret. Et aucun temps n’est gaspillé à concevoir des fonctionnalités qui ne seront jamais développées.
Pragmatique, clair, rassurant!
Thinking with your hand: an introduction to Lego Serious Play ™ (Ellen Grove)
Mon avion Lego
Mme Grove nous a parlé d’une technique utilisée dans beaucoup d’entreprises très sérieuses, et même avec des équipes de direction, afin de solutionner des problèmes de façon très efficace : jouer [sérieusement] avec des Lego!
Nul besoin d’avoir un talent artistique, il suffit de pouvoir emboîter des petits blocs. Alors tous ont la possibilité de faire aller leur imagination! C’est étonnant : avec exactement les mêmes blocs, nous avons fait des constructions complètement différentes. La suite de l’exercice nous force à être créatifs : nous devons raconter une histoire à propos de notre modèle en partant d’un choix de termes imposés.
Inspirant, instructif, amusant!
Site officiel de la technique et le blogue de Mme Grove
L’engagement est-il mort? (Éric Laramée)
Non.
Éric en pleine action
En scrum, le fait d’insister trop sur l’engagement pris par l’équipe au sprint planning nous éloigne de l’objectif ultime : livrer de façon régulière et prévisible un incrément de fonctionnalité de qualité à chacun des sprints. Si l’équipe a trop peur de rater son engagement, elle va assurément tourner les coins ronds.
Selon le Scrum Guide de juillet 2011, on prévoit donc le travail qui sera terminé à la fin du sprint, on ne s’engage plus. Plutôt, on s’engage sur
- la Définition de Terminé
- l’amélioration continue des pratiques de l’équipe
- le respect des valeurs et principes de l’Agilité
- l’objectif du sprint, qui prend maintenant toute son importance.
Motivant, intéressant, éclairant!
À lire, le blogue d’Éric à ce sujet : Is Commitment Dead?
100% de couverture de code par les tests (Vincent Tencé)
Le code patrimonial (legacy) de demain est écrit par les programmeurs d’aujourd’hui. Alors vaut mieux construire le filet de sécurité maintenant pour maintenir ce code plus tard!
Pour tous ceux qui pensent que couvrir 100% du code par les tests (unitaires, d’intégration et d’acceptation) est inatteignable… Voyez-le comme un objectif plutôt; c’est une courbe asymptotique, comme Vincent le dit si bien.
Mais n’empêche, il a réussi à nous montrer un projet où le seul code non couvert par des tests qui passent est le code qui permet d’améliorer les messages d’erreur quand les tests échouent. Sa couverture est donc de 99%. Définitivement, la meilleure pratique à utiliser par les équipes qui veulent faire du code de qualité est de faire du TDD. En plus d’assurer de la testabilité de leur application, cette pratique s’assure que toutes les lignes codées ont été testées, que le code est réusiné (refactor) en permanence et que le comportement du système en développement correspond bien à ce qui est attendu.
Étonnant, passionnant, et asymptotique 
Présentation en ligne sur SlideShare.
Mes photos de l’événement sont disponibles en ligne
00
Ever heard of Prescott’s Pickle Principle? It states that “cucumbers get more pickled than brine gets cucumbered” As an Agile coach, you are that cucumber bravely diving into a pool saturated with sodium chloride called “The Corporation”
In an Agile transformation context, it’s about the challenges the Agile coach faces when trying to be true with the values and principles of the Agile Manifesto. It’s about being bombarded, day in and day out with those “We can’t do that here!”. It’s that organizational brine that slowly transforms the Agile coach from a change agent into someone who finds great and innovative ways to justify things like ScrumButs and Flacid Scrum.
There’s a saying that goes like this : As a friend, I love you just the way you are. As a coach, I love you too much to let you stay that way. I am not saying that an organization can’t move towards Agile with a few (or many) “Buts” here and there. As coaches, we’d be quite bored (not to mention useless) if Agile values, principles and practices were fully adopted at a flick of a switch. What I am saying is that the Agile coach is not permitted to accept it – Fight the brine!
The symptoms
How can you recognize that you are being pickled? The main symptom is accepting concessions too easily. Some of the classics are “we can’t test this legacy stuff” or “we’ll create an implementation story and a testing story for the next iteration” At first you challenge the team but after a few iteration of trying, you accept it. You might even find yourself using that infamous “We can’t do that here!” You just might be right but that’s besides the point. We are coaches with a big visible agenda: Agile!
5 ways to fight the brine
1- Agile Manifesto – Big and Visible
That’s our agenda. The 4 values, 12 principles and a full inventory of engineering practices. Keep the manifesto in plain site and it’ll help you go back to basics when things get fuzzy.
2- Stay above the clouds
You’re not much good if you’re standing in the middle of the storm with everyone else. Stay above of the technical and business specificities. You risk getting tangled up in the details and start sympathizing. Teams don’t need your sympathy; they need to be challenged from day one to day n.
3- Put on the Thinking Hat
From the get go, inform the teams and management of your stance. Offer them a presentation of the Six Thinking Hats and formalize the fact that you’ll be switching from green to black then green again.
From wikipedia:
Bad points judgment (Black) – logic applied to identifying flaws or barriers, seeking mismatch
Creativity (Green) – statements of provocation and investigation, seeing where a thought goes
4- Keep a Beginner’s Mind
“In the beginner’s mind there are many possibilities, but in the expert’s there are few.” – Shunryu Suzuki-Roshi
When you first walked into XYZ inc. you had no “preconceptions, pre-conceived ideas or prior judgements” Always keep that sense of wonderment and keep asking those basic questions. Almost magically, on a Wednesday at 10:14 am, a team member will say : Hmmm, maybe we could test that. Magical indeed.
5- Go to local and international gatherings
- Agile Conference : Doesn’t get much better than that!
- Scrum user groups, Coaching circles and Agile communities of practice : These are often free and right next door. If none exists in your area…Here’s your chance to start one!
Meeting folks with similar challenges but different solutions won’t only help you fight the brine but can help break Group Think with the injection of fresh new ideas.
How do you fight the brine?
+20
Is your team is interested in new approaches to encouraging meaningful discussion about big opportunities or challenging problems? Playing with Lego can help! Serious fun can result in serious work getting done in not a lot of time, with a lot of laughter along the way.
Lego Serious Play is a playful approach to tackling challenging conversations about individual professional development, team dynamics and organizational strategy and planning. Through playful work, you can engage the creativity and enthusiasm of employees who may not be contributing everything they have to offer. Strategic Play with Lego Serious Play always includes 4 phases:
1) Building a model
2) Giving meaning to the model
3) Making a story to share the metaphor and meaning with others
4) Reflecting upon the knowledge that emerges and considering how to proceed.
Everybody builds. Everybody talks. The result is the emergence of a truly shared understanding that incorporates every participant’s point of view. It’s hard work, but it’s also a lot of fun, which helps people stay in the flow zone where they are the most engaged in the work at hand and creating the most valuable insights.
Working with Michael Sahota, I’ll be co-facilitating some Strategic Play with Lego Serious Play this weekend at Agile Coach Camp US in Columbus OH. I’ll tell you more about how it goes in my next post.
00As an Agile Coach, what’s the first thing you do when you walk into the meeting room?
Well, I observe and listen. I pay attention to individual behavior and the interactions before, during and after the meeting. Then I start labeling! Sounds horrible doesn’t it? But it really isn’t. It might also seem as if I’m judging. But I’m not. It’s simply a quick a dirty way to get a feel for the team and serves as first step to better understanding its dynamics.
The Labels
I don’t have the luxury of time (nor the brain power) to perform a MBTI psychometric assessment of each team member in real-time. Although we might complete a MBTI assessment at some point during the project, at first I rely solely on four high level social styles : Analytical, Driver, Amiable and Expressive. Here’s what I look and listen for :
Why do you need to know this
What I’m exposing here is stuff that’s been around for ages. I believe I first studied social styles in college about 25 years ago and then into more hard core stuff in University. The reason I’m blogging about this now is simply because nearly all the ScrumMasters I’ve coached over the years (mostly project managers and tech leads) never heard of this. (Maybe it’s time for the computer science department to enrich its curriculum, but that’s a whole other post…Stay tuned )
So even if you are (or were) a programming guru, are able to recite the 12 principles of the Agile Manifesto by heart or can book three conference rooms for a Scrum of Scrum Sprint Planning meeting with one arm tied behind your back – That’s just the the snowflake on tip of the iceberg.
Gerald M. Weinberg sums it up well when he writes “It’s always a people problem” in his book, The Secrets of consulting
Tim Lister and Tom DeMarco in Peopleware write:
“The main reason we tend to focus on the technical rather than the human side of the work is not because it’s more crucial, but because it’s easier to do. … Human interactions are complicated and never very crisp and clean in their effects, but they matter more than any other aspect of the work.
If you find yourself concentrating on the technology rather than the sociology, you’re like the vaudeville character who loses his keys on a dark street and looks for them on the adjacent street because, as he explains, “The light is better there.”
By understanding the basic social styles and being able to identify the tattletale signs given off every minute of every day by the individuals that surround you, you’ll acquire extra tools to deal with those “complicated and never very crisp and clean” human interactions.
These tools will allow you to :
- Better interpret verbal and non-verbal communication
- Improve your global listening
- Better resolve conflicts and insure better outcomes
- Offer more powerful feedback
- Better target your powerful questions
- Improve team member collaboration
- And the list goes on…
Who are you?
The starting point is knowing who you are. What is your predominant social style? You can perform a self-evaluation but do invite others to help out. Get some input from differente sources such as colleagues, your community of practice and why not a few beer buddies? You should also take the time to fill out a MBTI psychometric questionnaire. The results will astonish you!
Elasticity
Elasticity starts when you have a better understanding of your own predominant social style and are able to identify the social styles of folks around. Only then can you start avoiding or adopting certain behaviors that might not be natural to you or your colleagues. You practice elasticity when you able to “stretch” and reach out to the other social styles. Above all, it’s about being respectful of your team members styles. It starts with you, the coach. Then you can help the individuals on the team to “stretch” and adjust their own behavior to allow a more productive and healthy environment.
The scenario
Let’s say that…
- Diane is definitely the Driver style
- Andrew is big time Analytical
- Allen is the Amiable style
- And the Product Owner is the Expressive style.
Allen likes to start every meeting with a magic trick.
Andrew is already modeling a state machine on the whiteboard.
The Product Owner wants to change the world and is off in every possible direction,
And Diane in increasingly becoming impatient and tries to take control.
And you are…?
(If only it was that easy )
If everyone in the room sticks firmly to their own social style, you’ll start observing distinctive signs of frustration…
- The Driver might become more controlling and start finger pointing
- The Analytical might become aloof and start fixating
- The Amiable might continue to try to find a peaceful resolution but then retire completely
- The Expressive might become more agitated then finally become distant
- You might also notice an increase in volume, a change of pace (faster or slower) and long silences.
(I use the word “might” because, as you know, human interactions are complicated and never very crisp and clean)
Transforming the energy
How do we transform this dysfunctional meeting into a valuable one?
To achieve any kind progress, you first find need to be actively listening to whats happening. Since you are not involved in the specific content of conversation, you can pay attention to body language and go beyond what people are saying and start picking up on the energy in the room.
You can then work on team member elasticity by asking powerful questions. You might ask the following questions to our Expressive Product Owner who is going off in every possible direction :
- What is the essence of what you are telling us?
- What is the first thing you would like to accomplish?
If with these questions you manage to funnel our Product Owners energy, maybe…
- Diane The Driver will get the feeling that things are finally moving forward.
- This will help Andrew The Analytical to start modeling something simpler.
- With reduced tension and conflict, Allan The Amiable will feel more comfortable in joining in.
- Our Expressive Product Owner will feel more focused all the while being listen too.
You might want to take it one step further and…
- Offer to the Driver a chance to lead when defining clear options
- Roll in a white board and encourage the Analytical to structure and detail high level talks.
- Ask the Amiable if the decisions we are making map out well to our core values
- Create a well defined timebox for free expression and brainstorming. The Expressive social style will love it!
It takes practice!
You can start practicing by simply observing dyadic conversations at work and try to identify those Social Style tattletales. Look at who’s driving the conversation and observe the other person’s non-verbal communication. Then try to imagine how more valuable that conversation could have been if elasticity came naturally to both of them.
Understanding the driving force behind each team member and their natural differences can open up brand new opportunities to increase collaboration and improve the overall process. Know yourself, your team members and the surrounding collaborators and you’ll suddenly have additional tools to help create a healthy environment of transparency, collaboration and creativity.
00
Once again, I’ll be at the Agile Conference from August 8th to the 13th…And I can’t wait! (Even if I wasn’t successful in getting my session through…I got over it )
Flying through the Program Guide, I’ve identified what I would like or love to see. This is just an initial plan – a wish list fraught with scheduling conflicts. Tough choices ahead. Maybe I should prioritize, oops! I mean order my list 
My Sessions Backlog:
- Enterprise Agile Visioning and Learning from the Organization to the Person -Jean Tabaka, Julie Chickering
- An Introduction to Non-Violent Communication (NVC) for Agile Coaches -David Chilcott
- Facilitation & Communication in Agile Teams -Michele Sliger
- A Transformation Path to Enterprise Agility: Change Levers, Leaders & Culture -Michael Spayd
- Coaching Success: Getting People to Take Responsibility & Demonstrate Ownership -Christopher Avery, Ashley Johnson
- The Budgeting Black Hole: Predicting the Unpredictable -Johanna Rothman, William Rowden
- The Agile Leadership Kata: Discovering the Practice of Leadership -Tom Perry,
- What We Have Learned So Far: what we got right & what we got wrong -Chet Hendrickson, Ron Jeffries
- Negotiating Agile Contracts -Angela Druckman, Jimi Fosdick
- Agile Methods Influencing Non-IT Projects -Clement “James” Goebel
- Powerful Questions -Carlton Nettleton
- Adaptive Leadership: Accelerating Organizational Agility -Jim Highsmith
- Agile Coaching Self-Assessment — Where do you Stand on the Competencies? -Lyssa Adkins, Michael Spayd
- Resistance as a Resource =-Dale Emery,
- “It Depends on Context”: You CAN get there from here, if you know where here is -Ainsley Nies, Diana Larsen
- Release your team’s intelligent energy through five powerful conversations -Declan Whelan, Bryan Beecham
- Narrative Coaching -Scott Dunn, John DePaola
- Seeing and Steering Systems: Three Pragmatic Tools -Esther Derby
- Creating a Team Culture to Navigate Conflict -Lyssa Adkins
- Do you dare to ask your HR manager to practice KANBAN? -Thushara Wijewardena
- Bad-Assed Double-Loop Learning: From Judgmental to Good Judgement -Derek W. Wade
- From ‘Team’ to ‘Wow team’: an agile team’s journey -Gourav Tiwari, Zainab Alikhan
- Team Traps -Esther Derby
- Undoing Performance Review Damage – Coaching towards Customer Purpose -Harold Shinsato, Chris Sims
- Building an Agile Culture in a Regulated Environment -Michael Meissner
- Agile Hardware and Co-design -Timo Punkka
- Agile From the Top Down: Executives Practicing Agile -Jon Stahl
- Scrum in Sales -Denny de Waard, Jeff Sutherland
- Applying the Dreyfus Learning Model to Focus your Coaching Approach. -Simon Orrell, Jaron Lambert
- Agile Transition in Trouble? Using the Kotter Change Model as a Diagnostic Tool -Alistair McKinnell
- Telling Better Stories with User Story Mapping -Jeff Patton
- Enterprise Scrum at Belgacom -Xavier Quesada Allue
- Agile won’t work here… really? -Candi Rai, Marc-Elian Begin
What sessions are you planning to attend?
Hope to see you there!
Cheers!
Eric
00
Last June, I had the great opportunity to attend Lyssa Adkins’ and Micheal Spayd’s Coaching Agile Teams course in Montreal, Canada. They truly have a unique and lean approach to sharing their knowledge and experiences. One of the skills we worked on is the ability to ask Powerful Questions (PQs)
Powerful questions…
- Are truly open
- Are not asked with a “correct” answer in mind
- Invite introspection
- Reveal additional solutions
- Almost always lead to greater creativity and insight
- Send people into a realm of discovery
Source: Coaching Agile Teams. Co-Active Coaching Whitworth, et al.
Powerful questions might look something like this:
- Is there another way?
- How can you do that better?
- Can you explain that to me?
- What will this get you?
- What is it we’re not seeing?
- What is your responsibility?
As a ScrumMaster or Agile Coach, powerful questions have served us well. We simply listen, ask a question, and once again let ourselves be amazed by the answer. But as ScrumMaster or Agile Coach, we do have an unhidden agenda – that is, insuring that teams and the organization adhere to Agile values and principles and rethink possible solutions within the rules of, let’s say, Scrum. With that in mind, I sometimes allow myself to deepen my questions, all the while avoiding the notorious “leading questions” – implying that I already have an answer.
So instead of stopping at default, abstract level powerful question, I might ask a more concrete question and hopefully, keeping it powerful. I figured it’d be fun and maybe even useful to share some of these questions that reflect real life situations in an Agile/Scrum environment. I’ve divided it in 3 categories: Team, Product Owner and Organizational questions.
PQs for the Team
- What steps will you take to maintain good communication with your colleagues / Product Owner?
- How should the Product Owner hold you accountable for the sprint’s performance?
- What Agile engineering practice will add the most value to this Sprint?
- What action item from our retrospective do you feel you have the most influence over?
PQs for the Product Owner
- What would your Minimal Viable Product look like?
- How do you plan to maximize ROI for this Sprint/Release/Project?
- How can you help in the delivery of the Sprint?
PQs for the Organization
- What will be your reaction when the team fails / succeeds?
- What can the team hold you accountable for in order to have a successful release?
- How can you help the Product Owner?
Do you feel these questions are any less powerful than the more abstract ones?
Do they seem leading in any way?
What powerful questions would you or have you asked?
I’ll continue testing these out over the next few weeks…Stay tuned!
Cheers!
Eric
00Earlier this week at a combined Agile Ottawa/Ottawa Scrum User Group joint event, Joe Little facilitated an entertaining discussion about the basics of Agile release planning. This gathering was instigated by a question at an Agile Ottawa meeting a few months back about whether any sort of release planning happens in an Agile context. Given that much of the Scrum canon just does some vague hand-waving around this topic, it’s understandable that there is some confusion out there about what kinds of release planning a team might wish to undertake before diving into the nitty-gritty of getting things done.
Some teams breeze right past release planning — I’m constantly amazed that organizations in the habit of taking months or years to collect and sign-off on project requirements balk at spending a few days workshopping a release plan before jumping into delivery mode because “It takes too much time! We need to get started!”. Others spend weeks doing big upfront architecture and detailed design in the guise of “Iteration Zero” before writing a single line of code. Neither approach makes sense. It’s well worth spending a brief period of time to take the team on a few trips around the elephant to develop a shared understanding of the problem to be solved, but the amount of time spent should be limited to just enough to develop an understanding of the big picture, get the conversations flowing, and to resolve the relatively few decisions that really must be made up front. For a release plan for 6 months of work, it might be reasonable to spend 3-5 days having a release planning workshop with the whole team: scale up or down relative to your intended release cadence.
So what do you need to do to get started? Here are the basics of Agile release planning:
- Introductions: Get everyone in the room together – product owner, team, key stakeholders – and do some introductions/activities so that people get to know who they’ll be working with. Even in a relatively stable environment, there are likely to be new faces on the team, which means you have a new team.
- Why are we here?: Share the vision statement for the work, and the value of finding a solution (put into dollar terms if you can, or some other quantifiable measure of importance). What are we trying to achieve here? How much is it worth to us to solve this problem? This is a great opportunity for an Important Project Sponsor to make an appearance and explain the value of this project to the organization.
- Create the product backlog: identify the roles/users within the system, and feed that knowledge into a user story workshop to create a release map of user stories based on roles and activities.
- Assign business value to the backlog: Discuss what ‘business value’ means in this context. Then use Planning Poker or another relative estimation technique to assign Business Value Points (BVP) to stories.
- Estimate the backlog: Have any upfront infrastructural/architectural discussions that may be necessary to get a big picture of where things are going and to identify technical decisions that need to be made up front (which are usually fewer than you think). Have the team agree on initial “Definition of Done” at the story and sprint levels. Then use Planning Poker to assign Story Points (SP) to the stories in the backlog.
- Prioritize the backlog: Now you’ve got Business Value Points and Story Points for each item. With those two values, you can then do some very simple math to arrive at a crude-but-useful Cost-Benefit Analysis (CBA):
BVP/SP=CBA
Simple and rough, but very useful to help prioritize the work quickly. So now, prioritize that backlog!
- This is also a good time for the team to start identifying the risks, dependencies and other considerations that need to be made transparent to the team and stakeholders before embarking on this adventure together.
If you’ve now got a prioritized and estimated backlog, the team can probably come up with a very very very rough release estimate of schedule and scope. This estimate will be woefully inaccurate, but should give everyone a sense of what might be possible. After 3 iterations, you can use your velocity data to revisit this release estimate.
Lastly, don’t forget about the regular care and feeding of your Release Plan: During each iteration, the team might have 2 release-focused meetings (sometimes these are called backlog grooming):
- Big picture backlog maintenance (can be done early in the sprint, and maybe everyone doesn’t need to attend this meeting as long as you have a good cross section of skills/views in the room). What does your velocity tell you about how much of that backlog might get done by what point?
- Top of the backlog maintenance so that it’s ready for the next sprint planning (1-2 days before end of iteration, everyone should attend)
Bon voyage!
00
The rate of organizations moving from waterfall to Agile software development practices is staggering! Scrum being the most popular Agile framework, development teams are suddenly being ask to commit to delivering a specific amount of functionality every 2 to 4 weeks. The pressure is immense and committing to something in software development, even for a short period, is risky at best. But Scrum was clear – the team has to commit at the beginning of a Sprint and many used this as the perfect tool to reward, punish and evaluate. Pressure is good. Too much pressure and the whole thing falls apart.
Well a lot people will be going though a rough withdrawal period because in the latest Scrum Guide, team commitment has been replaced with…team forecasting.
Is commitment dead?
The concept of commitment as been used and abused by management, ScrumMasters and even Agile coaches. I should know! I’m one of them! I figured that by making the burndown highly visible and holding team members accountable to their Sprint planning commitment, that somehow it would get done. Worked for me when I was a developer! Oh ya…I also worked nights and week-ends to get it done. This didn’t only mess up the team’s true velocity but I also wasn’t necessarily getting better at what I do.
Asking the team for a guaranteed functionality delivery commitment for a Sprint isn’t only futile but it can also be harmful to a team’s continuous improvement initiatives.
So is commitment dead? Its misguided use might be coming to an end but the team still needs to commit, engage and take responsibility. It’ll simply be used for what it was intended to in the first place – that is committing to something deeper and more meaningful.
So what can the team commit to? Here’s a hint : At the end of a Sprint Planning meeting, focus away from the specific Stories and tasks and ask the team if they can commit to being Agile!
Can the team commit to…
- Satisfying the customer with the delivery of valuable software by the end of the Sprint?
- Working with the business people a daily basis?
- Dropping emails and communicate through face-to-face conversation?
- Working at a sustainable pace?
- Continuously pay attention to technical excellence and good design?
- Maximizing the amount of work not done?
- Inspecting and adapting?
I believe (not so naively) that if a team commits to applying Agile practices rather then to delivering specific functionalities, good things will happen. By committing to bettering their practices, teams will have no choice but to increase their velocity…It’ll just happen! Somehow I think that’s what the co-creators of Scrum had in mind.
The heartbeat
Development teams need to remember that they are not alone when delivering the next best thing in software. They are surrounded by other teams such as marketing, finance, sales and operations. And there’s this other group called clients and they are impatiently waiting for our clockwork delivery of cool features and bug fixes.
Let’s not misuse the word “forecast” and allow organizations to float the other end of the irresponsibility spectrum. During early iterations (more or less Sprints 1 to 4), forecasting can be used in its purest form and teams can offer a “we’ll do our best” estimate. As a Scrum team, we just don’t know what’s gonna happen! But as we move ahead into later sprints, we, as a professional team of experts, need to learn from those early sprints and start expecting the unexpected. Without actually knowing what will happen, we now know that it probably will. We need to start offering our stakeholders some good information through RELIABLE sprint forecasts. We are not the local plaid suit weather forecasters. We are serious forecasters where getting it wrong can lead to dyer consequences. We need to create that reliable heartbeat of high quality product delivery. Only then can our multi-team (development, marketing, sales, communications, finance) initiative effectively and efficiently plan for the future. Notice I didn’t specify Product Owner. The reason is simple: The Product Owner is part of the team and equally responsible, albeit at another level, in creating reliable forecasts.
Good days ahead!
By replacing “commitment” with “forecast”, management and ScrumMasters can no longer (in theory) rely on the blunt tool of pushing teams to reach that infamous 0 on the burndown chart. Hopefully that simple replacement will bring about a mind shift where Scrum practitioners will now focus their energy on deeper team and organizational issues, such as team dynamics, reducing waste and getting upper management buy-in. As for teams, they will continue to deliver great software all the while committing to perfecting their Agile practices.
00
Recent Comments