 Your new post is loading...
Your new post is loading...
Dans LeSS, chaque équipe est dotée d’un Scrum Master dédié à plein temps qui aide ses membres à se concentrer sur l’ensemble du produit. De plus, le Product Owner est responsable de prioriser et clarifier les éléments dans le backlog pour l’ensemble du produit. L’équipe de développement, qui intègre 2 à 8 équipes, est un bloc transversal et auto-organisé partageant un produit de travail.
À l’instar de la plupart des frameworks agiles, LeSS implique que toutes les équipes participent à différents événements, comme la planification de Sprint, le raffinement de backlog produit, les réunions quotidiennes (daily scrum), la revue du sprint, la rétrospective du sprint. Chaque équipe dispose d’un sprint backlog dérivé d’un backlog produit unique.
Embracing agility is more of a process than a decision. When a company decides to adopt an Agile framework, whether a scaling one or not, this decision should be followed by change.
Agile methodologies are not quick fixes for problems. Instead, they are glasses with which to look at the way organizations structure themselves and their teams. They are also a brave step: fully implementing an Agile framework implies letting go of anything that is not working in a team and in an organization at large, and not all companies are ready to take this step — even if they all like to think so.
Regardless, when Agile is implemented correctly and regularly inspected, it can generate effective benefits that include company success, team empowerment, and quality of the delivered product.
Nexus™ est un framework (cadre) d'agilité à petite / moyenne échelle venant de Scrum.org.
Scaled Professional Scrum is based on unit of development called a Nexus. The Nexus consists of up to 10 Scrum teams, the number depending on how well the code and design are structured, the domains understood, and the people organized. The Nexus consists of practices, roles, events, and artifacts that bind and weave the work…
Comment choisir son framework d'agilité à l'échelle ? Voici la quatrième question de notre série Q&A sur l'agilité à l'échelle et SAFe.
How effectively a Nexus works depends on its ability to eliminate dependencies. Eliminating dependencies simplifies integration. Scrum Masters who efficiently perform cross-team refinements save time. Saving time saves money.
Dans le travail du savoir, les "dépendances" ne sont pas causées par des lois immuables de la physique. Ressentir le besoin de planifier plusieurs sprints autour de ces dépendances est le symptôme de l'obsolescence d'une structure organisationnelle, de la stratégie et des compétences. Ceci devrait être abordé directement plutôt qu'être institutionnalisé avec une gestion waterfall de la dépendance qui se déguise sous la forme d'une mise à l'échelle de l'Agile.
L'auto-organisation par et pour l'équipe implique une structure organisationnelle simplifiée et désintermédiée. Les équipes sans rôle se coordonnent directement avec les autres équipes et apprennent directement de l'interaction avec le client. S'il vous plaît, arrêtez de réétiqueter les traditionnels spécificateurs et coordinateurs avec des noms à consonance Agile.
Une Planification efficace d'un Sprint Nexus se déroule en 2 étapes :
Chaque équipe Nexus sélectionne son travail pour le sprint. Il s'agit d'une activité collaborative avec un ou des représentant(s) de chaque équipe Scrum.
Chaque équipe exécute son processus normal de Planification d'un Sprint. Ceci se produit pour chaque équipe Scrum et peut se produire en parallèle.
Au cours de la première étape, un tableau d'Affinage inter-équipes peut être utilisé pour valider que l'information est toujours à jour et pertinente. Comme décrit dans le livre blanc Cross-Team Refinement in Nexus, les dépendances inter-équipes peuvent être visualisées à l'aide d'un tableau d'Affinage inter-équipes comme illustré à la Figure 1.
In our book — the Zombie Scrum Survival Guide — we dive deep into what causes Zombie Scrum; something that looks like Scrum from a distance, but lacks a beating heart. We also offer 40+ experiments…
Short Term: Scrum of Scrums
A common approach to mitigating dependencies as you scale Agile throughout your organization is to use a scaling pattern called a Scrum of Scrums. In a Scrum of Scrums, delegates from each team meet to coordinate efforts and dependencies. A valuable practice is to visualize the dependencies and candidly prioritize according to the value and impact of the work. No pet projects or side jobs are allowed – all the dependencies must be made visible and evaluated against other demands. Another common practice is to ensure the decision makers are involved, so that resolution of impediments is fast and the group is focused on solutions.
If you are a team on the receiving end of dependencies, this is a good first step to relieve the need to attend multiple team meetings. But it is only one step on your journey to less dependencies - there is so much more you can do.
Long Term: Enable Flow, Empower People
Scrum Master or Tech Manager
Overall, be curious and ask powerful questions about each dependency. Don't accept the status quo - dependency mitigation is a complex problem without a clear solution. Open up a dialogue with the Scrum team, the leaders, even the Stakeholders to examine your work from various standpoints.
Get work to "Done." If you aren't getting to Done, first, analyze what might be causing the problem: Are items too big? Are dependencies recognized during the execution of the work and not before? If items are just too big to be completed and fully tested within the time box, you may need to focus coaching and training efforts on vertically slicing small work items – with an emphasis on small. If the problem really is a dependency with another team or a specialist not on your team, discuss some solutions with your team, the Product Owner, and business leaders so they are committed to the behavior changes that are required to get items to a releasable state independent of other teams.
Get the team involved. If the flow of work in your team has the hiccups, perhaps indicated by a high spill-over rate, lots of starts and stops on work in progress, or aging items, consider a retrospective on how to smooth things out. No-one knows better than the development team the art of the possible when it comes to using technology to solve problems. They are also the closest to the work, and they will have good insight to bottlenecks caused by permissions, controls, and expert knowledge only held by a few people.
An online version of The Definitive Guide to Nexus
|
Beaucoup d’entreprises mettent aujourd'hui en place des organisations Agile à l’échelle. Mais quel framework choisir ? Découvrez le grâce à 10 questions !
Événements à l’échelle et la cadence unifiée
Tout d’abord, il faut ajuster le vocabulaire. On le dit haut et fort – on entend souvent parler des « Cérémonies agiles » en tant que réunions régulières timeboxées aux objectifs particuliers dans le Scrum. En effet, ni Scrum Guide, ni Nexus Guide n’utilise ce terme « Cérémonie » de façon formelle, le terme « Événements » (« Events » en anglais) est privilégié. À l’échelle, parler des « événements » prend tout son sens – on ne sacralise pas le déroulement d’un « cérémonial », on veut que certains événements prescrits se produisent pour la bonne planification et du déroulement du travail, de la collaboration et de la satisfaction de tous.
Parler de Nexus, c’est surtout parler de la cadence unifiée. Une seule durée de Sprint – celle du Nexus – donne le rythme à toutes les équipes. Si on aligne la cadence, le passage à l’échelle est plus simple car, si on fait un parallèle avec la musique, tout le monde joue avec son propre instrument, mais en se servant du même métronome commun. Mais démultiplier l’effort, ce n’est pas seulement l’histoire de mettre des équipes au travail en parallèle, il nous faut aussi des instances de synchronisation transverses et des objectifs communs. Pour y arriver, Nexus modifie chaque événement Scrum standard. Dans la plupart des cas, il les enrichit par des suppléments « Nexus » qui assurent l’échange d’information, la prise de décision, la levée des risques et la fixation des objectifs.
Nexus™ est un framework (cadre) d'agilité à petite / moyenne échelle venant de Scrum.org.
Organizations need to move fast and receive ongoing feedback from customers to drive sustainable innovation through continuous discovery and value delivery. But there is a problem — dependencies.
Scrum of Scrums describes one of the first approaches to scale Scrum and is often confused with Nexus Daily Scrum.
When scaling Scrum, we balance cost and effort with benefits and advantages. Costs and effort come from adding teams. Benefits and advantages come from delivering more value in the same amount of time.
L'une des principales responsabilités de l'Equipe d'Intégration Nexus est de coordonner le travail entre les équipes Scrum afin d'atténuer les risques d'interdépendance. Un outil couramment utilisé est appelé le Tableau d'affinage inter-équipes[1] Backlog de Sprint Nexus. Le tableau d'affinage inter-équipes backlog Nexus visualise les PBI (Product Backlog Items) dans une grille bidimensionnelle, pour chaque backlog de sprint d'équipe aussi bien pour le sprint à venir que les sprints suivants. Il identifie puis trace chaque dépendance et visualise à quel point celle-ci est risquée
Je crois qu’il y a quatre niveaux à distinguer dans l’adoption de l’Agile. Ce ne sont pas quatre niveaux de maturité. Ce sont des niveaux distincts pour lesquels les capacités d’ingénierie, de management et de leadership s’expriment différemment selon le contexte. Dans la plupart des organisations, le dimensionnement ne sera pas linéaire, il sera mis en œuvre en fonction des besoins du Métier.
L’agilité à l’échelle, c’est quand l’agilité couvre la stratégie et la tactique avec la gestion de programme comme courroi de transmission; c’est être agile à l’échelle de l’équipe, à l’échelle multi équipes et à l’échelle du portfolio et du budget avec l’utilisateur au cœur des préoccupations. Il y a des frameworks (SAFe, LESS, Nexus, …) pour porter l’agilité à l’échelle de l’entreprise et ils sont tous séduisants mais ce sont des recettes complexes et quand on les applique à une entreprise, le choc peut être violent, Le framework peut être incompatible avec le contexte.
Comment gérer plusieurs équipes en méthode Agile
The TeamsA few weeks prior to beginning development, the Dev Teams refined their dependent items. I knew there was some anxiety. At that point, they were conducting Nexus Daily Scrums, but felt that these daily meetings in addition to the Daily Scrums were overkill, because there were no dependencies between the sub-systems. So they decided to stop. They managed instead with offline ad-hoc conversations about upcoming “dependent” work. However, after a few Sprints, they selected the dependent items that needed to be developed and decided to reinstate the Nexus Daily Scrum and synchronize daily.
|
LeSS Huge est plus approprié pour les équipes plus importantes.
#Les rôles de LeSS Huge :
Product Owner (PO) – un PO pour l’intégralité du produit
Product Owner de domaine – un PO de domaine pour chaque exigence
Scrum master – un SM par équipe
Équipes de développement – 2 à 8 équipes pour chaque domaine, pas plus de 3 domaines
#Les artéfacts de LeSS Huge :
Backlog produit – vue d’ensemble générale du travail devant être accompli
Area backlog – vue du backlog produit basée sur le domaine d’exigence, où les éléments sont divisés, clarifiés et priorisés indépendamment.
Sprint backlog – liste du travail devant être réalisé par l’équipe pour terminer les éléments de l’area backlog.
#Avantages de LeSS :
Met à l’échelle les principes Scrum aux projets de grande envergure en utilisant de petits lots pour livrer des avantages à l’entreprise à chaque sprint
Structure les équipes selon les fonctionnalités
Supporte de multiples équipes travaillant sur un produit
Privilégie la collaboration avec le client plutôt que la négociation des contrats
Les efforts sont axés davantage sur la collaboration et l’apprentissage au sein des équipes