lean

La radicalité agile pour conjurer le faux agile

La radicalité agile pour conjurer le faux agile

Il faut bien le dire, le terme radical est susceptible d'en rebuter quelques-uns ; d'autres nous demandent pourquoi avoir conservé agilité dans agilité radicale. Retour sur le choix des mots.

Quand nous avons lancé l’agilité radicale en avril 2020 — c’était pour la keynote à Agile en ligne — dans les échanges avec les participants, nous avons eu quelques remarques sur le choix du mot radical :

radical, c’est un peu extrême !

Radical, c’est comme radis, ça vient de racine.

Lecture au klub : Lean Entreprise

Si la science est largement évoquée, les gens ne sont pas oubliés

Le livre choisi pour le klub d’octobre était donc : Lean Enterprise: How High Performance Organizations Innovate at Scale de Jez Humble, Joanne Molesky, Barry O’Reilly. Un gros livre. En anglais, ce qui n’a pas attiré les foules. Mais, bien que je fusse le seul à l’avoir lu entièrement (et sur mon smartphone !), la discussion s’est avérée passionnante. Un livre qui présente plein de choses, certaines dont je parle régulièrement sur ce blog et dans mon livre (le développement agile, impact mapping, lean startup, kanban) et d’autres un peu moins (design thinking, value stream mapping, devops).
L’agilité en mouvement

L’agilité en mouvement

L'agilité est un outil formidable pour découvrir une façon dynamique de faire les choses. Dynamique dans le sens où il ouvre de nouvelles pistes aux personnes qui réfléchissent à leur façon de travailler

J’avais écrit ce texte il y a quelques mois, en réaction à un article prétendant que l’agilité ne répondait pas aux problématiques abordées ci-dessous, alors que le Lean oui. Je le publie maintenant pour rajouter une couche au billet de Pablo Cow boys et hippies.

C’est le moment :)

Lean depuis les tranchées, le draft en VF

Piloter de gros projets avec Kanban, l'histoire de la police suédoise

Henrik Kniberg a publié Lean from the trenches chez The Pragmatic Programmers en fin d’année 2011. Il l’a écrit de façon itérative et a sorti plusieurs versions intermédiaires. C’est une de ces versions, le draft 0.9, que nous avons traduite. Bien sûr, c’est avec l’accord d’Henrik : Cette version draft est gratuite. Je l’ai rendue disponible pour ceux qui ont un budget serré et qui ne peuvent pas s’offrir le livre, ou qui souhaitent parcourir le draft pour se faire une idée générale de la portée du livre avant de l’acheter.
Le multi-tâches c'est mal

Le multi-tâches c'est mal

Combien faut-il de temps pour écrire un prénom ?

Ça dépend.

Ce matin, commençait ma (déjà !) 8ème formation de l’année. Je fais notamment une série de formations Scrum pour les développeurs qui travaillent sur le smartphone d’Intel à Toulouse.

Dans mon fil twitter j’avais vu passer il y a quelques jours la traduction en français du jeu inventé par Henrik Kniberg pour illustrer les méfaits du multi-tâches.

Séminaire 'L'agilité : du projet au programme et à la ligne de produits'

IBM Toulouse organise le 10 Novembre prochain, sur le site de la Plaine, un séminaire sur l’agilité au-delà du projet, pour des produits qui évoluent longtemps, font partie de programmes ou d’une famille de produits ou sont inclus dans un portefeuille de produits J’aurai le plaisir de faire la présentation sur ce sujet et je dispose d’une bonne partie de la matinée. Les premiers inscrits recevront un exemplaire de mon livre « SCRUM : le guide pratique de la méthode agile la plus populaire » publié aux Éditions DUNOD, qui leur sera remis le jour du séminaire.
Limitez le TAF

Limitez le TAF

Diagramme de flux cumulé

Celui-ci a été produit avec l’outil IceScrum. En abscisse on a les sprints. En ordonnée, on a le nombre de stories dans chaque état de son workflow. Dans cet exemple, les données sont celles du projet IceScrum lui-même. Les sprints durent 2 semaines et représentent environ l’équivalent de 3-4 jours de travail (les membres de l’équipe sont à temps partiel). Ce type de diagramme a été mis en avant par David Anderson qui promeut le Lean Software et en particulier la pratique du Kanban[1].

Rétrospective 2009

Pour Scrum et les méthodes agiles, l'année 2009 a été celle de la confirmation

Je vais essayer de faire un bilan de l’année sur quelques aspects qui ont été significatifs de mon point de vue. La diffusion se poursuit La place de l’agilité et de Scrum dans le développement de logiciel a continué d’augmenter. Cela se voit dans les médias spécialisés. Les grands éditeurs sont désormais aussi porteurs du message agile. On peut dire qu’il y a un buzz, mais au-delà de l’aspect communication, la diffusion se poursuit en France.
Le burnup

Le burnup

Mieux que le burndown

Le burndown chart montre bien ce qui reste à faire, mais on n’y voit pas les évolutions de périmètre. Il y a 2 ans, j’avais présenté l’intérêt du burnup à 2 courbes pour pallier ce manque du burndown.