Faites-vous du faux Agile?

 

Selon le 14e rapport annuel sur l'état de l'agilité, les organisations apprennent encore à mettre en œuvre l'agilité. Environ 50% des répondants ont déclaré que la moitié de leurs équipes utilisent l'agilité, et 84% d'entre eux admettent que leur organisation n'a pas atteint un haut niveau d'agilité.

Voyant que les entreprises et les équipes ont obtenu un grand succès après la mise en œuvre de l'agilité, de plus en plus d'équipes s'y affluent et elles passent à l'agilité. Mais ce n’est en aucun cas une tâche facile. Le problème commun est que l'équipe ne comprend pas les principes et les valeurs fondamentales de l'Agile, mais qu'elle fait de l'Agilité au lieu d'être Agile. Cela a finalement échoué. Ensuite, l'équipe ou les membres qui avaient subi cela ont commencé à faire connaître la «théorie inutile agile»: c'est engager tant de trucs et ne ferait que gaspiller plus de travail et de ressources. L'Agile est-il vraiment inutile? Ou vous l'utilisez simplement de la mauvaise manière.

Individuals and interactionsover processes and tools
Working softwareover comprehensive documentation
Customer collaboration over contract negotiation
Responding to changeover following a plan

 Certaines entreprises prétendent faire de «l'Agile», mais ce qu'elles font s'écarte du Manifeste Agile et des principes. En fin de compte, ce n'est souvent pas fait. Robert C. Martin, co-auteur du Manifeste Agile, a déclaré dans une interview que tout outil ou processus qui rend l'équipe difficile dans son environnement de travail ne peut pas être Agile. Les équipes semblent être agiles ne peuvent être que de «faux agiles».

Qu'est-ce que le faux agile?

Les sceptiques agiles ont une poignée de termes qui ont augmenté pour décrire le phénomène appelé «faux agile»:

• Zombie Scrum
• Faux Agile
• Dark Agile
• Agile Theater
• Agile In Name Only(AINO)
• Agile BS

La distinction est que lorsqu'il s'agit d '«être» agile, peu importe le cadre que vous utilisez tant que les principes clés agiles sont conservés. Ce sont les principes que pratiquement tous les «vrais» principes agiles partageraient avec chaque framework Agile.

D'un autre côté, le faux agile est un type de gaspillage. Tout comme ce que les équipes échouées se plaindraient ci-dessus dans la première section de cet article. Il y aura beaucoup de gaspillage car les équipes génèrent un grand nombre de builds opérationnels dans le but de faciliter les retours clients.

Faux symptômes agiles

Agile extrême

• «Agile» n'est pas seulement «rapide». En ce qui concerne l'agilité, un cadre léger, les gens croient à tort que l'agilité est «rapide»: réponse rapide et livraison rapide. Par conséquent, toute l'équipe ne recherche que la vélocité, de sorte qu'elle doit renoncer à la qualité à la poursuite de la vélocité. Un produit axé sur une livraison rapide ne peut pas répondre aux besoins des clients et ne réussit même pas les tests d'assurance qualité.

• «Agile» n'est pas seulement «simplicité». Le dixième article des Douze Principes d'Agile est «La simplicité - l'art de maximiser la quantité de travail non effectuée - est essentielle.» Ainsi, certaines personnes comprendront que le processus inutile doit être simplifié puisque la simplicité est encouragée. Les stand-ups quotidiens prennent trop de temps, alors sautez-les; Les réunions rétrospectives n'ont pas de sens, omettez-le; La préparation des documents est trop compliquée, laissez-la; Agile préconise de répondre aux changements, il n'est donc pas nécessaire de planifier des réunions, de les ignorer ... Les absolutistes pensent souvent qu'il s'agit de simplifier plus en profondeur pour plus de simplicité, puis des réformes drastiques sont effectuées. Cependant, après un arbitrage chaotique, les véritables objets de valeur ont été «éliminés», laissant les programmeurs confus pour continuer à créer des codes dans les jours répétitifs et fastidieux.

Zombie Agile

• Réunion Scrum quotidienne. Le stand-up quotidien est un pont permettant aux équipes agiles de communiquer entre elles. Le stand-up quotidien n'exige pas que les membres de l'équipe rédigent un rapport détaillé et clair sur leur travail. Cela ne prend que deux minutes pour faire une déclaration simple. Le temps total est généralement d'environ 15 minutes. Les 15 minutes ici ne sont qu'une durée approximative, le temps spécifique peut varier en fonction du nombre de membres de chaque équipe et de la nature du travail. Dans le processus de pratique agile, certaines équipes confondent le concept de réunion debout, mais suivent strictement la règle du temps de réunion de 15 minutes. L'exigence doit être remplie dans les 15 minutes, quoi qu'il arrive. Une fois que l'heure de la réunion sera rigide, cela mettra beaucoup de pression sur les membres de l'équipe, les incitant à trouver des tâches au coup par coup pour parfaire la réunion, afin qu'ils ne puissent pas atteindre l'objectif des réunions debout quotidiennes pour promouvoir la communication de l'équipe.
• Tableau Kanban. Kanban est généralement utilisé pour aider l'équipe à réaliser la visualisation des tâches et la transparence du statut de travail, à motiver les membres de l'équipe à travailler et à améliorer la concentration et l'efficacité du travail. Cependant, après la mise en place du tableau Kanban, il y aura également un gros défaut: le tableau Kanban est dans un état semi-inactif et ne peut pas être mis à jour à temps, et les membres de l'équipe ne peuvent pas obtenir les informations de réponse du tableau Kanban. Le résultat de ceci est: Kanban est devenu un affichage qui représente l'agilité. Lorsque le responsable rapportait son travail, il désignait le kanban sur le mur: Regardez, notre équipe se transforme en agile. Mais si le concept agile a été complètement mis en œuvre, personne d'autre ne le sait, sauf les membres de l'équipe.

Agile conservateur

Avant que l'équipe ne passe à l'agilité à grande échelle, le leader doit être agile. Dans une transformation d'équipe traditionnelle vers l'agilité, il est également nécessaire que les dirigeants prennent les devants dans la transition vers l'agilité et possèdent une pensée lean et agile (voir aussi Le rôle de leader dans la transformation agile). Seuls les leaders maigres et agiles peuvent promouvoir l'agilité de l'équipe en utilisant les forces de l'équipe et des individus.

J'ai connu une entreprise dont le dirigeant souhaite conserver le modèle traditionnel de développement en cascade. Lorsque toute l'équipe a commencé à passer à l'agilité, les dirigeants ont toujours préconisé le développement de Waterfall, ce qui a provoqué une grande résistance de l'équipe lors de la mise en œuvre de sprints dans le développement agile. S'il n'y a pas d'attitude unifiée envers la transition agile au sein de l'entreprise, l'équipe agile aura du mal et pourrait conduire à une fausse agilité.

Par conséquent, si vous voulez briser la "malédiction" d'une transition agile médiocre, vous devez avoir le courage de briser les chaînes du modèle actuel de l'équipe, voir à travers le "faux agile" dans l'équipe, changer la stratégie en fonction du réel situation de l'équipe, et vraiment rendre agile "vivant".

Conclusion

Une organisation agile s'adaptera rapidement au changement grâce à des processus préétablis qui lui permettent d'assimiler facilement de nouvelles connaissances et d'intégrer de nouveaux apprentissages dans ses biens ou son expérience de consommation. L'agilité nécessite la responsabilisation des équipes. Cela nécessite de la confiance, ce qui prend du temps. La leçon la plus difficile pour les dirigeants est de savoir comment recruter et apprécier des employés talentueux.

Voir également

• Doing Agile vs Being Agile

Scrum y DevOps

 La gente quiere ir con DevOps en lugar de Scrum porque quieren ser ágiles pero no pueden cambiar su organización. Muchas personas de la comunidad Agile con las que he interactuado piensan que DevOps solo se trata de herramientas para la entrega continua. Vamos a aprender por qué DevOps no se trata solo de herramientas para la canalización de entrega.

Scrum es solo un marco

Scrum es solo un marco simple para el desarrollo de productos complejos que se basa en valores y principios. Scrum no es una metodología prescriptiva que le dice cómo debe verse su proceso. Scrum está muy centrado en lo que sucede durante el Sprint. Scrum no le dirá cómo debería verse su proceso dentro del Sprint. Scrum es un marco aditivo, lo que significa que Scrum solo te dirá los conjuntos mínimos de lo que necesitas para usarlo. Al igual que cuando necesita instalar un software en su computadora, existe un requisito mínimo para la especificación de la computadora, pero no hay nada de malo en instalar el software en una computadora que esté por encima de la especificación mínima. Entonces, con esta premisa, no es ilegal agregar prácticas que mejoren el flujo de su entrega de valor dentro del Scrum Framework.

ZenTao ALM-Open Source Scrum Tool

DevOps: Lean Thinking, Systems Thinking y Value Stream Mapping

DevOps comienza con el pensamiento sistémico y ve todo el flujo de valor en el sistema en lugar de enfocarse únicamente en la fase de desarrollo, analizando cómo el trabajo entra en el desarrollo (el flujo ascendente) y cómo los trabajos se entregan a los clientes (el flujo descendente). El pensamiento sistémico ve cómo todos los elementos interconectados del sistema se afectan entre sí. En un sistema complejo como una infraestructura corporativa, los elementos no funcionan de forma aislada. Hacer un cambio en un elemento afectará a otro elemento del sistema.

Un flujo de valor es cómo el procesamiento de las solicitudes de los clientes en un resultado tangible fluye de un elemento a otro en todo el sistema. Siempre que hay una solicitud, hay un flujo de valor en el sistema.

Además del pensamiento sistémico, DevOps también se basa en el pensamiento lean. El pensamiento Lean consiste en reducir el desperdicio en la cadena de valor. Cualquier actividad que no tenga valor agregado puede considerarse desperdicio. No voy a dar más detalles sobre Lean y tipos de desperdicio en este artículo.

El pensamiento Lean, el pensamiento sistémico y el mapeo de todo el flujo de valor son importantes y funcionan bien con Scrum porque Scrum se basa en el pensamiento Lean. Esto es lo que hago antes de comenzar Scrum en una gran corporación, ver todo el sistema de manera integral y mapear todo el flujo de valor en el sistema primero en lugar de solo aplicar Scrum al departamento de TI. Kanban es una buena herramienta para visualizar todo el flujo de valor en el sistema.

Cuando usamos Scrum y DevOps, todas las actividades en el flujo de valor, desde las solicitudes de los clientes y el lanzamiento del producto, hasta los entornos de producción y los clientes, ocurren dentro del Sprint. Esto no significa que un Sprint sea una mini cascada donde la implementación solo ocurre al final del Sprint o todo el análisis ocurre al comienzo del Sprint. Usar Scrum con Kanban ayuda a dejar de usar Sprint como mini cascada y avanzar hacia modelos basados en flujo de una sola pieza en el Sprint.

Scrum Team aplicando DevOps: la composición

Los equipos Scrum que adopten DevOps tendrán una forma de trabajo diferente a la de un equipo Scrum que no adopte DevOps. No solo su forma de trabajar es diferente, la composición del equipo también se ve muy diferente.

Scrum dice que el equipo de desarrollo está formado por profesionales que entregan los incrementos potencialmente liberables al final del Sprint. Dado que DevOps ve todo el flujo de valor y utiliza el pensamiento sistémico, los profesionales de Scrum Teams que adoptan DevOps son todos los que procesan el elemento de la lista de productos pendientes (PBI) en todo el flujo de valor de principio a fin. Mucha gente ve que el equipo de desarrollo solo está formado por desarrolladores, por eso muchos piensan que Scrum es solo para la fase de desarrollo.

En un equipo Scrum que adopta DevOps, la composición del equipo incluye a todos, entre otros, personal de marketing, analistas, diseñadores de UI / UX, desarrolladores, personal de operaciones, administradores de sistemas, científicos de datos e ingenieros de confiabilidad del sitio. Todos trabajan juntos de forma colaborativa como una sola unidad para ofrecer valor a sus clientes.

DevOps se trata más de cultura organizacional que de herramientas

Como puede ver, DevOps no se trata de herramientas y automatización en el proceso de entrega. De hecho, como hemos aprendido, las herramientas y la automatización son solo un tercio de DevOps (yo diría que es incluso menos). En general, DevOps se trata de colaboración y propiedad colectiva, se centra en el flujo de la entrega de valor y la cultura de aprendizaje y experimentación. Pero, lamentablemente, muchos proveedores de herramientas posicionan DevOps como herramientas y procesos para la canalización de entrega (los proveedores que he visto en mi mercado están más enfocados en herramientas, pero su experiencia puede ser diferente a la mía). Esto entusiasmará a la gerencia porque muchos gerentes a los que he conocido piensan que después de comprar e instalar las herramientas "DevOps" sin cambiar su organización, su empresa se volverá ágil al instante. Es como poner el carro delante del caballo.

Scrum et DevOps

Scrum et DevOps ne doivent pas nécessairement être un choix qu'une équipe doit faire. Découvrez comment une équipe Scrum peut adopter les pratiques DevOps.

Scrum n'est qu'un cadre

Scrum n'est qu'un simple cadre de développement de produits complexes basé sur des valeurs et des principes. Scrum n'est pas une méthodologie normative qui vous indique à quoi devrait ressembler votre processus. Scrum est très concentré sur ce qui se passe pendant le Sprint. Scrum ne vous dira pas à quoi devrait ressembler votre processus dans le Sprint. Scrum est un framework additif, ce qui signifie que Scrum ne vous indiquera que les ensembles minimums de ce dont vous avez besoin pour l'utiliser. De la même manière que lorsque vous devez installer un logiciel sur votre ordinateur, il y a une exigence minimale pour les spécifications de l'ordinateur, mais il n'y a rien de mal à installer le logiciel sur un ordinateur qui est au-dessus de la spécification minimale. Donc, avec cette prémisse, il n'est pas illégal d'ajouter des pratiques qui amélioreront le flux de votre livraison de valeur dans le cadre Scrum.

ZenTao ALM: a free Scrum tool

DevOps: Lean Thinking, System Thinking et Value Stream Mapping

DevOps commence par une réflexion systémique et visualise l'ensemble de la chaîne de valeur dans le système plutôt que de se limiter à la phase de développement, en analysant comment le travail entre dans le développement (en amont) et comment les travaux sont livrés aux clients (en aval). La pensée systémique voit comment chaque élément interconnecté du système affecte les uns les autres. Dans un système complexe comme une infrastructure d'entreprise, les éléments ne fonctionnent pas de manière isolée. Faire un changement dans un élément aura un impact sur un autre élément du système.

Une chaîne de valeur est la façon dont le traitement des demandes des clients en un résultat tangible passe d'un élément à un autre élément de l'ensemble du système. Chaque fois qu'il y a une demande, il y a une chaîne de valeur dans le système.

Outre la pensée systémique, DevOps est également basé sur la pensée lean. La pensée Lean consiste à réduire le gaspillage dans la chaîne de valeur. Toute activité sans valeur ajoutée peut être considérée comme un déchet. Je ne vais pas m'étendre sur le Lean et les types de déchets dans cet article.

La pensée Lean, la pensée systémique et la cartographie de l'ensemble de la chaîne de valeur sont importantes et fonctionnent bien avec Scrum car Scrum est basé sur la pensée Lean. C'est ce que je fais avant de démarrer Scrum dans une grande entreprise, de visualiser l'ensemble du système de manière holistique et de cartographier d'abord l'ensemble de la chaîne de valeur dans le système plutôt que d'appliquer uniquement Scrum au service informatique. Kanban est un bon outil pour visualiser l'ensemble de la chaîne de valeur dans le système.

Lorsque nous utilisons Scrum et DevOps, toutes les activités de la chaîne de valeur, depuis les demandes des clients et la sortie du produit, jusqu'aux environnements de production et aux clients, se déroulent dans le Sprint. Cela ne signifie pas qu'un Sprint est une mini-cascade où le déploiement se produit uniquement à la fin du Sprint ou toute l'analyse se produit au début du Sprint. Utiliser Scrum avec Kanban permet de sortir de l'utilisation de Sprint comme mini-cascade et de passer à des modèles basés sur des flux en une seule pièce dans le Sprint.

Équipe Scrum appliquant DevOps: la composition

Les équipes Scrum adoptant DevOps auront une façon de travailler différente de celle d'une équipe Scrum qui n'adopte pas DevOps. Non seulement leur façon de travailler est différente, mais la composition de l'équipe est également très différente.

Scrum dit que l'équipe de développement est composée de professionnels qui fournissent les incréments potentiellement libérables à la fin du Sprint. Alors que DevOps voit l'ensemble de la chaîne de valeur et utilise la pensée systémique, les professionnels des équipes Scrum qui adoptent DevOps sont tous ceux qui traitent l'élément de backlog produit (PBI) dans l'ensemble de la chaîne de valeur de bout en bout. Beaucoup de gens voient que l'équipe de développement est uniquement composée de développeurs, c'est pourquoi beaucoup en viennent à penser que Scrum est uniquement destiné à la phase de développement.

Dans une équipe Scrum adoptant DevOps, la composition de l'équipe comprend tout le monde, mais sans s'y limiter, les responsables marketing, les analystes, les concepteurs UI / UX, les développeurs, les opérateurs, les administrateurs système, les data scientists et les ingénieurs de fiabilité de site. Ils travaillent tous ensemble en une seule unité pour offrir de la valeur à leurs clients.

DevOps est plus une question de culture organisationnelle que d'outils

Comme vous pouvez le voir, DevOps ne concerne pas les outils et l'automatisation dans le pipeline de livraison. En fait, comme nous l'avons appris, les outils et l'automatisation ne représentent qu'un tiers du DevOps (je dirais que c'est encore moins). Dans l'ensemble, DevOps concerne la collaboration et l'appropriation collective, se concentre sur le flux de la livraison de valeur et la culture d'apprentissage et d'expérimentation. Mais malheureusement, de nombreux fournisseurs d'outils positionnent DevOps comme des outils et des processus pour le pipeline de livraison (les fournisseurs dont j'ai été témoin sur mon marché sont plus axés sur les outils, mais votre expérience peut être différente de la mienne). Cela excitera la direction car de nombreux managers que j'ai rencontrés pensent qu'après avoir acheté et installé les outils «DevOps» sans changer leur organisation, leur entreprise sera instantanément agile. C'est comme mettre la charrette devant le cheval.

Agile vs Scrum

 Waterfall project management is a well-known method in software development, and its basic process is story -> development -> test. It is assumed that the final result is right, if each phase is done correctly. Microsoft uses the Waterfall method and it works well.

However, it has a relatively high failure rate, for the market and requirements are constantly changing. Software pioneers conducted a series of researches, thinkings, and summaries about the problems found in the Waterfall methodology and finally came up with the concept of Agile.

What is Agile?

Agile is an approach that helps one iterate on processes in the Software Development Life Cycle, such as development, testing, and so on. This technique has advantages, including the ability to produce high-value functionality in fast implementation times, which was previously a problem for the traditional waterfall approach. It also helps to enhance customer retention and satisfaction. This is accomplished by splitting down the product into smaller units/builds, allowing the operations to run concurrently. Agile encourages collaboration and face-to-face contact.

Agile Manifesto was release in 2001 by 17 independent-minded software practitioners.While the participants didn't often agree, they did find consensus around four core values.

Individuals and interactions   over processes and tools
Working software   over comprehensive documentation
Customer collaboration   over contract negotiation
Responding to change   over following a plan

Agile approaches include

• Scrum
• Kanban
• Feature Driven Development (FDD)
• Extreme Programming (XP)
• Lean Software Development (LSD)
• Adaptive System Development (ASD)
• Dynamic Systems Development Method (DSDM)

What is Scrum?

Scrum is a simple and lightweight framework that aids individuals, teams, and organizations in creating value by allowing them to respond to complex problems.

According to Scum Guide 2020,

Scrum requires a Scrum Master to foster an environment where:

• A Product Owner orders the work for a complex problem into a Product Backlog.
  
• The Scrum Team turns a selection of the work into an Increment of value during a Sprint.
  
• The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
  
• Repeat

Scrum can be understood in the 3-5-3 structure.

• 3 roles: Product Owner, Scrum Master and the Team.
• 5 events: Sprint, Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective.
• 3 artifacts: Product Backlog, Sprint Backlog and Increment.

See also

• What is the 3-5-3 structure in Scrum?

Agile vs. Scrum

The primary difference between Agile and Scrum is that, while Agile is a project management framework based on a core collection of standards or concepts, Scrum is a specialized Agile approach for project management.         

        Read more HERE.

See also

Are you doing fake agile?

The Ultimate Guide to Remote Team Collaboration under COVID-19

 Organizational leaders, shareholders, or other stakeholders will not quickly forget Covid-19, and all of the job chaos it has created. Many that were not ready this time will learn what worked and what didn't work and be motivated to close the gaps so that they are better positioned in the future by investors in particular. After Covid-19, what is your work-from-home forecast?

Our best estimate is that 25-30% of the workforce will be working-from-home multiple days a week by the end of 2021.

- Kate Lister, President of Global Workplace Analytics

On March 11, the World Health Organisation declared Covid-19 a pandemic. According to a recent report by Slack, an unprecedented 16 million U.S. knowledge workers moved to operating remotely within a few weeks to help flatten the curve of the health crisis.

A  knowledge worker is anyone who holds an office position and/or works with data, analyzes information or thinks creatively in a typical workweek.

With the global concern about COVID-19, we have all the answers you need in one location if your business is implementing a more structured remote work approach for the first time. These recommendations and best practices will extend to any condition that can prevent or render in-office work difficult (e.g., public transit closures or strikes, weather, disease, etc.).

The most critical things to remember about remote work during the Covid-19 pandemic are:

• Remote work surge: As of March 27, an estimated 16 million knowledge workers in the United States had begun operating remotely as a result of Covid-19; this figure is undoubtedly even higher now.
• Remote work experience matters: When workers are new to working from home, productivity and communication is much affected. The positive news is that previous experience is valuable. Many that have worked from home for more than a month have discovered methods and techniques that have enhanced teamwork and job satisfaction.
• Collaboration tools help: Team collaboration tool users showed a stronger sense of belonging when work remotely. They're much more efficient and less likely to have to struggle with delayed or poor communication.
  

ZenTao has been a ideal and helpful tool for team collaboration, either self-hosted or in the cloud. In 2020, ZenTao witnessed an increase of remote teams with 20%. ZenTao can help your remote work with:

• task management: todo, calendar, Gantt Chart
• document management: document library, document online preview and editting
• messaging: intranet and internet chat, add messages as tasks via ZenTao Desktop
  
• audio and video conferencing: screensharing and integration with other systems
  

See also

• Compare with Jira
• Compare with Asana
  

REFERENCE

1. https://globalworkplaceanalytics.com/work-at-home-after-covid-19-our-forecast

2. https://www.fuze.com/the-Ultimate-Guide-to-Remote-Work

3. https://slack.com/intl/ja-jp/blog/collaboration/report-remote-work-during-coronavirus