La question du titre, où l'innovation fait référence à des avancées créatives à plus petite échelle dans une équipe qui se porte déjà bien en Agile.
La meilleure réponse est résumée dans cet article sur les "Gold Card Days" .
Résumé (paraphrasé et avec mes propres interprétations qui peuvent ne pas refléter les intentions de l'auteur) :
- Les développeurs peuvent identifier des objectifs d'étirement intéressants (stimulants intellectuellement) liés au travail sur lesquels ils aimeraient travailler.
- Ces objectifs étendus, après avoir été approuvés par l'équipe (y compris le propriétaire du produit), deviennent des "cartes d'or".
- L'équipe est encouragée à prendre une journée pour travailler sur ces "cartes d'or".
- Habituellement, cela se passe le vendredi, il devient donc le "Gold Card Day".
- En ce qui concerne Scrum, les cartes Gold sont planifiées et suivies comme tout autre élément de carnet de commandes; l'équipe devra démontrer ses résultats.
Il y a quelques autres points (pas dans cet article) concernant l'application des "cartes d'or":
- Ne laissez pas un seul membre de l'équipe prendre tout le plaisir. Chaque membre de l'équipe devrait être encouragé à passer du temps créatif en prenant une «journée de la carte d'or» de temps en temps.
- Dans le même ordre d'idées, essayez de faire d'une "carte d'or" un effort d'équipe (par opposition à une tâche solo), et exploitez cette tâche comme un moment de socialisation (team building).
La question de fond, où l'innovation se réfère à la recherche (des mois à des années de travail horrible) qui ont un risque réel de ne trouver aucune solution utile.
Cette question précédente, quelles techniques de programmation extrême sont appropriées à utiliser dans un environnement de recherche? couvre une grande partie du terrain de cette question.
(Avertissement: j'ai écrit l'une des réponses à cette question, mais pas celle sélectionnée.)
Le résumé est que le travail de recherche sur les logiciels peut être rapide; elle oblige ses participants à établir des priorités sur la base de nouvelles informations (en absorbant les idées découvertes / apprises et en synthétisant de nouvelles). Il donne l'apparence d'être "lent" uniquement parce qu'il est "lent à montrer les fruits du succès, et seulement s'il a réussi".
Cette question sur la gestion de projet bêta - Quels sont les avantages et les inconvénients de l'intégration d'un chef de projet dans une équipe de recherche? - couvre également les mêmes motifs.
En esprit, oui.
Comme indiqué dans la réponse de mouviciel , l'esprit de la recherche logicielle est conforme à l'esprit du Manifeste Agile. Ce que je discuterai ensuite est de savoir si la recherche à haut risque peut être intégrée dans Agile en tant qu'organisation ou méthodologie de gestion ("Agile dans la pratique").
En pratique, vous devez répondre à quelques questions.
Cette liste n'est pas exhaustive...
Nous devons retracer un peu comment la méthodologie Agile a vu le jour.
La méthodologie Agile est généralement utilisée lorsqu'il y a un sponsor du projet. De plus, la volonté du sponsor de financer le projet est limitée; il s'attend à ce que des logiciels de qualité utilisable (potentiellement livrable) soient livrés régulièrement après avoir financé le projet pendant un certain temps.
Le type de travail de recherche dans cette question fait référence à des «efforts potentiellement non résolubles». En d'autres termes, la nature même de ce type de travail comporte un risque qu'il puisse finalement échouer, malgré toutes les intentions et la diligence des personnes impliquées.
Ce n'est pas une liste de contrôle de style ScrumButt.
Il s'agit plus d'une liste de contrôle en amont qui prédit si l'on est mieux "Que Sera, Sera"
1. Transparence dès le départ. Le promoteur du projet se fait-il dire la vérité sur la nature risquée du projet?
2. Volonté du parrain. Le parrain est-il conscient du risque et est-il disposé à poursuivre le financement?
Le sponsor doit avoir une acceptation des risques supérieure aux projets commerciaux typiques ou aux projets logiciels / informatiques / agiles typiques. Tous les sponsors ne répondent pas à ces critères. Si cela ne convient pas, il serait bon qu'un professionnel se retire du projet.
3. Transparence tout au long du projet. Le sponsor est-il régulièrement informé de l'état réel du projet?
Il s'agit de contrecarrer les tentatives de masquer les échecs ou les échecs imminents dans le projet en abusant du laps de temps entre les mises à jour de statut.
4. Participation active du sponsor. Le sponsor est-il intéressé à connaître les moindres détails, les hauts et les bas, les promesses et les limites de chaque tentative?
Le problème avec la recherche sur les logiciels est qu'il peut y avoir de nombreuses fausses pistes - à la fois de faux positifs (croyant qu'une approche fonctionnerait mais qui n'a finalement pas réussi) et de faux négatifs (prétendre que quelque chose n'est pas possible, seulement pour être réfuté par quelqu'un d'autre) .
Les projets agiles permettent à l'équipe (y compris les sponsors et les parties prenantes) de prendre des risques calculés. «Calculé» signifie que les preneurs de risques sont pleinement informés. Si le sponsor n'est pas disposé à apprendre les détails du projet, il ne disposera pas d'informations complètes pour calculer (juger) le risque par lui-même.
Même si un sponsor est disposé à prendre le risque financier, s'il n'est pas disposé à prendre également les risques de prise de décision (et accepte les conséquences de ses propres choix), le sponsor est également inapte à de tels projets de recherche à haut risque.
5. L'équipe de recherche peut-elle montrer (démontrer) ses progrès sous la forme d'un logiciel en cours d'exécution, par opposition à des diapositives de présentation?
Cette question est appropriée pour les projets de recherche où le résultat final devrait être l'exécution d'un logiciel. Les diapositives de présentation pourraient être utiles pour expliquer les théories CS, mais elles pourraient également être utilisées à mauvais escient pour masquer des revers dans l'implémentation du logiciel (ou l'absence totale de). Une démo de logiciel est destinée à contrecarrer de tels abus.
6. L'équipe de recherche peut-elle fournir un produit logiciel partiellement valable, même si le commanditaire décide de suspendre le financement à tout moment du projet?
Cette question n'est pertinente qu'au cas par cas. Certains projets de recherche sont progressifs; ils peuvent avoir plusieurs étapes et livrables. Il faut qu'une équipe de recherche priorise ses approches pour privilégier les «fruits les plus bas qui pendent d'abord» ou «l'approche la moins coûteuse pour démontrer la viabilité».
Certains projets de recherche ne sont pas incrémentaux: apporter une percée technologique unique et très spécifique. C'est un hasard. Pour ce type de projets, les seuls résultats supplémentaires sont les travaux de recherche et de prototypage, et peut-être les publications académiques. Ces livrables incrémentiels «non consommables» sont néanmoins précieux pour certains types de sponsors - à savoir les universités, les agences de financement de la recherche et les grandes sociétés qui espèrent développer la bonne volonté académique.
Cependant, des projets de recherche ayant de telles caractéristiques pourraient également favoriser l'approche du "codage Cowboy", comme expliqué plus loin. Ceux-ci sont appelés à juste titre "hacks", et ils se produisent dans le monde universitaire.
En raison de l'échelle de temps de la plupart des recherches universitaires, le financement de la recherche de type universitaire est généralement fourni avec un engagement d'une ou plusieurs années; le financement de la recherche médicale (universitaire et commerciale) peut être engagé pour des périodes encore plus longues. D'un autre côté, la recherche typique financée par le commerce peut être interrompue sans préavis ou voir ses ressources (main-d'œuvre) entièrement réaffectées à d'autres projets.
7. Comment l'équipe de recherche mesure-t-elle l'échelle du silo par rapport à la fonction transversale?
Certains types d'équipes de recherche sont très cloisonnés. Cela se produit souvent dans des projets "multidisciplinaires" - exactement un membre de chaque discipline est impliqué. En conséquence, aucun membre ne peut reprendre la tâche d'un autre membre, même pas de très petite taille, car leurs connaissances et leurs compétences ne se chevauchent pas. La difficulté s'étendrait également aux communications et à la définition des tâches.
Les équipes extrêmement cloisonnées bénéficieront toujours de certains rituels Scrum tels qu'une réunion de stand-up quotidienne, mais en dehors du "rituel", il peut ne pas y avoir beaucoup d'interaction. Il faudrait un coach agile hautement socialisant pour amener l'équipe à parler et à instaurer la confiance.
8. Si un entraîneur agile est présent, l'entraîneur prescrit-il des cycles d'itération courts, la boxe temporelle et des estimations de temps?
Chacune de ces pratiques agiles pose des difficultés pour certains types de projets de recherche. Néanmoins, il a été signalé que certains groupes de recherche hautement qualifiés étaient en mesure d'appliquer ces pratiques dans la recherche avancée . Puisqu'il n'y a aucun détail sur la façon dont le coaching agile se produit au sein de ces équipes d'experts, nous ne pourrons peut-être pas savoir comment chacune de ces difficultés pourrait être surmontée.
9. L'équipe de recherche vote-t-elle à l'unanimité pour adopter le style de développement Solo par rapport à toute autre méthodologie?
Édité: une version antérieure utilise l'expression "codage cowboy", qui fait allusion au manque de professionnalisme. Cependant, il existe une différence entre le développement solo et le codage cowboy, et les circonstances de cet élément de la liste de contrôle peuvent faire du développement solo un choix légitime.
Cette question montre qu'il y a des programmeurs qui préfèrent posséder un gros morceau de développement. Si l'équipe de recherche est principalement composée de ce type de programmeurs, étant donné que l'ensemble de compétences des membres de l'équipe est irremplaçable (en se référant au point de compétence précédent), alors les membres de l'équipe peuvent devoir obtenir ce qu'ils souhaitent, en échange pour leurs compétences et leur travail.
La principale différence entre le développement solo et le codage cowboy est que dans le développement solo, on peut adopter les pratiques énumérées dans Le test Joel: 12 étapes pour améliorer le code , telles que l'utilisation du contrôle de version, l'automatisation de la construction et la correction des bogues avant d'ajouter de nouvelles fonctionnalités .
Certaines circonstances favoriseront le développement solo de chaque membre, tandis que certaines circonstances favoriseront le codage cowboy.
Le codage Cowboy est privilégié si l'objectif final est de «faire valoir un point», en montrant que quelque chose est technologiquement possible. Il n'y a aucune exigence de livraison - ni de qualité - à part une bonne présentation sur le prochain DEF CON ® .
Dernière question. Si les circonstances ne permettent pas à une équipe Agile de mener des recherches révolutionnaires, comment utilisent-elles des technologies innovantes?
Comme d'habitude. Laissez d'autres entreprises (ou universitaires, particuliers ou équipes de pirates informatiques , startups, etc.) s'attaquer d'abord au problème difficile, puis acheter / licencier la technologie auprès d'eux. L'industrie du logiciel fonctionne selon ces principes depuis de nombreuses décennies.
L'accent mis sur la présentation des premiers prototypes de travail dans la méthodologie Agile oblige une équipe à rechercher d'abord les solutions existantes, ce qui est une bonne chose car cela peut sauver l'équipe d'un travail redondant.