Lean Start-Up, and How It Almost Killed Our Company

The theory of Lean start-up with its focus on product, small bets, customer validation and pivot points, has become almost universally accepted within software development and businesses in general. In this article Helen Walton offers a provocative critique of its suitability to many business contexts, as well as recounting why the method proved almost fatal for one particular start-up – her own.

Source: www.infoq.com

Cet article d'Helen Walton peut susciter pas mal de controverses. C'est un retour d'expérience sur le Lean Startup chez Gamevy une entreprise qui fait des jeux d'argent sur internet. Helen partage les difficultés rencontrées par les fondateurs de Gamevy dans la mise en place d'une approche Lean Startup et dénonce un certain nombre de pièges de l'approche, notamment dans le cas de marchés avec des barrières d'entrée élevée.

 

On pourrait argumenter sur la définition du MVP et c'est peut-être une bonne idée de relire cet article de Steve Blank que nous avions partagé récemment http://steveblank.com/2015/05/06/build-measure-learn-throw-things-against-the-wall-and-see-if-they-work/ il y a sans doute ici quelques pistes qui peuvent expliquer les confusions.

 

Toutefois ceci à part, l'article reste un excellent retour, détaillé, d'une expérience poussée de mise en place du Lean Startup. Les mises en garde ne sont pas dénuées de sens et cela peut sans doute être là des avertissements utiles si vous envisagez ces approches.

Bonne lecture!

The Epidemic of Managing without Soul | Henry Mintzberg

BLOG

Source: www.mintzberg.org

Au premier abord, cet article peut sembler anodin. Et puis on s'aperçoit qu'il est de Henry Mintzberg et il prend toute sa puissance.

Henry Mintzberg nous partage ici quelques histoires, vécues ou racontées sur les conséquences d'un management sans âme. À l'heure du management 3.0, de l'entreprise libérée et pour ainsi dire de la prise de conscience de l'importance du rôle du manager, il est important de se rappeler à quel point nos actes peuvent être destructeurs s'ils sont faits sans âme.

Un joli rappel qu'une entreprise ce n'est pas juste un organigramme que je vous propose donc de parcourir!

Why Physical Task Boards Still Matter –

If your agile teams are not using physical task boards, you don't have all the context. Let's find out why and identify how agile teams can start using them.

Source: www.leadingagile.com

Après l'article contre l'utilisation de tableaux kanban physiques, celui-ci explique leur intérêt.

Vous vous en doutez, du coup je ne puis qu'en être partisan.

 

Ce qui est intéressant avec cet article c'est qu'il va au-delà des arguments que j'ai déjà pu rapporter au sujet du précédent article.

Vous y trouverez des informations de recherche qui expliquent l'intérêt du physique. Vous y verrez aussi quelques détails pratiques pour mieux mixer le tableau électronique avec le tableau physique.

Il n'y a guère que le point à propos des équipes distribuées que l'on peut éventuellement discuter. Pour ma part dans ces cas-là, je propose la duplication du tableau physique en complément de l'électronique. C'est certes plus contraignant, mais le bénéfice en vaut le coût.

 

Je vous souhaite une bonne lecture.

5 reasons to switch from your kanban board

Dovilė Misevičiūtė | Kanban, Lean

Source: www.eylean.com

Je préfère vous le dire tout de suite, je ne suis pas d'accord avec les conclusions de cet article qui présente 5 raisons pour adopter un Kanban électronique.

 

Si je vous le partage, c'est que les arguments avancés font partie de ceux que l'on voit régulièrement. Voici quelques réponses que l'on peut y apporter en faveur d'un tableau physique.

• Espace illimité: En pratique, l'outil électronique n'apporte rien, car si l'espace est illimité, la partie visible à l'écran est plus limitée que celle d'un tableau physique. On ne peut pas bénéficier de l'effet "radiateur d'informations"
• Informations détaillées de la carte changent: S'il est intéressant d'avoir cette information quelque part, ce n'a aucun intérêt sur un kanban. En effet, trop d'informations tuent l'information. La carte doit être visible de loin et permettre la conversation. Nous savons tous que noyés sous les spécifications, nous avons tendance à ne plus lire du tout.
• Métriques automatiques: C'est là un bon argument pour un tableau électronique en complément d'un tableau physique
• Accès illimité aux informations de l'équipe: Un faux problème. On s'en sort très bien avec un tableau physique. Pensez à utiliser des avatars. En les déplaçant avec la carte, vous savez qui a travaillé dessus.
• Update et monitoring facilités: Mauvais argument, déplacer un post-it reste beaucoup plus rapide qu'en changer le statut dans un outil. Par ailleurs, pour ce qui est du monitoring, un coup d'oeil à un tableau physique suffit généralement pour s'apercevoir qu'une tâche n'a pas bougé depuis plusieurs jours ou que les post-its sont en train de virer au rouge!

Voilà, j'espère vous avoir apporter quelques réponses si vous deviez, vous aussi défendre le tableau physique. L'outil électronique reste intéressant, mais en complément seulement.

En attendant, je vous souhaite une bonne lecture.

The Forgotten Agility of User Stories — Medium

As a Ringbearer, I want to throw the One Ring into the fires of Mount Doom so that Middle Earth will not be bound in darkness.

Source: medium.com

J'ai une confidence à vous faire, j'adore cet article de John Hayes.

C'est un article qui n'hésite pas à renverser les barrières de ce qu'on a pu vous apprendre sur la bonne façon d'écrire des User Stories. Un article qui remet de la vie dans l'expression du besoin en cassant le mythe des templates. C'est un retour aux sources.

L'agilité à cherché à remettre l'utilisateur au centre du projet. Pour mieux comprendre ses besoins, on a cherché à les exprimer sous formes d'histoires. Pour simplifier, on a défini un template. Et c'est là que les choses se sont compliquées.

John Hayes nous montre les limites d'une user story qui ne ferait que suivre un template. Il illustre très clairement les manques d'une approche qui cherche à appliquer une méthode sans en comprendre le sens. Bref il nous présente le "Why" des User Stories.

Une excellente lecture pour remettre de la vie dans vos Stories!

Stop Doing Retrospectives

andon cord

Source: curtiscooley.com

Cet article est simple mais je l'aime beaucoup car il est sensé. La rétrospective c'est la première chose que l'on regarde pour évaluer la maturité Agile d'une équipe:

• Fait-elle des rétrospectives?
• Sont-elles efficaces?
• Existe-t-il des sujets tabous?

Il faut bien reconnaître que lorsque les équipes tiennent des rétrospectives elles sont rarement efficaces. Curtis Cooley, nous propose donc de les voir sous un autre angle de vue, en les rendant immédiates et effectives.

Des conseils avisés, qu'il fait bon de rappeler afin de ne plus faire des rétrospectives parce que la méthode le demande mais pour s'améliorer!

Creating a Creative and Innovative Culture at Scale

King Digital Entertainment needs to foster a creative and innovative culture with engaged and motivated people to create fun games. They have established an environment with freedom and trust, with space for experiments, exploration, and learning, to make people happy. Experiments and lessons from the engineering organization showing continuous improvement of HR-related processes and topics.

Source: www.infoq.com

King tout le monde les connaît, ou plutôt, tout le monde connaît Candy Crush Saga leur jeu phénomène sur mobiles! Pour ma part, c'est aussi beaucoup de souvenirs, puisque je les ai rencontrés dans mon ancienne vie!

 

Cette industrie du jeu vidéo est encore trop souvent décriée et pas réellement prise au sérieux. Pour autant, c'est là que j'ai pu y observer les meilleures organisations Agiles.

Le REX présenté ici par Matti Klasson, lève un peu le voile sur les pratiques organisationnelles mises en place chez King. On y retrouve une organisation de type Feature Teams, des pratiques de Management 3.0 ou même d'entreprise libérée.

Non content de nous partager leur expérience, Matti Klasson nous présente concrètement quelques-uns des outils qu'ils utilisent, notamment autour du développement de carrière.

Mais ce qui est aussi très intéressant, c'est le "why" de la démarche de King. L'agilité n'est pas là par hasard, mais au service du développement d'une culture d'innovation et de créativité à grande échelle.

Comme chez Spotify le modèle est donc changeant, s'améliorant, pour mieux répondre à un objectif précis. Il est aussi au service d'une grande réactivité.

 

Un bel exemple que je vous invite donc à découvrir et qui montre que le modèle Feature Teams, ce n'est pas que chez Spotify!

Design Studio Recipe – Jeff Patton & Associates

Design Studio is a quick collaborative approach to considering lots of possible solution ideas for a new product, a feature, or enhancement. In a design studio, everyone sketches and shares ideas. By everyone I really mean everyone: UI designers, developers, testers, product managers, business stakeholders, end users, customer service people, and anyone else interested. Everyone …

Source: jpattonassociates.com

Cet article de Jeff Patton nous présente une méthode pour faire émerger des idées qu'il appelle Design Studio.

Il est vrai que si l'Agilité a toujours mis l'accent sur le travail itératif c'est surtout la partie réalisation qui est vue sous cet angle. Ici, Jeff Patton nous propose d'itérer nos idées (on parle d'ideation).

La méthode est présentée clairement et permet de rapprocher des métiers différents autour d'une vision commune (et ainsi créer l'adhésion). C'est aussi un bon moyen pour faire de l'innovation.

Certainement un bon complément à vos Story Maps, lorsque vous êtes en phase de lancement!

A vous de jouer!

Why Managers Ask for Estimates and What They Need to Know

In many of my transitioning to agile clients, the manag…

Source: www.jrothman.com

En dépit des apparences, cet article de Johanna Rothman, n'est pas un article sur le mouvement #NoEstimates, mais une analyse des réels besoins du manager lorsqu'il demande des estimations.

En nous penchant sur les raisons sous-jacentes à cette demande (être capable de prédire les revenus à venir), nous pouvons alors envisager de nouvelles pistes pour une discussion plus riche des estimations.

Ainsi plutôt que de parler de "Time to release", Johanna propose de parler de "Time to release value" et donc de mettre l'accent sur la capacité à livrer fréquemment.

Plus la fréquence des livraisons augmente, plus la raison d'être d'une estimation classique diminue. C'est peut-être là une des pistes vers une forme d'estimation plus saine!

Bonne lecture

How to Be a Great Product Leader – SpecTechUlar

Enter Now and Find Out How to Be a Great Product Leader on the Number One Resource for Product Management Information, News, and Information.

Source: spectechular.walkme.com

Lorsque nous intervenons dans la mise en place de l'Agilité auprès de nos clients, on nous demande souvent quelles sont les qualités d'un bon Product Owner.

Dans cet article Mark Silver, décrit celles d'un Product Leader, et s'il ne parle pas directement d'Agilité, nous sommes en fait très proches du rôle de Product Owner. A l'exception peut être des qualités en management des ressources humaines (mises en avant ici et peut-être moins essentielles au rôle de PO), vous avez là un beau panorama des qualités recherchées.

Si à la description de celles-ci (et à l'explication de leur raison d'être) vous vous effrayez de cet assemblage de compétences qui tient lieu de mouton à cinq pattes, rappelez-vous toutefois qu'une approche Agile, à travers ces boucles de feedback courtes, facilite une recherche de la solution qui ne serait pas parfaite du premier coup.

Au delà des qualités mises en avant ici, le bon PO saura donc prendre le risque d'échouer pour mieux comprendre et mieux servir le produit. Car, comme le disent les anglais, FAIL ce n'est jamais qu'un First Attempt In Learning!

Bonne lecture!

Key to happiness at work is unrelated to job – The Times of India

As we spend more time at the office, we search even harder for better ways to achieve the mythical ‘work-life balance’.

Source: timesofindia.indiatimes.com

Pour continuer dans la thématique du bonheur au travail (voir aussi "What makes us feel good about our work"), ce court article du Times of India, apporte quelques données finalement pas si étonnantes que ça, sur l'influence du social dans notre satisfaction au travail.

Des statistiques qui viennent convaincre ceux qui pouvaient encore être réticents de l'importance du cadre social et de son développement, non seulement pour le bonheur au travail, mais aussi pour la performance de l'entreprise!

Je vous invite donc fortement à y jeter un oeil!

Let’s Acknowledge SAFe For What It Is… And Move On –

It seems this week more SAFe related stuff than usual made it across my desk… some positive, some negative… some old, some new… but all asking the same fundamental questions. Is SAFe the savior of all things software development? Is SAFe really agile or merely the second coming of RUP? Will SAFe survive or be …

Source: www.leadingagile.com

Certains diront que SAFe "ce n'est pas vraiment de l'agilité" et que c'est le mal.

D'autres seront plus mitigés (ou pragmatiques), comme Mike Cottmeyer qui dans son article émet l'idée que dans le cas de certaines entreprises, qui ne peuvent pas facilement créer un environnement propice a l'agilité telle que décrite dans le manifeste Agile, alors SAFe c'est peut être toujours mieux que leur méthode de travail actuelle.

SAFe ne réduit pas forcement la complexité mais va quand même permettre de se focaliser sur la valeur, et sur le long chemin qui mêne a l'agilité, SAFe est peut être finalement un bon point de départ pour certains.

What makes us feel good about our work?

What motivates us to work? Contrary to conventional wisdom, it isn't just money. But it's not exactly joy either. It seems that most of us thrive by making constant progress and feeling a sense of purpose. Behavioral economist Dan Ariely presents two eye-opening experiments that reveal our unexpected and nuanced attitudes toward meaning in our work. (Filmed at TEDxRiodelaPlata.)

Source: www.ted.com

Ok, ok, cette vidéo à deux défauts: elle est en anglais (non sous-titrée) et elle est ancienne.

Pour ce qui est de l'anglais, je ne peux malheureusement rien faire, mais pour ce qui est de l'ancienneté je pense qu'elle est, en fait, très actuelle au vu du reportage récent sur Arte "Le bonheur au travail".

 

Cette notion de bonheur et de motivation au travail n'est pas neuve (un des principes du Manifeste Agile en 2001, disait d'ailleurs de réaliser les projets avec des personnes motivées), mais ce n'est que récemment que cette idée de satisfaction a pris son essor.

Le reportage d'Arte sur les entreprises libérées met cette notion de bonheur au travail sur le devant de la scène. Il ne s'agit plus seulement de réflexions de quelques agitateurs seulement connus des initiés.

 

Dans ce TED, Dan Ariely, nous fait réfléchir sur certains des éléments qui composent notre motivation. De manière intéressante et illustrée d'exemples d'expériences menées en recherche, il nous montre que l'argent n'est pas une vraie motivation (on s'en doutait un peu), mais aussi qu'aimer son travail n'est pas non plus suffisant (ce qui est déjà moins évident) ou encore qu’une certaine forme de difficulté peut-être la bienvenue...

 

Bref, je vous recommande vivement ce TED qui est une excellente source d'inspiration pour mieux comprendre la motivation et rendre le travail plus intéressant !

The Case for Scrum Dying in a Fire

This is RonJeffries.com, the combination of new articles, XProgramming, SameElephant, and perhaps even some new items never before contemplated.
Copyright © 1998-2015 Ronald E Jeffries

Source: ronjeffries.com

Pour ceux d'entre vous qui suivent l'actualité Agile sur Twitter vous avez peut-être entraperçu tout un débat entre Ron Jeffries, et Gilles Bowkett au sujet de Scrum.

Gilles a manifestement rencontré un de ces monstres de Scrum-But que l'on préférerait éviter, une pure forme d'Agile Washing (qui ne lave pas plus blanc que blanc!). De son point de vue Scrum n'est bon qu'à périr dans les flammes...

En réponse aux articles de Gilles, Ron a publié une série de billets sur son blog. S'ils sont tous intéressants, je n'en retiens que le dernier qui s'attache réellement au problème de Scrum-But auquel on a tous certainement pu assister.

Dans ce billet Ron, prend un peu de hauteur et revient sur ce qu'est Scrum et sur les raisons qui peuvent expliquer que nous puissions si facilement en voir l'idée dévoyée.

Si vous avez pu vous aussi, vous posez des questions sur des implémentations de Scrum plus que hasardeuses et vous demandez comment cela peut bien fonctionner, c'est une lecture que je ne peux que vous conseiller!

The Eight Most Common Big Data Myths

The hype surrounding “Big Data” does businesses a disservice by making it all look much too easy.

Source: knowledge.insead.edu

L'agilité c'est avant tout une vision de l'organisation qui remet le client au centre.

Comprendre le client, ses besoins, ses désirs est loin d'être facile et lorsqu'il n'est pas accessible directement, ses représentants (aka: les Product Owners) ont bien du mal à adopter la bonne vision. Avec l'avènement du Big Data, on a cru voir une solution miracle à ces problèmes. Enfin, nous allions comprendre nos clients, prédire leurs moindres rêves.

À travers cet article (en anglais),  Joerg Niessing (@JoergNiessing), INSEAD Affiliate Professor of Marketing, et James Walker, Partner Demand Analytics, Strategy& démystifient les Big Data en s'attachant à nous en révéler 8 croyances fausses.

Une lecture à ne pas rater pour qui vaut mieux comprendre cette hydre à 8 têtes !

Fifty Quick Ideas To Improve Your User Stories – Version Mind Map

Quick Reference Mind Map from Fifty Quick Ideas To Improve Your User Stories by Gojko Adzic and David Evans

Source: atlas.mindmup.com

Certains d'entre vous connaissent déjà le récent bouquin de Gojko Adzic et David Evans composé en mode Lean. Vous aimerez d'autant plus la présentation des Fifty Quick Ideas To Improve Your User Stories en mode Mind Map.

Comme toujours dans ce mode, les idées principales deviennent immédiatement et visuellement accessibles. Un très bon Quick Reference Guide graphique pour avoir rapidement les éléments en tête et les naviguer aisément.

Merci à Peter Önneby pour ce pointeur !

La transformation digitale en baromètre

Source: www.cbnews.fr

A l'heure des transformations digitales, voici un article très complet qui en explique les tendances et les impacts.

L'agilité est au coeur du débat. En effet, l'auteur explique que l'apparition des nouveaux modèles économiques en rupture  orientés services demande d'être agile : flexibilité, immédiateté, vélocité, innovation, évolutivité.

Les impacts sont à la fois organisationnels, économiques, technologiques, managériaux et culturels.

Quand transformation digitale rime avec transformation agile à l'échelle...

Thoughts on Estimation

The nature of software development touches on estimation along its flow. Let's drill into that.

Source: www.mountaingoatsoftware.com

Une fois que vous aurez lu l'article de Matthew Heusser, vous voudrez sans doute poursuivre par celui-ci (plus récent).

Mike Cohn nous partage en effet sur son blog quelques réflexions de Ron Jeffries sur la valeur des estimations.

Ron Jeffries, faisant écho à son dernier livre "The Nature of Software Development", partage ici sa vision sur les estimations.

Il nous parle de son expérience et des questions que vous vous êtes certainement vous-même posées au sujet des estimations.

Ron Jeffries ouvre d'ailleurs le débat en vous proposant de lui partager vos idées pour qu'il enrichisse la discussion.

C'est peut-être l'occasion de lever vos derniers doutes!