The S.T.O.P (Sit, Think, Organize, Perform), is one of my new favourite Trello Inspiration Boards, shared by Stanley Fuller. You can get your own copy here: https://trello.com/b/F3aSiZPs/stop-board
Research and publish the best content.
Get Started for FREE
Sign up with Facebook Sign up with X
I don't have a Facebook or a X account
Already have an account: Login
Devops for Growth
107.5K views |
+0 today
For Product Owners/Product Managers and Scrum Teams: Growth Hacking, Devops, Agile, Lean for IT, Lean Startup, customer centric, software quality...
Curated by
Mickael Ruau
 Your new post is loading...
Your new post is loading...
Scoop.it!
Grâce à une étude consistant à solliciter chaque individu de l’organisation en lui demandant de noter les cinq ou six éléments principaux de la meilleure équipe dont il ait fait partie, elle a pu déterminer, après avoir regroupé et traité les réponses en groupe, les sept caractéristiques communes aux meilleures expériences des individus interrogés. De ce résultat est né un acronyme que chaque facilitateur pourra garder en mémoire : PERFORM.
Vous aurez remarqué que, jusqu’ici, il n’y a aucune notion explicite d’Agilité, de framework ou de pratiques quelconques. Pourtant, ces sept caractéristiques sont en total accord avec le Manifeste Agile sur lequel repose l’état d’esprit que nous nous efforçons d’insuffler aux équipes que nous accompagnons. 
Scoop.it!
Joanna Zweig spent more than ten years researching group characteristics for her Ph.D. dissertation. She formed the Group Coherence Cooperative Inquiry (GCCI) group to learn about Group Coherence. This research team used Cooperative Inquiry, a group research method consisting of cycles of action and reflection to answer a question that the group agreed upon. The question was "What is Group Coherence?"
Mickael Ruau's insight:
Types of Group Coherence
Scoop.it!
Scoop.it!
Pour faire suite à mon billet précédent qui parle de l’évaluation des performances individuelles, j’ai pensé qu’il pourrait être pertinent d
Scoop.it!
Depuis toujours, dans le monde du logiciel, on entend « Il faut augmenter la productivité des développements ». Il ne suffit pas d’en parler pour améliorer la productivité. Comment passer d’un slogan très abstrait à des actions concrètes et des résultats tangibles ?
Scoop.it!
La mesure de la productivité des développeurs « à la ligne de code » n'a aujourd'hui plus lieu d'être. Sauf à les transformer en dactylos.
Mickael Ruau's insight:
La vitesse limite absolue de codage est estimée à 6 500 lignes source de code par personne et par mois. C'est une limite physiologique impossible à dépasser. La vitesse limite " relative " est quant à elle de 2 200 lignes et inclut un minimum de réflexion. La vitesse de programmation dite " artisanale " chute à 1300 lignes, tenant compte d'une phase de conception et de la rédaction d'un brouillon. Et si on vous demande une programmation industrielle, c'est-à-dire documentée et répondant à des standards de codage précis, vous vous situerez entre 220 et 350 lignes par mois.
|
Scoop.it!
Serving in the role of Product Owner (and development team) for a fruit salad requires you to make many decisions that parallel real life. It’s amazing how something as simple as a fruit salad brings up all the hard things a Product Owner will have to deal with and make tradeoff decisions about. Here are some decisions that had to be made in order to develop this fruit salad from a Product Owner’s perspective
Scoop.it!
In order for a team to improve process efficiency, they will have to stop multi-tasking and execute the Swarming: One-Piece Continuous Flow pattern. This is well known to radically increase the flow of story completion and is fundamental to lean production at Toyota.
Mickael Ruau's insight:
We want to abandon hours as a reporting tool for Scrum teams as data on over 60,000 teams in a Rally survey shows that the slowest teams use hours. The fastest teams use small stories, no tasking, and no hourly estimation. How can we estimate process efficiency for these teams?
Scoop.it!
In this team, we valued getting metrics about our own performance. Similar to what is described in the Kanban Guide for Scrum Teams. We also measured a metric that we didn’t have a name for. It was the ratio of the time we spent working on a story to the total time it took to get the story in production. Our ratio was horrible (0,7%). This was astonishing to us because we thought of ourselves as one of the most productive teams in the department.
Scoop.it!
Réduire ses encours de développement et augmenter sa productivité pour un investissement minimum : telle est la promesse de la théorie des contraintes.
Mickael Ruau's insight:
Un des principes forts de la ToC est de concentrer ses efforts d’amélioration là où ça compte le plus. La démarche 5FS (« 5 Focusing Steps ») est là pour le mettre en oeuvre :
Le Drum Buffer Rope illustré pour une usine classique… mais qui fonctionne aussi pour une usine logicielle ! (source : wikimedia) Quand et comment utiliser la ToC dans une équipe logiciel ?Avant de passer à la ToC dans une équipe de développement, je recommande de mettre en place Kanban.
Scoop.it!
La performance des équipes de développement Comment la mesurer ? Indicateurs de qualité, productivité, dette applicative, alignement sur les besoins métier.
S’il est facile de mesurer la performance d’une entreprise ou de comparer les performances des ventes ou des services financiers en utilisant des ratios du métier, l’exercice qui consiste à mesurer la performance d’une équipe de développement reste complexe. Il est assez aisé de mesurer les coûts, mais comment mesurer la valeur réelle de ce qui est produit ? La clé d’une meilleure performance réside dans la façon dont l’équipe de développement contribue à améliorer l’efficacité de l’entreprise. Et cela nécessite une réelle collaboration entre l’équipe de développement et les autres départements. Nous avons identifié 6 axes d’évaluation de la performance d’une équipe de développement logiciel : -alignement -qualité -productivité -évolutivité -prédictibilité -créativité
Scoop.it!
Les 6 vérités de la programmation, se vérifient-elles autour de vous ?Un développeur américain explique sur son blog que son expérience professionnelle dans le domaine de la programmation lui a permis de faire quelques constatations à propos des professionnels de l'IT et de leur manière d'écrire du code.Les voici :- Un programmeur passe entre 10 et 20% de son temps à coder, et écrit en moyenne 10 à 12 lignes de code par jour qui seront incluses dans le produit final (peut importe leur niveau)
Scoop.it!
Combien de temps perdez-vous en réunion ? Trouvez-vous vos réunions réellement productives ? Etes-vous sûr d’avoir vraiment tout essayé pour optimiser vos temps de réunions ? Hum, hum…pas sûr…connaissez-vous le lean coffee ? … Via PhCourcier
|
Here is how it works:
Daily STOP:
1)At the beginning of the day, arrange the cards in the list to the order you plan to attack the items. If you don't feel that you'll be able to get everything done, move items to the next day, and adjust the rest of the weekly schedule as necessary.
2)Mark-off checklist items when complete. Close the card when all checklist items are complete.
3)At the end of the day, move anything that didn't get done to the next day, and adjust the rest of the weekly schedule as necessary.
4)As more things come up that week, work them into the weekly schedule, or put them on next week's list.
5) When approaching the end of the week, begin moving items to next week's list if needed.
Weekly STOP:
1)Every Monday, pull the current week's list over in front of the "Monday" list.
2) Assign tasks to team members as desired.
3)Distribute the items in the list to the days that week you plan on starting the item. This will depend on the hard points in your calendar (meetings, trips, appointments, etc.).
4) Items assigned to others may remain in the weekly list.
Monthly STOP:
1)Sometime around the the middle/end of the month, create lists for each week of the upcoming month.
2)Distribute the items in the upcoming monthly list to each of the newly-created weekly lists.
3) Create new monthly list(s) in order to have around three to four that you can move yearly items into.
This is great for time blocking and for splitting your work into bite size chunks when you have a timeline to work towards. I currently have a Today and Tomorrow Board, but like how this is broken down by day of the week, weekly and monthly and it evolves as each day is completed.