An undercover agilist in a Startup Weekend

Logo Startup Weekend LyonRecently (13-15 April 2012) my colleague Yann and I participated in our first Startup Weekend in Lyon (France). We had multiple objectives when going there, including having fun, preparing for organizing a similar Startup Weekend in Luxembourg later this year, pitching some of our startup ideas and evaluating the spread of Agile concepts and practices amongst the community of entrepreneurs. In this post I would like to share some insights about the later aspect.

As agile practitioners we already know that Scrum in particular is very well suited for new product development and we have actually seen the benefits of Agile for such projects in both new companies and mature organizations. But Yann had the occasion a few weeks ago to discuss with a startup team that was using Scrum with only partial knowledge and understanding of the rationales behind it, hence limited benefits. So I wanted to see on the field to what extent Agile methods are understood and used by innovative teams and entrepreneurs. A Startup Weekend would be an ideal Lab for such an observation.

I had a first try on Friday evening by pitching my idea of a starter kit for new agile teams (more about this soon). I quickly realized that this was far from most participants’ knowledge area and concerns. My pitch was not a winner and I was wondering if anyone in the room had ever heard of Agile.

When I eventually joined a team, I did not want to be too pushy for Agile, but rather to see how the team would become more familiar with agile along the weekend. Actually, when discussing with other participants it appeared that some of them are already practicing some sort of Agile process, but only a few of them know what Agile and Scrum actually are.

One of the key aspects of Startup Weekends is the participation of tech and startup leaders as coaches (the “mentors”). Some of those “mentors” were the first to bring Agile explicitly on the table, as a proper framework for managing the kind of innovative product/service development projects that we were at during that weekend.

What stroke me in the team I joined was the high number of hypotheses that were taken without a structured approach to test and validate those assumptions. I believe that several mentors participated in initiating a feedback loop with the team so that we could learn and pivot from the original ideas in order to create a more appealing value proposition and business model (Yann’s team actually pivoted multiple times and quite often all along the weekend ;-) . I did not hear anyone refer to the Lean Startup movement boosted by Eric Ries’ book, but a lot of discussions were really in line with it.

At the end of the weekend, the 15 teams that were formed to work on selected ideas (selected out of 42 initial ideas pitched on Friday evening) presented their projects to a jury composed of entrepreneurs and other personalities. While the evaluation criteria were intentionally kept “secret” it appeared clearly that the jury expected to be thrilled by a great vision backed by a few hard facts & figures, rather than a full 3-years business plan. I felt a strong agile mindset in this moment when it was clearly recognised that faced with so much uncertainty, it was vital to create a learning organization that aims at a great goal, to inspect and adapt continuously along the way, instead of building a full-fledged plan based on pure guesses.

My last comment is that all 3 winning teams were not only able to present an exciting business idea but also to demonstrate tangible results (e.g. a domain name and an embryo of web application), which for me shows once again the importance of demonstrating your actual progress to build trust with your customers / investors, another key Agile concept!

2012: Agility should win by a utilization rate of 80%!

As we enter 2012, it seems appropriate to revisit a Strategic Planning Assumption made by Gartner in 2010.

By 2012, agile development methods will be utilized in
80% of all software development projects

Drafted by Gartner when entering 2010, this document gives arguments like:
Existing groundwork
The tools needed to support an agile transition become and will become more and more mature while the development teams will desire to come out from heavy development process.
Visible benefits
Organizations that have made ​​the shift recognize that the main visible benefits are the improvement of the productivity and flexibility of the teams but also the reduction of the costs of development and maintenance cumulated.

Necessary warnings related to challenges that organizations will have to face are mentioned like:
Cultural changes
The companies will have to take into account some key cultural elements like among others the team-focused and collaboration cultures, the needed of dedicated resources, the speedup of defects detection…
Achievement price
The price to continue benefit from agility will be concentrated in the necessary investment in training and coaching of teams together with the acquisition of tools enabling the transition.

Finally the utilization of agile development methods seems to be considered as a key driver to avoid in long-term the declining of product quality and to allow a better understanding of the project by the business.

To read further get here the document

Agile Mëtteg on DevOps

For this last seminar in 2011 we were about 20 people to discuss DevOps or a fresh new look at the collaboration between development and operations.

Thanks also to our special guests XebiaLabs who did a very interesting demo of their tool DeployIt.

The slides are now published:

1 minute demo of DeployIt
 

Ce que je retiens de Lean & Kanban 2011 Benelux

Il y a un peu plus d’un mois nous avons participé (Yann et moi) à Lean Kanban 2011 Benelux à Anvers. Cette conférence regroupait plusieurs figures du domaine dont Don Reinertsen, Dave Snowden, David Joyce, Alan Shalloway, David Anderson, Karl Scotland et John Seddon.

Avec un peu de recul il me semble qu’une partie des débats a porté sur l’importance respective du processus et des personnes (process vs. people).

Classiquement pour les processus industriels et opérationnels, les travaux de Deming et le “systems thinking” tendent à mettre l’accent sur le système et ses règles de fonctionnement, et on considère que les personnes n’influencent la performance du système qu’à hauteur de 5 à 7% seulement.

Pour les processus de développement (de logiciel et de produit en général), le facteur humain semble plus important compte tenu du degré d’apprentissage nécessaire pour créer et innover. On est dans le cadre d’un système complexe tel que défini par le framework Cynefin. Les processus et les technologies sont au service des personnes pour leur permettre d’atteindre d’excellents résultats.

Dans notre contexte habituel de projet informatique d’entreprise, il faut certainement adopter une perspective globale du système : le processus métier que l’on tente d’améliorer et le développement de la solution logicielle qui doit contribuer à cette amélioration.

Je pense que cette perspective globale est une condition indispensable pour s’assurer que le projet crée réellement de la valeur pour l’entreprise (“build the right thing”). En effet il n’y a pas de gaspillage plus important que de développer de la fonctionnalité inutile ou qui ne contribue pas à l’efficience du processus métier concerné.

Il faut donc considérer d’une part le processus métier et travailler à son optimisation grâce à une approche systémique. Cela devrait permettre d’identifier les points sur lesquels une solution logicielle sera utile et quelles fonctions (ou “user stories”) sont requises pour cela.

D’autre part, le processus de développement lui-même peut également bénéficier d’une approche Lean / Agile. A ce sujet j’ai particulièrement apprécié la session présentée par Karl Scotland (“The science of Kanban”) qui a résumé une série d’arguments en faveur de Kanban sur les plans :

  1. humain (force de la visualisation, inefficacité du multi-tâches, patterns d’apprentissage)
  2. processus (théories des flux et des files d’attente, boucles de contrôle)
  3. économique (coûts actualisés, coûts de retard, coût / valeur de l’information et de la réduction des risques)

On constate également qu’une approche Kanban va avoir tendance à s’étendre en amont pour prendre en compte les problématiques de gestion d’un portefeuille d’initiatives métier (à faire évoluer d’un portefeuille de projets en un portefeuille de “features” plus petites), et en aval pour prendre en compte les problématiques de déploiement en production et d’exploitation.

Lean d'un point de vue global

Bien sûr bon nombre de sessions ont porté sur la mise en oeuvre de Kanban mais cela fera certainement l’objet d’un autre article…

Le site officiel de la conférence : http://www.agileminds.be/event/2
Les vidéos des sessions sont disponibles ici : http://vimeo.com/agileminds