Le deuxième jour de la conférence GOTO Amsterdam 2013 a démarré par une keynote de Martin Fowler sur le développement logiciel au 21ème siècle. Il a présenté les raisons pour lesquelles l'Agilité a démarré dans les années 90 pour expliquer comment aujourd'hui les équipes peuvent devenir fluide en Agilité, et donner toute la mesure de leurs capacités.
L'Agilité est née en réponse aux projets en retard, livrant des applications bugguées à des utilisateurs insatisfaits, et dont les développeurs étaient démotivés. Des méthodes pilotées par le planning étaient utilisées à cette époque pour développer des logiciels, Martin les a comparé à l'Agilité. Cette dernière diffère car elle s'appuie sur des planning adaptatifs contrairement au pilotage par le planning qui utilise des planning prédictifs. Alors que l'Agilité se concentre sur les individus, les méthodes pilotées par le planning reposent sur des processus. Dans les méthodes pilotées par le planning, il y a différentes étapes pour planifier votre travail et le suivre, le succès étant défini "selon le planning". Puisque les planning dépendent d'une stabilité des exigences métier, ces méthodes voulaient les stabiliser, là où l'Agilité veut casser la dépendance entre le planning et des exigences stables en acceptant le changement.
Comme Martin l'indiquait précédemment, l'Agilité diffère aussi du pilotage par le planning par la façon dont elle voit les processus et les individus. Il a montré comment l'Agilité est un changement d'état d'esprit vers "les individus en premier" au lieu des "processus d'abord". Les processus de développement logiciel dans les méthodes pilotées par les planning sont composées d'étapes liées entre elles, impliquant des individus qui suivent le processus. L'Agilité a une approche différente, en commençant par rassembler les individus en une équipe, et en la laissant ensuite décider de son processus de travail le plus adapté. Martin affirme que "c'est une erreur d'ordonner à une équipe de devenir agile". Les équipes choisiront elles-même de faire des choses agiles ou non, et c'est très bien ainsi.
Cela soulève la question du moment où les équipes doivent être, ou non, agile, et comment elles veulent être fluide en Agilité. Diana Larsen et James Shore ont écrit à propos de la Fluidité Agile; Martin a publié leur article dans "notre chemin a travers la Fluidité Agile". Diane et James ont défini la fluidité ainsi :
La Fluidité, c'est comment une équipe développe du logiciel quand elle est sous pression. N'importe qui peut suivre un ensemble de pratiques quand on lui donne du temps pour se concentrer dans une salle de classe; la vraie fluidité est une pratique subtile et quotidienne qui persiste quand votre esprit est perturbé par autre chose.
Martin a présenté comment les équipes peuvent augmenter leur Fluidité Agile, suivant 4 niveau d'étoiles. Au niveau 1 étoile, les équipes divisent le travail en parties individuelles pour livrer de la valeur métier. Vous devez investir dans le développement de l'équipe et la conception du processus pour atteindre ce niveau, cela prend généralement de 2 à 6 mois. Les équipes au niveau 2 étoiles "livrent à la cadence du marché"; réalisant plus de valeur en livrant aussi souvent que le marché peut le supporter. Un investissement est nécessaire dans les pratiques et les connaissances techniques telles que XP, TDD et la programmation en binôme pour améliorer leur artisanat logiciel, et avoir une équipe productive qui délivre du logiciel avec moins de défauts. Cela prend généralement de 3 à 24 mois pour atteindre ce niveau.
Les équipes au niveau 3 étoiles optimisent leur valeur métier en utilisant des métriques et les équipes du niveau 4 étoiles contribuent au succès à l'échelle de l'entreprise. Martin a indiqué qu'il ne voit pas beaucoup d'équipes au niveau 3 et 4 étoiles. Il suggère aux équipes de réfléchir au niveau qu'elles veulent atteindre, et si elles sont capables et volontaires pour faire cet investissement.