Laurent Morisseau's Blog, page 10
August 23, 2015
Agile Digest 35
Cette semaine, on parle de prédictibilité, du rôle du Product Owner; d'autres que moi s'intéresse au Kanban pour Startups. Et quitte à parler Kanban, Jim Coplien challenge cette méthode en le remettant en perspective du Lean et du one piece flow.
Côté startup, un riche retour d'expérience évoque le rôle de mentor; on parle également de l'avantage unique et des incubateurs.
Cet article Agile Digest 35 est apparu en premier sur Morisseau Consulting.
August 20, 2015
Agile Digest 34
Agile - Kanban - Scrum - Lean Startup
Découvrez l'actualité agile qu'il ne fallait pas louper cette semaine !
Agile Digest 34
L’écosystème agile
A lire cette semaine l’article sur les mouvements agiles du mouvement agile de Pablo Pernot, le joueur de Banjo agile qui porte fièrement son nom d’agent provocateur :o)
Google+
Agile Timeline
Ce post a fait débat, surtout sur la validité des dates. En fait, je n’avais même pas regardé les dates car dans son blog, Pablo précise bien l’aspect flou de celles-ci.
Je l’ai relayé, bien que je ne sois pas d’accord avec tout ce qu’il y est écrit, et c’est normal, on a chacun son avis et son prisme de lecture. Je l’ai relayé, donc, car il n’est pas à destination des experts justement, mais à tous ceux qui sans connaissance fine de l’agilité veulent en avoir une image d’ensemble.
Cela manquait ces derniers temps car l’agilité ne cesse de s’agrandir. Un des points qui fait débat, en plus des dates, c’est le fait d’avoir mis tout cela au nom du mouvement agile, même agile/lean.
Personnellement, je parle d’écosystème agile, car s’il y a des mouvements agiles, tout ne vient pas de l’agilité.
De manière intelligente, Olivier rebondit et propose sa propre vision des mouvements agiles :
Google+
Mouvements agiles
Et vous, quelle est la votre ?
J’espère que cette proposition de Pablo et d’Olivier vont vous permettre d’avoir une meilleure vision d’ensemble floue de l’écosystème agile et plus.
Et en parlant d’écosystème agile, quels sont les points communs entre une entreprise libérée, une startup et une entreprise agile ? C’est LifeIsASeriousGame qui nous en parle avec les exemples de Favi, Google et Spotify.
L’agilité vu par Gartner
Un rapport du Gartner sur l’agilité, que l’on trouve résumé ici.
Agile is not one thing
Agile is not a « pick’n mix » methodology
Embracing agile is a joint business-IT activity
With agile, it is important to walk before you try running
Embracing agile is embracing continuous learning
Agile is about teams and teams of teams
Documenting, managing and eliminating technical debt is a core concept of all agile methods
Working with third-party development service providers on agile development demands special care and attention
The impact of agile goes well beyond the software development teams
Other software development methodologies will still have a place in your portfolio
La traduction de la semaine de Fabrice
Les 10 choses que les RH ne veulent pas entendre sur l’agile, voir la belle infographie sur le wiki d’Ayeba.
Est-ce que cela marche pour vous ? A votre avis, est-ce caricatural ?
Le coin des twittos Agiles
"Can we become Agile w/o changing our systems, portfolio, structure, and relationship between IT & Biz?"
Hmmmm…
— John Miller (@agileschools) August 19, 2015
Agile Digest – Scrum
Le meilleur de Scrum
Twitter
LinkedIn
Google+
Facebook
Lego Scrum board
Dans la série des tableaux innovants, en voilà 5 autres, plus orientés Scrum, et certains avec des légos !
Le coin des twittos Scrum
#Scrum is easy to learn, but difficult to master. #Empirical processes promote sustainable development #Agile #Chopin pic.twitter.com/L1vwUpbp0m
— Quantum of Value (@quantumofvalue) August 20, 2015
Agile Digest – Kanban
Le meilleur du Kanban
Twitter
LinkedIn
Google+
Facebook
Un tableau kanban électronique type
« Arrêter de commencer, commencer par finir »
C’est un des mantras de la méthode Kanban. Dans l’article Kanban et l’intention de Rythme Soutenable d’InfoQFr, Mike Burrows explique pourquoi Kanban propose un rythme soutenable et pérenne pour l’évolution du système, orienté service, avec quelques points clés à retenir :
Kanban organise le travail pas les gens, ce qui encourage l’auto organisation.
Kanban cherche un meilleur équilibre entre les différentes priorités de tâches, à court/moyen/long terme.
La collaboration comme focale de l’amélioration continue
Merci à Dimitri & Stéphane Wojewoda pour la traduction
Le coin des twittos Kanban
@klausleopold local optima. wrong metrics. wrong reward system. lack of customer focus
— David J Anderson (@djaa_dja) August 17, 2015
#protip: many questions such as "how to do X in #kanban?" can be traced to: what are you trying to use a Kanban system for?
— Alexei Zheglov (@az1) August 17, 2015
Agile Digest – Lean Startup
Le meilleur du Lean Startup
Autopsy.io ou les leçons apprises par des startups qui ont échouées. En voici un très petit extrait :
stuck with the wrong strategy for too long does not represent the vision I had when starting the company not enough time spent on vision in the early days, too early marketing spending, too many early hires, and a lot more..
That’s all Folks !
Agile Digest 34
A lire aussi
Google+
Agile Digest 33
Google+
Agile Digest #32
Google+
Les 10 bonnes résolutions pour être plus agile en 2013 ~ Part II
Google+
Les 10 bonnes résolutions pour être plus agile en 2013 ~ Part I
Cet article Agile Digest 34 est apparu en premier sur L'accompagnement agile.
August 17, 2015
5 pratiques pour manager agile
Des pratiques pour manager agile
Un manager agile est un manager qui évolue dans un écosystème agile. Il n’est pas toujours simple de trouver sa place lorsqu’on a été manager dans un environnement traditionnel; ni de trouver la bonne posture managériale, plus délégative.
La communauté de pratique est un bon moyen pour un manager agile, de (re)trouver sa place et sa légitimité. Ce n’est évidemment pas la seule. Elle fait partie de la panoplie de pratiques pour manager agile.
C’est également une piste importante pour la scalabilité de l’agilité dans l’organisation, mais c’est un autre sujet.
Les communautés de pratique
Les communautés de pratique existent depuis quelques dizaines d’années, au moins 1990 a priori. Elles permettent le partage de connaissances, d’un savoir-faire et de progresser ensemble sur un domaine, au sein d’une organisation. Nous allons nous concentrer sur les communautés de pratique internes aux entreprises.
Etienne Wenger soutient que ces communautés de pratique sont « la connaissance la plus dynamique et la plus versatile de l’entreprise, une ressource qui constitue le socle de sa capacité à savoir et à apprendre »
Car elle touche, entre autre, à la connaissance tacite du métier difficile à capter. D’ailleurs, certains situent cette pratique dans le cadre du Knowledge management.
Dans l’écosystème agile, ces communautés sont arrivées à deux niveaux principalement :
Les communautés de pratiques agiles, souvent constituées autour des rôles Scrum : Product Owner, Scrum Master, coach agile, manager agile.
Les communautés de pratiques techniques ou métiers. Les équipes agiles sont orientées produit ou fonctionnalités métier (équipe feature comme le traduit Fabrice). Elles sont pluridisciplinaires, avec des testeurs, des développeurs de toutes technos, des analystes métier. Contrairement à l’organisation traditionnelle organisée par profil (technique, métier, marketing, …). Les communautés transverses ont pour but de garder une connaissance transverse aux produits ou fonctionnalités, et d’assurer une homogénéité de pratiques (développement, briques techniques, ergonomie, …).
J’ai pu observer que ces communautés sont importantes pour le statut social des experts qui, avec l’arrivée de l’agilité, ne vivent pas toujours bien de se retrouver au même niveau que tous les équipiers (i.e. sans rôle hiérarchique) d’un projet Scrum. Ils retrouvent, avec les communautés de pratiques techniques, un espace où leur expertise est valorisée et valorisable.
Spotify a fait beaucoup d’avancées sur ce sujet et propose un modèle d’organisation avec des communautés de pratique, ses chapters et ses guildes.
Google+
Modèle spotify
Ces communautés créent globalement du lien entre les équipes.
Organisation des communautés de pratique
Ces communautés sont généralement auto-organisées. Elles sont « l’émergence d’un management coopératif ». Et cela bouscule les managers.
Avec le modèle d’organisation proposé par l’agilité, et particulièrement par Scrum, c’est le deuxième effet KissCool : les managers ont déjà vu l’arrivée d’équipes auto organisées et d’un Scrum Master, ce qui les a sorti une première fois de l’arène opérationnelle. Rebelote avec les communautés transverses au niveau de l’organisation !
Le manager agile & les communautés de pratique agiles
Plutôt qu’une nouvelle menace pour son poste, c’est une opportunité à saisir pour le manager. Jean-Claude en parle très bien dans son blog. Il propose que le manager Agile soit l’initiateur voire l’animateur de ces communautés. Plutôt que de se voir exclu du jeu, il en devient l’acteur bienveillant, le pilote. C’est pourquoi ce sont des pratiques pour le manager agile.
A minima, il doit en être le sponsor, pour qu’elles trouvent la légitimité du temps qu’on leur accorde.
Leur existence et leur animation sont donc de véritables enjeux, c’est pourquoi il vous faut des pratiques pour vos communautés de pratique !
5 pratiques pour vos communautés de pratique
J’ai eu l’opportunité d’accompagner, ces dernières années, plusieurs communautés de pratique agiles pour différents clients. Voici quelques retours d’expérience, qui ont bien marché, sur la manière de les animer dans un esprit collectif et collaboratif.
#1 Créer la vision d’une communauté
Avec une communauté de managers lors d’une transition agile, j’ai utilisé l’atelier du speed boat enrichi. Voilà comment cela se déroule :
On commence par dessiner une île paradisiaque, le terme du voyage (i.e. la transition agile). L’objectif de l’atelier est que tout le monde s’aligne sur leur futur rôle de manager Agile. Chacun y met d’abord sa propre vision, en écrivant ses propres sticky notes, puis une vision collective se forge sur le rôle en regroupant, reformulant, mettant de côté chaque point.
Ensuite, on utilise le speed boat pour visualiser les freins et les moteurs permettant d’atteindre plus rapidement cette île. Cela permet d’identifier les chantiers sur lesquels la communauté de pratiques doit travailler. On initialise le backlog de la communauté.
On peut enrichir l’atelier en visualisant les écueils ou les risques par des rochers effleurant l’eau, ou des orages zébrés d’éclairs.
Il y a d’autres manières de faire, on peut citer le Pocket-Sized Agile Principles ou le product box.
Google+
#3 Prioriser les sujets
Une fois les sujets identifiés, j’aime bien utiliser un autre atelier des innovations games: Prune the product Tree.
Les participants mettent les sujets sur un arbre et les répartissent par thème. Ces thèmes sont émergents, ils deviennent les branches de l’arbre, les sujets en sont les feuilles.
Ensuite, on déplace les sujets par priorité : les priorités hautes proches du tronc de l’arbre, et basses vers l’extérieur. On schématise les futures tailles de l’arbre pour les saisons à venir. Cela permet visuellement de répartir les sujets dans les différentes saisons, par priorité.
On peut maintenant se concentrer sur la prochaine saison pour identifier les feuilles des branches. On découpe les sujets en des tâches plus actionnables, (bon ok des actions SMART).
Ici, la métaphore de l’arbre marche à deux niveaux : pour les saisons et le fait qu’une communauté de pratique évolue de manière organique, c’est un bon rappel.
Google+
#5 Prendre des décisions collectives
Oui, mais pas forcément unanimes. Le Dot Vot est là pour vous aider à faire émerger rapidement la bonne décision collective, les 2 ou 3 actions à réaliser…
C’est un classique de n’importe quelle rétrospective Scrum. Cet atelier est bien utile dans ces communautés de pratique où il n’y a pas de chef. Il y a par contre un leader, mais qui n’impose pas les décisions.
Google+
#2 Définir le rythme des rencontres
Bien qu’informelles, je vois un intérêt à donner un rythme aux réunions de ces communautés de pratiques, plutôt court, toutes les 2 semaines par exemple. Mais plus important, un rythme pour les objectifs à moyens termes.
Et pour cela, j’ai repris l’idée de Laurent Sarrazin, la notion de saisons, comme les séries télévisées, calées sur le rythme des vacances scolaires, avec une planification à la rentrée et un bilan, voire une démo avant les vacances.
Tout cela est raconté dans Rupture douce saison 1.
Google+
#4 Rétrospectives sur les pratiques
On a vu jusque-là des ateliers plutôt destinés au démarrage de la communauté ou au démarrage de chaque nouvelle saison. Ca permet de remplir le backlog des sujets de la communauté et de le prioriser.
En fin de saison, j’aime bien faire une rétrospective des pratiques, comme à la fin d’un Sprint :
Rétrospective du backlog grooming (pardon Claude, l’affinage de son backlog) avec les Product Owners, rétrospective des rétrospectives avec les Scrum Masters (ça rend fou tout ça…).
C’est une communauté de pratique, on est là pour s’améliorer sur nos pratiques justement…
J’utilise tout particulièrement l’atelier learning matrix pour rappeler que c’est un moment de partage et d’apprentissage.
Dans cet atelier, on demande aux participants d’écrire ce qui a bien marché pour eux (on partage les bonnes pratiques), ce qui n’a pas bien marché (c’est cool on va pouvoir en débattre ensemble !), ce qu’ils ont appris (on ancre l’apprentissage) et les questions qu’on se pose encore (re cool on va pouvoir aussi en discuter).
Avec un client, on a passé comme cela une journée complète avec les Product Owners et une journée complète avec les Scrum Masters pour repasser chaque pratique, en changeant l’atelier de rétrospective à chaque nouvelle pratique.
Google+
Ces pratiques ne sont pas nouvelles en tant que telles. Elles sont d’ailleurs largement utilisées dans les équipes agiles, particulièrement lors des rétrospectives. Je trouve particulièrement intéressant de donner un écho à ces pratiques dans le contexte un peu différent des communautés de pratique; surtout qu’elles sont cette fois animées par le manager plutôt que le scrum master.
Apprentissages
Niveaux d’engagement différents
Une communauté de pratique marche sur la confiance avec des niveaux d’engagement différents, comme le rappel Fabrice Aimetti. Il faut l’accepter et rappeler la Directive Première de l’univers de fiction de Star Trek !
Être berger plutôt bâtisseur
Vous êtes manager et vous allez animer une communauté de pratique avec vos collaborateurs ?
Prenez l’attitude d’un servant leader, un chien de berger dirait même Dimitri, l’âme d’un facilitateur.
Communication à l’extérieur de la communauté
Il faut communiquer à l’extérieur de la communauté pour conserver sa crédibilité. Avoir une perspective extérieure pour rester aligner avec l’organisation, recevoir du sponsor ship, permettre la porosité des idées, et le brassage des participants. Bref, il faut communiquer.
Et vous, quelles sont vos pratiques pour manager agile ? Pour animer vos communautés de pratiques ?
A lire aussi
Google+
Les 10 bonnes résolutions pour être plus agile en 2013 ~ Part I
Google+
Vos formations agile/Kanban 2012
Google+
C’est quoi ton anti problème ?
Google+
L’agilité, même pas mal ~ épisode #1
Cet article 5 pratiques pour manager agile est apparu en premier sur L'accompagnement agile.
August 13, 2015
Agile Digest 33
Agile - Kanban - Scrum - Lean Startup
Découvrez l'actualité agile qu'il ne fallait pas louper cette semaine !
Agile Digest 33
feature frequency curve
La nouvelle traduction par fabrice Aimetti est à lire ici en français sur l’inflation de fonctionnalités de Joel Spolsky.
« L’innovation ne consiste pas à dire oui à tout. Cela consiste à dire NON à tout sauf aux fonctionnalités les plus cruciales. » – Steve Jobs
Multibao, une boîte à outils de pratiques collaboratives
Une boite à outils pour pratiques collaboratives nous est proposée par Multibao et c’est LifeIsASeriousGame qui en parle.
Le coin des twittos Agiles
Agile : Culture qui nous enseigne à évoluer dans un monde complexe #agile
— Steeve Evers (@steeveevers) August 7, 2015
Agile Digest – Scrum
Le meilleur de Scrum
rocket planning
Loic Leofold nous propose d’agrémenter chaque meeting Scrum d’un jeu collaboratif.
Il fallait oser le mélange :o)
Le PBT-SLIM Canvas est une combinaison du Value Proposition Canvas, du Speedboat et du PEETIC. Il permet d’avoir sur un même outil visuel l’étude des causes de l’avancement du projet et le tableau d’actions.
Le coin des twittos Scrum
@agilecoach I apparently convinced Jeff Sutherland the Retrospective is the first and most important meeting of #scrum at #agile2015 Score!
— Dan Greening (@greening) August 6, 2015
Le truc marrant c’est que quand j’ai passé mon CSM avec Jeff Sutherland, la partie rétrospective était presque inexistante. Il faut dire avec une session de 25 participants c’est dur. Il a évolué donc…
Et si la rétrospective est la réunion la plus importante de Scrum, la pratique agile apportant le plus de valeur est la conception évolutive selon Joshua Kerievsky, propulsé par Oana.
Développement itératif incrémental
Cette pratique permet de lever les risques d’intégration et de mauvaise collaboration au plus vite (à commencer dès la fin du premier sprint) là ou cela peut prendre des mois avec une approche traditionnelle de gestion de projet.
Livre
Bientôt dans les bacs, la 4ème édition du livre Scrum de Claude Aubry.
Agile Digest – Kanban
Le meilleur du Kanban
Un slideshare tout en visuel de Kanban pour revoir les bases, et différents kanban boards, avec une explication simple et visuelle.
Kanban boards step by step from Giulio Roggero
Et juste parce que c’est joli, des notes sur le livre Personal Kanban par @toddaclarke
Personal Kanban
Le coin des twittos Kanban
Et parce que c’est rigolo
It's like suggesting drowning kittens or something… #Kanban #WIP pic.twitter.com/oCNuGP7PRM
— I Can Haz Agile? (@agile_memes) January 30, 2015
Et un rappel pour tous ceux qui commencent une démarche Kanban :
Your first #kanban board will be wrong, but it will still be a good start
— Andrew Rusling (@andrewrusling) August 12, 2015
Agile Digest – Lean Startup
Le meilleur du Lean Startup
An MVP is an experiment that teaches you something you didn't know, not a Version 1 where you know the outcome going in. #LeanStartup #agile
— Melissa Perri (@lissijean) June 22, 2015
That’s all Folks !
A lire aussi
C’est quoi ton anti problème ?
Agile Digest #32
Les 10 bonnes résolutions pour être plus agile en 2013 ~ Part II
Les 10 bonnes résolutions pour être plus agile en 2013 ~ Part ICet article Agile Digest 33 est apparu en premier sur L'accompagnement agile.
August 10, 2015
Kanban pour startup
Pour ne rien rater sur le Kanban et les startups
Prénom
Nom
Adresse e-mail
Kanban pour startup
Le travail d’un entrepreneur en phase de création est multiple. Une partie de son activité peut être décrite par des processus : découverte client, validation client, création client, découverte startup si l’on prend les étapes du Customer Development, à titre d’exemple.
Google+
Étapes du customer development de Steve Blank
Il est donc possible d’optimiser ces processus. Un des cadres que l’on peut utiliser pour cela est le Kanban pour l’IT et l’adapter.
Les pratiques Kanban
Regardons de plus près les deux premières pratiques du Kanbanqui peuvent nous intéresser :
#1 Pratique Kanban pour l’IT – Visualiser le travail
Une startup a différentes étapes de croissance. A chaque étape, le travail des fondateurs et collaborateurs changent, le focus également. Le Kanban représente la meilleure manière connue de faire le travail à un instant donné. Le Kanban va donc évoluer également.
Il n’y a donc pas un seul Kanban pour startup mais une famille de Kanban pour startup.
#2 Pratique Kanban pour l’IT – Limiter le travail en cours
La deuxième des pratiques, la plus connue, est celle consistant à limiter le travail en cours : celui sur lequel on travaille, mais également aussi les tâches commencées mais non finies, qui attendent une validation par exemple, ou un complément d’informations, ….
Cette limite se fait généralement par le nombre de tâches. Lorsque celles-ci sont de tailles trop différentes, on peut passer à un modèle basé sur la taille des tâches comme les points de Scrum et la vélocité. Mais généralement, le nombre suffit.
Passons maintenant aux différentes étapes pour voir identifier les Kanban pour startup.
Phase d’exploration du Business Model
Dans cette phase-là, très exploratoire, on émet des hypothèses sur notre business model, à base de segments clients, de problèmes à adresser, de proposition de valeur.
Les outils utilisés dans cette phase sont le business model canvas ou le Lean canvas. Pour alimenter ces canvas, on utilise le Value Proposition Design pour faire un zoom sur deux des neufs cases : customer segments et unique value proposition.
Google+
lean canvas
Google+
Business Model Canvas
On visualise bien les informations. La différence entre un business plan et business model, c’est que le second est dynamique. Les informations des canvas sont des actions à prendre ou le résultat de celles-ci : hypothèses sur les canaux de communication, segment client validé, …
Ces canvas se rapprochent du Kanban : du travail, dans des états différents.
Et pour aider l’entrepreneur à se focaliser sur le plus important, Ash Maurya, dans son outil en ligne, limite d’ailleurs le nombre d’éléments par case à 3.
On peut utiliser ces canvas dans une approche Kanban pour fluidifier et focaliser son travail.
En dehors de cette partie, acceptons-le, ça a tendance à partir un peu dans tous les sens au démarrage. On est dans l’innovation, la création, pas de process très établi a priori.
Nous avons à notre disposition tout un panel d’ateliers spécifiques pour innover,créer, partager : Game storming. L’important est de s’y retrouver et de se focaliser.
Dans cette phase sans réel processus, une approche très simple, type Scrum, semble la plus adaptée.
Google+
au pays de scrum
Phase d’évaluation du problème et de test de la solution
Phase plus expérimentale, il s’agit maintenant d’identifier les hypothèses et risques du business model. Puis de lancer au plus vite une expérimentation en les confrontant au marché, aux futurs clients et utilisateurs.
Les outils utilisés sont principalement :
Google+
javelin board
Javelin board
Google+
validationboard
Validation board
Google+
Lean dashboard
Lean dashboard
On est clairement dans un processus de validation, répétable. Une seule expérimentation, un seul paramètre à tester à la fois : les limites sont explicites. C’est le temps des interviews, des MVP à faible fidélité.
C’est clairement du Kanban. La limite de 1 est très dure et très frustrante dans cette phase car c’est le début, on a plein d’idées à tester. Le risque pour un entrepreneur est de s’éparpiller. Un des facteurs de succès est de se focaliser. La limite de 1 est là pour cela.
Elle est là également pour apprendre : si l’expérimentation marche ou échoue et que je teste trop d’hypothèses à la fois, ou trop de changements à la fois, qu’est-ce que j’apprends, quelles sont les conclusions ? Difficile.
Dans la phase d’évaluation, un Kanban orienté validation très agressif avec des limites de 1 !
Phase d’acquisition/fidélisation/développement de la clientèle
Toujours dans l’étape de découverte client, il faut élaborer différentes stratégies pour acquérir la clientèle, la fidéliser et la développer. Et bien sur tester ces stratégies. Les tableaux de validation, vus précédemment, continuent d’être utiles dans cette phase.
Le retour de ces stratégies n’est pas toujours immédiat. Nous sommes dans des boucles de validation de quelques heures à quelques semaines. C’est plus long qu’une séance d’interviews dans la rue. Les expérimentations vont commencer à se superposer. La limite n’est plus de un à ce stade.
Il peut donc être intéressant de basculer sur un tableau Kanban plus adapté à des cycles un peu plus long, à l’exemple de celui d’Ash Maurya :
Google+
Kanban pour startup
On y trouve des colonnes de validation qualitative, quantitative, une seconde ligne qui est une file d’attente, des limites sur les colonnes. Toutes les premières pratiques du Kanban pour l’IT.
J’ai expérimenté cela lorsque j’étais mentor au booster de la cantine numérique, avec une suite logique du lean canvas : les hypothèses à valider, puis du validation board : les expérimentations en cours, puis du kanban board pour suivre les tâches qui permettent d’expérimenter les hypothèses à valider :
Google+
La logique des boards utilisés au booster
Google+
Kanban pour startup au booster
La conclusion est assez mitigée pour deux raisons :
Les entrepreneurs étaient seuls, donc a priori pas besoin de partager (et pourtant besoin de visualiser)
Le manque de présence de ma part pour le faire vivre au démarrage.
On peut également envisager à ce stade des kanbans plus spécifiques : process de publication d’un post sur le blog de la startup, process liés aux métriques de conversion…
Et vous, quels sont les outils que vous utilisez pour vous organiser ? Quels sont les kanban boards qui marchent pour votre startup ?
Kanban pour startup
Je cherche à rencontrer des startups utilisant des principes et des outils Kanban pour leur organisation.
Contactez-nous pour en discuter
A lire aussi
Google+
Agile Digest #32
Google+
Les 10 bonnes résolutions pour être plus agile en 2013 ~ Part II
Google+
Le Shift Camp
Cet article Kanban pour startup est apparu en premier sur L'accompagnement agile.
August 6, 2015
Agile Digest #32
Agile - Kanban - Scrum - Lean Startup
Le meilleur de l'agilité de la semaine
Agile Digest
Agile Digest, c’est le meilleur de l’agilité, toute l’agilité, trouvé sur le web cette semaine.
Panorama des méthodes agiles
A lire le Panorama des méthodes agiles par @EmilieEsposito avec une infographie qui marche bien.
Cette semaine avait lieu Agile2015, la conférence de l’Agile Alliance, pour ceux qui ne peuvent pas y participer comme moi, il nous reste les tweets :
A really good agile manager needs to be more like a coach. Via @jeffsutherland#Agile2015
Agile needs to be part of the culture not only at the team level, but at the leadership level as well. All in! #Agile2015 Via @ScrumMasterCE
Agile Digest – Scrum
Problem solving tools
Article intéressant sur Scrum, bien qu’il soit classique sur le fond, il est toujours bon de relire les fondatmentaux : scrum without removing impediments isn’t scrum
Scrum is a problem-finding tool, not a problem-solving tool
Et comment un Product Manager doit-il alimenter un backlog Produit ? par Sebastien Sacard à lire ici :
la vision permet de déduire les bénéfices utilisateurs,
les bénéfices permettent de déduire les caractéristiques,
les caractéristiques permettent de déduire les récits utilisateurs
Add a positive 4th question to your daily Scrum meetings: « are there any opportunities we could exploit? » – thanks Mike Griffiths #Agile2015 via @EFranchomme
Agile Digest – Kanban
A voir, le Top 5 des tableaux kanban innovants, il y en a pour tout le monde. Restez innovant et surtout faites le tableau qui marche pour vous.
Tableau Kanban innovant RH
In fact #kanban reveals bottlenecks dynamically and fosters a culture of flow#lean via @Na3mAkrm
Agile Digest – Lean Startup
Only write code when you can’t think of any other way to validate your hypothesis
à lire sur les échos, pour les entrepreneurs qui se demandent avec le Lean Startup, s’il est prudent de parler de leur idée tant que le produit n’est pas finalisé :
A l’ère numérique, la propriété intellectuelle perd de son sens. Comme le montrent plusieurs grands patrons du digital, l’avenir est désormais au partage de l’innovation. Ce n’est plus la protection mais l’amélioration permanente qui permet de maintenir son avance.
Et un classique du Lean Startup :
If You’re Not Embarrassed By Your Startup, You Launched Too Late #mvp#leanstartup via @onemonthedu
Pas sûr que ce soit toujours vrai, mais il est bon de le rappeler :
The mistake of most start-ups is to operate like an established business. Forget business plan, focus on the business model. #leanstartup via @Liza_Hussein
Ça par contre c’est vrai !
Don’t kill your #startup with#growthhacking obsession at early stage.
Initial Traction > Product-Market Fit > Growth Hacking #leanstartup via @IFTTTMarketing
Et forcément, j’aime bien cette image :o)
@ leanstartup #leanstartup is like sailing, & customers are wind Sometimes you need to change tack to fill your sails via @leanplc
Les pratiques agiles et les startups : le point de vue de Jeff patton :
Common Agile Practice Isn’t for Startups
As a team frequently ask yourselves these questions:
Are we working together as a team collaboratively and effectively?
Are we making our ideas visible fast so we can learn fast, whether it’s working software, or a simple paper prototype?
Are we learning directly from our real customers, the people that will buy and use our product?
Are we stopping frequently to take stock of what we’ve learned and to re-think our product idea, our plans, and the way we’re working?Common Agile Practice Isn’t for Startups
That’s all folks !
Cet article Agile Digest #32 est apparu en premier sur L'accompagnement agile !.
July 29, 2015
Innover comme une startup
Google+
Formation Lean startup, 22-24 septembre 2015, Rennes
Innover comme une startup
Oui, mais dans votre contexte ! C’est ce que nous vous proposons avec notre nouvelle formation lean startup.
Pensée pour tous ceux qui veulent découvrir ou porter un démarche Lean startup dans leur organisation, elle sera particulièrement utile pour les Product Owners / Product Manager / Marketing souhaitant avoir une démarche plus innovante pour leur produit, et amener l’agilité au plus prêt du business.
Les coachs agiles et scrummasters seront mieux armés pour embarquer le métier dans leur démarche agile, véritable enjeu d’une transformation agile réussie. L’approche est complémentaire, les principes plus adaptés et surtout un vocabulaire partagé.
Le Lean startup, c’est le mélange du customer development (de steve Blank) et de développement Agile. Les deux méthodes sont des approches empiriques permettant de piloter dans un contexte de forte incertitude. L’incertitude pour les méthodes agiles se situe au niveau de la solution, que l’on va finaliser an cours de projet, en co-construction avec les utilisateurs; celle du Lean startup se situe au niveau du business model même.
Une démarche d’expérimentation va permettre d’avancer dans ce contexte et de lever les hypothèses au fur et à mesure. L’approche agile va venir en support du lean startup pendant la phase de développement client.
Enfin, les managers y trouveront des éléments de réflexions pour décider d’une démarche lean startup en interne et pouvoir diffuser son état d’esprit.
Google+
Lean startup mindset
A vous de jouer !
Au cours de ces 3 jours de formation, constitués de masterclass, d’ateliers et d’études de cas, nous allons parcourir les techniques et outils du
Lean startup
Customer development
Business model generation
Value Proposition Design
Prochaine session
Rennes, 22-24 Septembre
Informations & inscription
Cet article Innover comme une startup est apparu en premier sur L'accompagnement agile !.
Innovez comme une startup
Formation Lean startup, 22-24 spetembre 2015, Rennes
Vous voulez innover comme une startup ?
Oui, mais dans votre contexte ! C’est ce que nous vous proposons avec notre nouvelle formation lean startup.
Pensée pour tous ceux qui veulent découvrir ou porter un démarche Lean startup dans leur organisation, elle sera particulièrement utile pour les Product Owners / Product Manager / Marketing souhaitant avoir une démarche plus innovante pour leur produit, et amener l’agilité au plus prêt du business.
Les coachs agiles et scrummasters seront mieux armés pour embarquer le métier dans leur démarche agile, véritable enjeu d’une transformation agile réussie. L’approche est complémentaire, les principes plus adaptés et surtout un vocabulaire partagé.
Enfin, les managers y trouveront des éléments de réflexions pour décider d’une démarche lean startup en interne et pouvoir diffuser son état d’esprit.
Running Lean
Au cours de ces 3 jours de formation, constitués de masterclass, d’ateliers et d’études de cas, nous allons parcourir les techniques et outils du
Lean startup
Customer development
Business model generation
Value Proposition Design
Plus d’informations sur la prochaine formation lean startup
du 22 au 24 septembre à Rennes
July 28, 2015
Être manager agile
Devenir
Manager Agile
Le rôle de Manager, lors d’une transition Agile/Lean, évolue. D’un rôle typiquement directif, la posture du manager devient plus délégatif pour aller vers du Leadership..
Nous vous accompagnons dans ce changement
July 16, 2015
C’est quoi ton anti problème ?
Récemment, j’ai redécouvert l’atelier « the anti problem » de Game storming, mais pour un contexte un peu différent que celui décrit dans le livre : les rétrospectives agiles.
Au passage, ce livre est une mine d’or pour concevoir vos ateliers collaboratifs.
Un recueil d’ateliers collaboratifs
Un peu de contexte d’abord
C’est un atelier permettant à une équipe travaillant déjà sur un problème, mais étant à court d’idées, de trouver d’autres solutions. Le format consiste globalement à :
Prendre le problème que l’on a à résoudre
Formuler la contraposée du problème
Essayer de résoudre ce nouveau problème
Le reste dépend de vous !
Un exemple pour une rétrospective
Imaginons un projet Scrum où il est difficile de mettre en place des démos, pour diverses (bonnes) raisons : contexte avec peu de clients, répartis dans le monde, plutôt des prospects sur un marché agressif…
Bref pas l’idéal pour faire des démos avec les futurs utilisateurs. Le problème est donc de ne pas pouvoir avoir de feedbacks réguliers d’utilisateurs sur ce que nous produisons.
C’est quoi ton anti problème ?
C’est là que l’anti problème arrive
On pose la question simple. C’est quoi ton anti problème ?
La contraposée de ce problème serait d’avoir des démos qui ont bien lieu, avec beaucoup d’utilisateurs et trop de feedbacks ! Difficile même de tout prendre en compte.
L’équipe imagine en rétrospective des solutions pour ne plus avoir autant de retours lors de ces démos. Et pourquoi pas ne plus en avoir du tout (pour se débarrasser de la démo) ?
Comment faire pour capter ces informations avant la démo, voire, faire bien du premier coup ?
Bien sûr, les solutions vont dépendre du contexte, on évoquera surement du maquettage, du prototypage, de meilleurs critères d’acceptation, mais aussi, on l’espère, des solutions plus innovantes spécifiques à l’équipe Scrum.
Le bilan
Un problème sans solution est un anti problème mal posé.
Citation (personnelle) d’Albert Einstein
Bien qu’il semble un peu compliqué à introduire auprès des équipes, j’aime bien cet atelier car il force à s’extraire de la solution classique qui ne marche pas, à reconsidérer le besoin initial qui nous a conduit à la solution classique, et à repenser d’autres solutions.
Avec une approche « Problème », on serait tenté de mettre en place une démo coûte que coûte, au risque d’avoir une solution artificielle, à base de visio conférence par exemple ou de démo par le Product Owner sans l’équipe, en suivant les contraintes des clients, en décalé des sprints.
Avec une approche « Anti problème », on dépasse la solution (la démo), pour se concentrer sur le pourquoi (converger vers la bonne solution au plus vite) et cela passe par d’autres solutions.
Et toi, c’est quoi ton anti problème ?
Hey, vous avez lu mon dernier post ? C’est sur la prochaine formation Lean startup !
Cet article C’est quoi ton anti problème ? est apparu en premier sur L'accompagnement agile !.
Laurent Morisseau's Blog
- Laurent Morisseau's profile
- 3 followers
