Quand l'agilité n'est plus une fin en soi
La tentation d'introduire des pratiques agiles pour « faire agile » est un piège que j'ai déjà vécu. Je vous propose quelques exemples montrant l'agilité face à quelques cas concrets.
Informatique, économie, Bitcoin (forcément 😏), et puis plein de trucs random …
La tentation d'introduire des pratiques agiles pour « faire agile » est un piège que j'ai déjà vécu. Je vous propose quelques exemples montrant l'agilité face à quelques cas concrets.
Le Well Architected Framework nous donne le cadre pour faire croître notre produit, ou plutôt « nos » produits... L'entreprise continue de s'agrandir, et de nouveaux acteurs interviennent.
Passer du « vibecoding » à l'infrastructure « Enterprise Ready »... À quoi ressemblera le Product Builder du futur ?
concevoir une architecture robuste ne suffit pas. Nous devons également savoir ce qu'il s'y passe réellement, en temps réel... sans attendre que les utilisateurs nous signalent les pannes.
Grâce à l'IA, nous avons développé une superbe application, le trafic décolle... mais comment faire face au succès sans voir notre infrastructure s'effondrer ?
Au-delà de l'instance unique, le réseau est notre véritable fondation, lorsque nous commençons à structurer notre application avec plusieurs services.
Nous avons « vibecodé » une superbe application, mais ... où allons-nous la loger ?
Plus ça va, plus nous pouvons créer des prototypes bluffants, avec l'IA. Il faut désormais amener cette dernière au niveau d'expertise le plus pointu, pour arriver jusqu'au produit fini.
Quand nous parlons d'automatisation, nous ne pouvons faire autrement que de passer par la case Git, « le » système pour versionner nos projets. Mais comment bien l'employer ?
Il y a déjà quelques temps, je m'étais déjà lancé dans quelques partages sur le scripting, l'automatisation et le Cloud. Je vous propose aujourd'hui de revenir sur ce premier point.
Nous parlons beaucoup d'implication collective, à l'échelle de l'équipe Agile... Mais derrière ce « collectif » se cachent des individus.
Dans ce nouvel article, nous explorons un peu plus avant le sujet des indicateurs, dans le cadre d'une perspective un peu plus large que l'équipe : celle des objectifs produit.
Nous sommes tentés de voir la mesure de la performance comme antinomique avec les méthodes agiles. Eh bien peut-être pas…
Pour certaines équipes et certains managers, l'implication du Scrum Master – ou même le fait d'incarner le rôle – n'est pas forcément clair... Si l'équipe est autonome, sert-il encore à quelque chose ?
Jusqu'à présent, nous avons introduit les grands principes de l'agilité, en insistant sur la transparence qui est fondamentale. Mais pour que l'équipe avance, il lui faut un but.
L'un des piliers des Méthodes Agiles est la transparence. C'est l'une des clés pour assurer l'efficacité de l'équipe dans la production de valeur.
Entre la théorie des formations d'Agile et l'expérience du terrain, ou comment je me suis forgé ma propre expérience.
Au travers de ma dernière série sur le PRD, j'ai déjà évoqué l'intérêt de livrer régulièrement et dès que possible en parlant d'itérations, mais je voulais en rajouter une dernière couche...
Pour terminer cette série sur le PRD, je vous propose de sortir légèrement du cadre et d'explorer ce qui suit la Discovery, ou exploration : l'implémentation, et comment le PRD suit les itérations agiles...
Le PRD fait le pont entre le besoin de l'utilisateur, nos hypothèses sur la gêne à traiter, et la solution que nous allons proposer en réponse. Ici, nous allons voir concrètement comment le rédiger.