À l’instar des autres pratiques de développement, la revue de code ou le mob programming ne peuvent pas se mettre en place indépendamment de considérations sur la culture de l’entreprise qui souhaite encourager ces pratiques. Certaines cultures d’entreprise favorisent activement la formation d’équipes en cohésion (principalement en ne plaçant pas d’obstacles à leur formation). Dans d’autres cultures, la notion même d’équipe est dénuée de signification réelle. De la même manière qu’aucune pratique de développement ne saurait être « copiée/collée » d’une entreprise à l’autre sans considération du contexte, il est apparent que toutes les entreprises ne sont pas égales devant le défi que constitue le développement d’un logiciel de qualité. La présence ou non des revues de code dans leur corpus de pratiques est à mon sens une preuve de cette inégalité.
We start our re-read of Monotasking by Staffan Noteberg. The book is 237 pages published by Racehorse Publishing (an imprint of Simon & Schuster) and was released in English on June 1, 2021. For most of the readers of the blog and listeners to the podcast, this will be an initial read.
Get a unique collection of radically collaborative patterns for building software with others. In this mini-encyclopedia, third-generation programmer Matthew Parker introduces you to 27 successful patterns used in organizations that follow distinctive methodologies such as Scrum, Extreme Programming, SAFe (Scaled Agile Framework), and others.
Has your team “gone Agile“ yet still falling short on deliverables? If yes, it may be time to revisit one of the most powerful patterns in Scrum: Swarming. The benefits speak for themselves and show proof from the very first Sprint. Listen in as Dr. Jeff Sutherland explains the benefits and pitfalls...
[00:00:00] The most common cause of a team being late, not having everything done at the end of a sprint is that everybody is working on their own thing. And so everything is open. If you look at the scrum board, everything is open and nothing is done. So then when it gets to the end of the spread where everything has to be tested at once, there's not enough time to do that and the sprint fails.
[00:00:38] So the challenge is how to get people working together in a way that systematically bring stories to done. So at the end of the spread, everything is done, or the least amount of things are not done. And we spent many years working on how to describe what is needed. In a way that's consistent with scribe and fits in with the other patterns.
[00:01:06] And after many years of work, the title of the pattern is called swarming. We want multiple people working on an individual story. Now, why is that? Well, we know from Jerry Weinberg's, uh, book on quality software. He did an analysis of what percent of time is available for people to do actual work if they're working on multiple projects.
In software development, organizing Scrum Teams to have cross-functional membership and allocating work via swarming work well. In hardware development, these two things are at odds, and only one can be accomplished. The goal is always to develop a successful product at minimal cost, as quickly as possible, so I favor having cross-functional skills on teams over the ability to swarm. Risk and cost increase if we insist on forming single-skill teams in order to enable swarming within them.
Swarming is a technique that helps agile teams to deliver working software fast and frequently. What is swarming, what are the benefits of swarming, and when and how to apply it?
Setting a limit on the number of Stories a Team can work on at a time is frequently used to harness Team focus, reduce noise and bolster productivity.
However, for a Team like Mark’s with a significant skill-set gap, limiting WIP provides several other benefits as well.
Essentially, limiting WIP forces the entire Team to swarm. Restrictions on WIP mean there are no options for a Dev, Junior or Senior, to dive into a new Story from the Backlog. The Team has to work together. It’s an outstanding learning opportunity for both levels of Devs.
Swarming is when an Agile team need all available personnel to work on a single problem. In this article, we offer a quick review of Swarming and how to use it.
The future of artificial intelligence is self-organizing software. Multi-agent coordination and stigmergy will be useful in our quest to discover dynamic environments with decentralized intelligence. In every field, there’s a pioneer, a prototype, an individual or group that blazed the path forward to uncover previously hidden value. Observing the giants in artificial intelligenceallows us to revisit …
Mickael Ruau's insight:
A swarm is simply a group, right? What if we could design intelligence systems to optimize learning? These systems wouldn’t only exemplify stigmergic environmental properties. They would also build on properties of traditional group dynamics. If you’re in the gym and notice people are staring at you, you’re able to bike a little harder, run a little faster, or lift a little more. What if we could design artificial intelligence systems that would be intelligent enough to embrace these same feelings? Sure, we’re talking less about feeling and more about procedures or rules that we apply in context — but the term “feelings” sounds better to me.
Collective behaviors contribute to solving various complex tasks.
These four principles are found in insects that collectively organize. They should also be found in the artificial intelligence systems we create:
Coordination: organizing using time and space to solve a specific problem.
Cooperation: agents or individuals achieve a task that couldn’t be done individually.
Deliberation: multiple mechanisms when a colony or team faces multiple opportunities.
Collaboration: different activities performed simultaneously by individuals or groups.
Whether we’re adding blocks to a blockchain or changing the rights individuals have to shared content, the study of interactions might hold the key to unlock the next generation of artificial intelligence. Before exploring the benefits of dynamic systems and chaos theory, we must apply the principles of artificial intelligence, mass collaboration and group dynamics to expand our knowledge of how systems self-organize.
The best way to perform quickly and accurately we should try to minimize the period of the Storming phase. There are so many ways to achieve this goal in different processes of product development, but in Scrum Agile it is the one of the behavior or nature of the process itself. The way Agile is designed it always try to minimize the Storming phase.
Mickael Ruau's insight:
How Agile minimize the Storming phase?
• Scrum Master: Agile has the concept of Servant Leader (a Scrum Master), who is not the team leader or a project manager, rather he would be the person whose primary goal is to resolve the impediments of the scrum team and try to provide the way by which scrum team can easily work to complete the defined tasks, user stories, and epics. By avoiding tangible and intangible impediments scrum master helps to shorten the period of the Storming phase.
• Scrum Team and motto — The self-driven team has qualities like being transparent, courageous helps to avoid the storming phase. In the scrum, the measurement of success would define by the team not by the individual so the whole team would represent as one team and try to achieve the one goal. The team should be cross-functional and so when someone has extra time in the defined sprint, they can pick any task and/or user story and try to accomplish it based on the definition of ready and definition of done.
• Inspect and Adapt — Scrum is the process of inspecting and adapt due to that at the beginning of the problem, issue or impediments, people come to know about it and try to solve it or try to identify the way of execution to avoid or prevent any hurdle. This helps to avoid unnecessary procrastination and blame game.
• Ceremonies— The rating and evaluation of user story in Sprint planning meeting is teamwork, it may avoid the in justification in the evaluation and task allocation. Also based on capabilities and the availability we would take the task so it may avoid dependencies, and help all to grow based on their skills. Daily stand up meeting helps us to identify the dependencies, impediments of the individual or team is facing and by avoiding it we can resolve the internal conflicts. Sprint review meeting where everyone is present may clarify the expectation of the stack holder also which would get the transparencies among the team. A neutral and unbiased Retrospective team meeting may help us to identify the improvement area, there are so many ways to achieve this, but the primary criteria would try to address the concerns not to address any individual may help us to minimize the storming phase of the Tuckman principle.
In a nutshell, if we follow the traditional agile process and follow the SBOK it may help us to minimize the storming phase and we will be easily moved to the Norming phase. In any case, if we have to customize the agile process then it would be great if we can follow its basic principle, team qualities, and try to celebrate its all ceremonies to minimize the storming phase of the principle.
Llewellyn Falco s'exprimait sur le Mob Programming durant la première conférence sur le sujet. Il explora la différence entre le développement solo, en pair et en bande, ainsi que les raisons produisant un meilleur résultat avec le mob programming : "ce n'est pas obtenir le plus possible des gens, mais le meilleur".
Mickael Ruau's insight:
L'intervention de Llewellyn Falco, intitulée "Understanding the Science of Mobbing", part du principe que le Mob Programming n'est pas une science - tout comme l'informatique (computer sciences en anglais, NdR). Il y a pourtant des pratiques partagées sur la manière de développer des logiciels :
Le Solo programming est sans doute la pratique la plus admise aujourd'hui, qui implique que tout ce qui est produit entre dans le code, le bon comme le mauvais.
Le Pair programming est la seconde manière la plus connue de développer et les meilleures idées de chacun entrent dans le code.
Le Mob Programming est enfin la dernière pratique, et sans doute la moins connue, et comme l'explique Llewellyn : ce n'est pas obtenir le plus possible des gens mais le meilleur.
Où est donc la science ? Llewellyn fait un parallèle avec la théorie des systèmes : une équipe forme un système. Et c'est un système complexe. Il est difficile d'en isoler une partie, ou pour paraphraser Dan North : "Quel est le son de l'applaudissement d'une main ?".
Démarrer quelque chose dans un système est comme allumer un feu de camp. Dans une équipe de développeurs autonomes, même les très bonnes, lorsque quelqu'un est bloqué, il reste coincé seul. Pour qu'une idée grandisse, comme pour le feu, il faut des brindilles, et en quantité. C'est le principe du Mob : disposer d'un ensemble de personnes pour nourrir une étincelle.
Pour utiliser une image différente (qui ne vient pas de Llewellyn), c'est l'exact opposé d'un épisode de Docteur House (ou le dernier épisode de la saison 1 de Silicon Valley) : quelqu'un a une illumination, ou lance une idée, et le reste de l'équipe contribue pour la rendre meilleure.
Cet impact est similaire avec la mémoire et la mémoire de groupe. Cette dernière est plus robuste que celle d'un seul esprit, et une bande peut déclencher des mémoires multiples. Il en va de même avec la résolution de problème : l'état de votre système favorise ce que Takeuchi et Nonaka appellent la "diversité". Et c'est un état nécessaire quand les choses tournent mal.
This week is a doubleheader (baseball term for two games played by the same teams on the same day against each other). We begin our re-read of Monotasking by Staffan Nöteberg and we have my interview with Staffan.
Successful swarm facilitation is about building relations and trust with team members. Similar to an agile scrum team, a swarm is a lean kanban team focused on delivering software.
Mickael Ruau's insight:
Dale Carnegie’s classic, “How to Win Friends and Influence People” is a great blueprint for helping swarm facilitators learn to norm and quickly form teams. The book was authored in 1936 but is eternally relevant. Listed by Library of Congress as the seventh most influential book in American history, generations have benefited from it in the past as well as future generations. While all the topics of the book can be implemented, we will touch on the topics most important for a swarm facilitator to employ. The book is broken up into 4 areas:
Techniques in handling people
Ways to make people like you
Win people to your way of thinking
Be a leader: How to change people without giving offense or arousing resentment.
I will save the last section for a future post and focus on the first three topics.
Swarming is the act of all development team members working on only one requirement at a time during the sprint. Although not a principle specific to scrum, it is such an effective way for teams to execute their sprint backlog that it warrants some more discussion. Again, one of the main benefits of scrum is …
Mickael Ruau's insight:
Recently, Microsoft conducted a study on the effects of multitasking. The results were that multitasking just doesn’t work. On average, it takes 15 minutes to get your brain back to the level it was at before you answered that phone call or email. Studies have also shown that an interruption as short as 4.4 seconds will triple the number or errors made on subsequent tasks requiring sequencing. Reducing multitasking in your development team will get you a sound head start on achieving the 30–40 percent increased product-to-market time.
Thrashing is when developers jump back and forth between projects, requirements, and tasks — context switching. Thrashing increases the time required to complete tasks by 30 percent. If you don’t have enough people to take on the workload as dedicated, swarming developers, you definitely don’t have time to thrash them.
Team Swarm is where a Team works on just a few Stories at a time. Each Story is finished as quickly as possible by having many people work on it together.
The Agile Architect explains how to increase productivity significantly while also increasing code quality with a simple process change.
Mickael Ruau's insight:
From this experience, our process for development, which we've only changed slightly, has fundamentally altered how we work. The rules now are:
Each feature is developed on its own branch.
As many developer pairs as possible work on the most important story in process.
Each story is developed directly on the feature branch, allowing stories to share code changes.
(...)
Our configuration management tools have led us down the wrong path. They make it so easy to develop code in isolation that they imply that we should develop code in isolation. Nothing can be further from the truth. Lean principles tell us that we want to complete stories and features as fast as possible. That means using the entire team on a single story as though they are of one mind. And the only effective way to do that is to swarm!
To get content containing either thought or leadership enter:
To get content containing both thought and leadership enter:
To get content containing the expression thought leadership enter:
You can enter several keywords and you can refine them whenever you want. Our suggestion engine uses more signals but entering a few keywords here will rapidly give you great content to curate.
Your new post is loading...
