Tag Archives: waterfall

quels furent les billets DantotsuPM les plus lus en Juin 2017 ?

8 Août

les articles les plus lus sur DantotsuPM de Juin 2017

Ce mois-ci les billets appréciés des suiveurs du blog et autres visiteurs furent ceux liés à l’agilité, aux soft skills et à la qualité. Bonne relecture ou découverte !

15 vérités pas si évidentes sur les compétences relationnelles: les connaissez-vous? qu’ajouteriez-vous?

Les personnes non intuitives et de nombreux professionnels techniques disent que maitriser les aspects pas si évidents des interactions avec les personnes (« soft skills » ou compétences relationnelles) est un grand défi et souvent prise de tête.

certaines relations peuvent être particulièrement frustrantes !

Quelles vérités sur les compétences ces personnes doivent-elles apprendre et utiliser ?

« Peut-on se libérer de sa culture ? » (de waterfall vers l’agilité)

L’un des 2 sujets 2017 du bac S en philosophie: « Peut-on se libérer de sa culture ? » m’a immédiatement rappelé des discussions avec Claude Emond sur la culture Agile et plusieurs billets que nous avons ensemble publiés sur ce blog.

L’Aïkido Verbal est un moyen pacifique de gérer les attaques verbales, basé sur la philosophie de l’aïkido martial.

Pour aller plus loin, le livre sur Amazon

Cet art s’est inspiré de la pratique et de la philosophie de l’aïkido martial, et permet de diriger une agression verbale vers un résultat positif et équilibré. Comme dans l’art martial, l’assaillant et le défenseur sont dits « partenaires » et non « adversaires ». Il n’y a donc pas à proprement parler d’affrontement, ni vainqueur ni vaincu.

Connaissez-vous le nouveau Agile Practice Guide (en anglais) ?

PMI et Agile Alliance se sont mis au travail ensemble pour produire le Agile Practice Guide dans l’intention de forger une meilleure compréhension des pratiques agiles pour les chefs de projet.

la qualité est trop souvent considérée seulement à la fin des projets: les 14 points de Deming sont un guide pour l’obtenir systématiquement

Le livre sur Amazon

La qualité est mal comprise par trop de personnes qui n’y pensent que quand ils touchent au produit final. En réalité, c’est seulement au travers de processus de qualité centrés sur l’efficacité, l’innovation et l’amélioration continue qu’un produit de qualité est réalisé, et ces processus exigent une culture de management de qualité non seulement dans nos projets, mais aussi dans nos organisations.

Dans le chapitre 2 de son livre de 1986, « Out of the Crisis« , Edward Deming a présenté 14 prinipes dont il pense qu’ils peuvent rendre l’industrie plus compétitive grâce à un accroissement de la qualité.

Comment crever le double plafond de l’Agilité ?

Marc-Noël Fauvel

Billet original sur LinkedIn (republié avec l’autorisation de Marc-Noël Fauvel que je remercie)

L’agilité au niveau des équipes de développement a fait ses preuves depuis des années maintenant principalement grâce à SCRUM et XP.

Enregistrer

« Peut-on se libérer de sa culture ? » (de waterfall vers l’agilité)

16 Juin

L’un des 2 sujets 2017 du bac S en philosophie: « Peut-on se libérer de sa culture ? » m’a immédiatement rappelé des discussions avec Claude Emond sur la culture Agile et plusieurs billets que nous avons ensemble publiés sur ce blog.

Je vous invite donc aujourd’hui à les relire:

Enregistrer

Enregistrer

Enregistrer

1 Décembre – Lyon ( #PMI ®) – Agile versus Waterfall, vers l’hybridation des méthodes de management de projet

21 Nov

Le PMI France, Pôle Lyonnais vous invite le 1er Décembre à Lyon

On entend beaucoup parler d’agilité qui signerait la fin des méthodes classiques de gestion de projet. Pour autant, bon nombre d’entreprises utilisent encore très largement une approche traditionnelle.

  • Que faut-il faire et quand faut-il le faire ?
  • Faut-il tout miser sur l’agile ou rester sur les méthodes traditionnelles qui ont fait leurs preuves ?
Image courtesy of stockimages at FreeDigitalPhotos.net

Image courtesy of stockimages at FreeDigitalPhotos.net

La solution est peut-être entre les deux : l’hybridation entre gestion de projet traditionnelle et méthodes agiles afin d’utiliser leurs forces respectives et limiter l’impact de leurs faiblesses.

Cette conférence a pour objectif de présenter les grands principes d’une approche hybride :

  • Quelles sont les différences entre gestion agile et traditionnelle ?
  • Pourquoi l’hybridation ?
  • Comment choisir ?
  • Comment la mettre en œuvre ?

Intervention de Stéphane Derouin – Ancien Président et Fondateur du PMI France, Président de PMGS.

Partenaire de DantotsuPM

Partenaire de DantotsuPM

Événement ouvert à tous et gratuit pour les membres du PMI et de l’IAE Lyon (€10 pour participer aux frais pour les autres).

PMI is a registered mark of Project Management Institute, Inc.

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

17 Novembre – Caen ( #PMI ®) – Gestion de projet, entre musique classique et jazz…

6 Nov

Le PMI France, Branche Atlantique vous invite le jeudi 17 novembre 2016 à Caen

classsical-musicOn entend beaucoup parler d’agilité qui signerait la fin des méthodes classiques de gestion de projet. Pour autant, bon nombre d’entreprises utilisent encore très largement une approche traditionnelle.

  • Que faut-il faire et quand faut-il le faire ?
  • Faut-il tout miser sur l’agile ou rester sur les méthodes traditionnelles qui ont fait leurs preuves ?

La solution est peut-être entre les deux : l’hybridation entre gestion de projet traditionnelle et méthodes agiles afin d’utiliser leurs forces respectives et limiter l’impact de leurs faiblesses.

Cette conférence a pour objectif de présenter les grands principes d’une approche hybride :

  • jazzQuelles sont les différences entre gestion agile et traditionnelle ?
  • Pourquoi l’hybridation ?
  • Comment choisir ?
  • Comment la mettre en œuvre ?

Intervention de Stéphane Derouin – Ancien Président et Fondateur du PMI France, Président de PMGS.

Partenaire de DantotsuPM

Partenaire de DantotsuPM

Événement ouvert à tous et gratuit.

PMI is a registered mark of Project Management Institute, Inc.

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Scrum… Vraiment

13 Avr

agile-on-the-beachScrum… Really

http://www.scrumexpert.com/videos/scrum-really par Amy Thompson à Agile on the Beach 2015

Scrum est depuis longtemps la plus populaire des approches Agile pour développement logiciel.

Amy Thompson

Amy Thompson

Mais de quoi s’agit-il vraiment ? À quoi ressemble une grande équipe Scrum? Scrum est-elle réellement la collection d’approches flexible, libre d’esprit et que l’on pense pouvoir adapter pour convenir à tout ce qui marche pour nos efforts ? Dans nos tentatives d’être ‘Agile’, avons-nous oublié les avantages de la structure et de la discipline ? Adaptons-nous Scrum un peu trop pour nous convenir et quel en est l’impact ?

J’ai travaillé avec beaucoup d’équipes Scrum et Kanban, y compris celles qui utilisent de plus lourdes méthodologies Agile comme SAFe et RUP et celles qui fonctionnent indépendamment au sein d’une organisation en cascade (Waterfall). Cependant, chaque fois que je travaille dans un nouvel endroit, je vois les mêmes problèmes encore et encore qui empêchent les équipes d’atteindre leur potentiel à être extrêmement performantes. Idem quand je participe à des réunions et conférences Agiles et parle aux gens de comment ils ont essayé de ‘devenir Agile’, mais que cela ne semble pas fonctionner pour eux.

Partenaire de DantotsuPM

Partenaire de DantotsuPM

Récemment, j’ai vu une tendance croissante des professionnels Agile à en arriver à la conclusion qu’une approche plus évangéliste parviendra plus probablement à amener le succès aux Business et équipes.

L’adhésion du management est essentielle, cependant que je voudrais concentrer ma discussion (vidéo en anglais ci-dessous) sur pourquoi je crois que la discipline, la routine, la structure et une compréhension minutieuse du processus Scrum sont clés à une grande équipe Scrum. Et aussi, expliquer que ceci ne signifie pas que l’équipe est étranglée dans sa créativité, ni contrôlées par leurs environnements, c’est en réalité tout le contraire … (voici le pointeur vers la présentation en pdf)

Be WAGILE (Waterfall + AGILE) : « an Iron Fist in a Velvet Glove » by Marc Burlereaux, Christine Rieu and Sylvain Gautier

30 Sep

A French version of this post can be found here: soyons WAGILE (W-aterfall + AGILE) : « une main de fer dans un gant de velours »

Marc Burlereaux has presented an article written by Christine Rieu, Sylvain Gautier and himself about the pitfalls when introducing Agility at the Project Zone Congress 18,19 March 2013 in Frankfurt.

The Agile approach used for projects, or new product development, ensures a greater flexibility with iterative design, lighter documentation and formalization, more interactivity and efficiency in the conduct of meetings, and especially more customer involvement throughout the project (Pichler, 2010). By coupling a Lean approach to these Agile methods; we remove all unnecessary and ‘non-value added’ steps to minimize waste and to maximize the expected value of the product (Larman & Vodde, 2010). This seems to be the panacea!

But it is not straightforward to implement this type of approach and the Project Manager may be asked many questions:

questiono How will  these approaches be integrated successfully in mature Project Management organizations that are more familiar with traditional software V-Model (software development) or Waterfall Model?

o How will the Release Manager be in a position to facilitate the delivery of products developed with Agile and Lean approaches?  This is particularly relevant given his/her role is to keep adherence to rigid processes for minimizing the risks associated with change, which is often seen by the Agile Project Manager as an awful slowdown in the delivery process.

o How will these deliveries fit in the whole Release Management process, including testing procedures (unit, integration and acceptance testing of applications), the production of operating technical documentation, user guides, and the creation of installation and deployment procedures?

o How will you  avoid Agile being used as an excuse for lax and ineffective behaviours, such as removing documentation?

The success of such projects imposes a balance between a comprehensive Agile approach and a discipline warranty by the Release Management process. Hence the title of our paper, « An Iron Fist in a Velvet Glove. »

product backlogThis presentation is based on lessons learned gathered during project experiences combining Agility and Lean Management in various fields of industry and banking organizations. We explain our vision of the prerequisites for a project to be eligible for Agile methods. The thread of the presentation is to then illustrate our experiences with emphasis on Agile best practices that we have identified as key success factors. We have divided these keys points throughout the various phases of project development, with a particular emphasis on the early stages of scoping and preparation, and then the final stages of acceptance (technical and business) and finally the transition to production.

The following anecdote illustrates that sometimes agile’s team are surprisingly facing rigidity:

Geeky Unsure WomanJack Duggal, a seasoned Program Manager with over 30 years of experience in project management, said at a conference organized by PMI (Project Management Institute) in Geneva in 2012: « You can sometimes blame rigidity in the application of agility. In a Scrum meeting, which assumes that you are standing, a person a little tired had expressed the need to sit down: this was refused, as matter of principle!  »

Whatever method is chosen, we should be able to get inspired by other approaches and benefit from best practices:

As an example, PMI, which is the authority in the management of « traditional » projects, has naturally opened the door to the principles of Agility by recently creating a new credential PMI-ACP (Agile Certified Practitioner) and integrating Agile and Lean Management into traditional project management. For example, the PMBOK 5th edition now takes into account Agile « Adaptive Life Cycles » with section 2.4.2.4 covering iterative and incremental methods.  These methods involve short iterations of 2 to 4 weeks with fixed time and resources (i.e. time boxing).An important aspect to add is the risk management: this is an example of good practice derived from traditional methods integrated into agile approaches.

Finally, we conclude by reminding the four principles issued by the Manifesto for Agile software development written by Kent Beck and 16 other signatories (K. Beck et al, 2001) which by the way could be followed regardless of the chosen project management methodology:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  1. Agile ManifestoIndividuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

That is, while there is value in the items on the right, we place more value to the items on the left.

The Agile approach should be considered rather as a philosophy of development

In this presentation, we wanted to give very practical advice to implement a successful agile approach, especially in organizations which will combine it with more traditional models. It is inspired by our experiences in various project contexts and emphasizes the importance of deeply understanding the benefits and implementation impacts of this new way (i.e.  not just use it as a « tool box with an integrated checklist »). The Agile approach should be considered rather as a philosophy of development, which focuses on employee involvement and commitment. One has to take in each method that is « good for business », knowing that every business is unique and has its own specific operational characteristics. Opposed to traditional methods, Agile methods are a revolution, but they can also bring their share of the burden and stress, depending on the implementation and the use.

human factorThe Agility is good but to control it is even better …

The Scrum approach is not a panacea, especially if it is not understood and supported by the Management and Business Analyst (MOA)

The Lean Approach coming from the industry may not be implemented in all contexts

The AGILE mindset is primarily the key success factor that will ensure a smooth Agile implementation

We must select the right AGILE tools best suited to the company

A pragmatic coaching is a key success factor

– The dogmatism must be forgotten

– And we must contextualize the process that could not be standard for all areas (from the space industry to Google, through aerospace, automotive, banking …).

Last but not least, misunderstood and badly launched / implemented Agility may cause more damage than traditional methods.

Let’s Be WAGILE! Contraction of WATERFALL (traditional methods of development) and AGILE … hence Agility: An Iron Fist in a Velvet Glove!

Christine RieuChristine RIEU, works as an Associate Professor in the Listic laboratory and has carried out research on Knowledge Management for the past 15 years.  Christine teaches Project Management at the IUT of Annecy where she also holds the position of Head of International Relationships.  .  Christine is also a founding member of “PMI Pôle des Pays de Savoie”, France Chapter.

Marc BurlereauxMarc BURLEREAUX, has more than 27 years of expertise in Project, Program and Portfolio Management with a proven track record in the field of Swiss Private Banking.  Marc is a Senior Volunteer at PMI, Director of “Pôle des Pays de Savoie” (part of the France Chapter) and also a member of the PgMP® & PMI-RMP® Credentials PRC (Panel Review Committee). Marc has been applying agile technics for the past 10 years, and more recently has spent two years as Head of European Release Management in a Swiss Private Bank.

Sylvain GautierSylvain GAUTIER, has more than 27 years of expertise in IT and started his career working as a consultant, and then as an architect, within the Software Industry (Computer Associates, Sybase).  Sylvain focused mainly on data design, DBA, and project management methodologies for major European projects before becoming Head of IT Operations for an important private bank in Geneva.  Sylvain is now a freelance consultant applying Agile, ITIL, Archimate and Service Design best practice to companies within the Banking and Insurance sector.

Bonus video : « Agile: An Introduction »

14 février – Paris – atelier gratuit PMGS: Management de projet Agile vs Classique

28 Jan

Participez à l’atelier de notre sponsor PMGS: Management de projet Agile vs Classique, le 14 février entre 18:00 et 20:00 à Paris!

Agile 2Afin de tenir informé ses clients de l’évolution du marché et des nouvelles tendances en management de projet, PMGS lance les rencontres PMGS dont l’objectif est simple : organiser une série d’événements pour rassembler nos clients et toute personne évoluant dans les projets, sur des sujets clés du management de projet comme : le « Program management », l’approche Agile, les outils pour mesurer la maturité d’un projet, Portefeuille et gouvernance,etc.

Dans un contexte dans lequel les exigences des projets sont en perpétuelles évolutions, l’approche Agile peut alors prendre tout son sens. Mais alors comment choisir et combiner une gestion de projet Agile avec une approche plus traditionnelle ?

Pour participer à cet atelier ?

Si vous vous demandez s’il est préférable d’utiliser la méthode classique plutôt que la méthode Agile et bien comprendre les différences entre les deux, suivez cet atelier !

Il vous donnera les clés pour en connaître les différences et être en mesure de choisir la meilleure approche pour gérer son projet !

Ce sera également l’opportunité d’échanger ses pratiques avec les autres participants ; un cocktail sera proposé à partir de 19h30 !

Objectifs de cet atelier :

  • Vérifier les caractéristique du Cycle de vie prédictif – méthodes traditionnelles /Waterfall
  • Vérifier ce qui fait les fondements d’une approche adaptative – méthodes motivées par le changement ou méthodes agiles
  • Identifier les différences et complémentarités entre ces méthodes
  • Constituer un outil de sélection
  • Comment mettre en place et faire cohabiter ces différentes méthodes au sein d’une organisation

A qui est destiné cet atelier ?

  • Les personnes désirant obtenir une vision globale des deux approches
  • Les personnes évoluant dans un environnement Agile ou Traditionnelle et qui souhaitent appréhender les deux approches
  • Définir des objectifs réalistes et mesurables et garantir des résultats positifs
  • Estimer les coûts et les échéanciers d’un projet au moyen de techniques simples et éprouvées
  • Acquérir des compétences, des techniques et des concepts fondamentaux en matière de gestion de projet

Conditions d’inscription :

GRATUIT – Attention, il n’y a que 15 places disponibles pour cet événement, contactez-nous rapidement pour réserver la vôtre !

Afin de vous recevoir dans les meilleures conditions, merci de nous confirmer votre présence avant le vendredi 1er février !

Besoin de plus d’informations et pour vous inscrire ? Aurélie Pouliquen – apouliquen@pmgsgroup.com – 01 56 81 08 54

PMGS Formations en Management de Projet

Partenaire de DantotsuPM

En indiquant les informations essentielles pour toute inscription :

  • ENTREPRISE
  • FONCTION
  • NOM
  • PRENOM
  • EMAIL

vos clients sont-ils prêts pour Agile ?

21 Nov

Are Customers Ready for Agile?

http://www.scrumalliance.org/articles/403-are-customers-ready-for-agile par Shweta Darbha

prêt à essayer une nouvelle approche?La méthodologie « waterfall » a été présente depuis si longtemps que les organisations de développement logiciel qui la pratiquent – et leurs clients – sont complètement en accord avec le processus. Récemment notre gourou résidant Agile l’a indiqué en commentant qu’avec Agile, clients ou propriétaires de produit (« product owners ») ne peuvent pas décharger leurs pensées sur l’engineering. Autrement dit, ils ne peuvent pas donner à l’ingénierie d’un seul coup tous leurs besoins au démarrage, parce que Agile demande une constante collaboration dans laquelle les besoins sont alignés à la fois sur l’équipe et sur le business.

Cela m’a sonné à réfléchir : Intérieurement, dans une organisation de développement de produits qui utilise Agile, coûte que coûte les propriétaires de produit doivent s’aligner. Ils apprendront le concept d’arriéré de produit et de besoins qui s’empilent; ils accepteront les tâches que les experts Agile attendent d’eux. Cependant, dans une organisation pilotée par les projet où les clients sont les gardiens du besoin, est-ce que ces clients sont prêts pour Agile ?

Je me rappelle de plusieurs occasions pendant mes missions de conseil où trois à quatre mois ont été dédiés « à la découverte » des processus clients, l’esquisse des besoins, l’obtention de la signature d’un document de contenu de projet. Le tout avant que nous ne puissions commencer le projet. Les calculs d’allocation de ressources et d’échéanciers, étaient basés sur ces « besoins ». C’est que la communauté informatique communauté a appris à ses clients sur quoi attendre d’un projet.

Aujourd’hui, comme la communauté IT adopte et s’adapte aux pratiques Agile, en faisons-nous assez pour instruire et informer notre écosystème – nos clients ?

Ce qui suit sont mes opinions sur certains des processus ou des engagements auxquels ces clients ont besoin de s’adapter dans le monde Agile.

Vider son esprit par rapport à construire les besoins de manière itérative

réfléchissonsDans la méthodologie « waterfall » les besoins sont le début des projets, avec des clients les exposant et des consultants les documentant. Les besoins n’étaient jamais revisités de nouveau avec le client, puisque le client les avait déjà formellement signés. Les projets commençaient seulement après que la collecte de besoins soit finie.

Dans Agile, cependant, les besoins, depuis le début même, peuvent être définis comme des « épopées » et doivent régulièrement être décomposées en histoires. À chaque planification de sprint, toutes les parties prenantes (incluant le client) conviennent d’histoires (autrement dit de fonctionnalités et de besoins) qui doivent être développées et testées dans le prochain sprint. Cela devrait être utilisé comme un facteur « WOW » par l’équipe projet, pour aider des clients à comprendre qu’ils peuvent être complètement en accord avec ce qui est développé et ils peuvent aussi prioriser les fonctionnalités selon leurs besoins business.

Cependant, là se trouvent les défis :

  • Participation : les Clients doivent s’engager sur la démonstration et la planification de sprint. Si éviter celles-ci est la norme et les propriétaires de produit deviennent régulièrement des mandataires pour le client, les bénéfices d’Agile ne peuvent jamais être expérimentés ni implémentés.
  • Alignement des équipes : le fonctionnel, le développement et des équipes QA doivent sortir de leurs mentalités « waterfall » et travailler vraiment en tandem dans chaque sprint, recherchant des démonstrations de sprint réussies sans balayer les problèmes sous le tapis.

Les estimations du management par rapport aux évaluations de point d’histoire d’équipe Scrum

En « waterfall », des échéanciers de projet partent du « go ». On s’attend à quelques semaines de collecte des besoins pour permettre au projet et aux managers de dessiner un parfait plan de projet, avec allocation des ressources, test d’acceptation utilisateur et date de livraison bien définie. Un chef de projet méritant son salaire intégrera toujours une marge de 20 à 30 pour cent.

Agile tourne ce processus sur sa tête. Il implique que l’équipe de Scrum (pas le management) devrait calculer les point d’histoire (« Story Points ») et s’engager à atteindre ces points d’histoire en fonction de la vélocité de l’équipe.

Ici, les défis sont :

  • Planification de projet : je crois qu’un échéancier est le plus grand défi du projet. L’idée de toujours avoir une date finale de projet (qui, selon diverses études, n’est pas respectée dans 80% des cas en « Waterfall ») sont si innés dans les organisations IT et chez leurs clients qu’atteindre la date finale possible de projet basée sur des points d’histoire va demander beaucoup de désapprentissage avant que cela ne puisse arriver.
  • Évaluations récurrentes : les propriétaires de produit, ainsi que les clients, doivent participer à la planification de Sprint en aidant ‘équipe, à nettoyer et calculer les points d’histoire de l’arriéré de produit. Ils peuvent alors voir ce qui peut être accompli dans le sprint à venir et ce quels sont les reliquats du sprint précédent.
  • Vélocité d’équipe : la méthodologie Agile implique que l’équipe soit assez mâture pour connaître sa vélocité, a suffisamment d’expérience pour estimer les besoins et a assez d’autorité pour s’engager sur les échéances.

Fin de développement par rapport à démonstration de sprint

démonstrationLes démonstrations de sprint exigent que l’équipe Scrum ait un morceau de code qui marche, digne d’être montré, mais elles exigent aussi l’engagement de la partie prenante clé : le client.

Les défis de cette approche :

  • Revue constante : si l’ingénierie et l’assurance qualité (QA) doivent s’adapter à des cycles de trois à quatre semaines pour créer un morceau de code fonctionnel et digne d’être montré, le client et le propriétaire de produit doivent aussi s’adapter au processus de constante revue. Le succès ou l’échec d’une histoire ramènent finalement à combien l’équipe Scrum a bien compris l’histoire, appelant ainsi à une revue de l’histoire elle-même. Fini sont les jours « Mais je pensais que vous aviez compris ce que je vous avais alors dit ». Si la planification de sprint et même les réunions « stad up » quotidiennes ont abouti à un écart de communication, l’équipe entière doit revisiter beaucoup de terrain, les besoins n’en étant qu’une partie.

Les projets au temps passé et dépenses contre coût fixe

La méthode « waterfall » permet aux organisations de négocier des contrats comme des offres à coût fixe ou bien en fonction du temps passé et des dépenses en matériel. Le type d’offre est dirigé par les offres des concurrents, la longueur possible du projet et le budget et la force de négociation du client.

Cependant, dans le monde Agile, cela n’aurait pas de sens d’avoir des contrats de type temps + coûts en matériels.

article précédent sur assistons-nous à la fin des contrats « classiques »?

Voici Pourquoi:

  • Des pratiques de sprint itératives donnent à toutes les parties prenantes la capacité d’arrêter le projet après n’importe quel sprint. (Assomption : à la fin de n’importe quel sprint, l’équipe a un code qui marche.)
  • La planification de sprint permet à toutes les parties prenantes d’avoir accès et d’analyser ce qui peut être réalisé dans des sprints futurs en fonction de la vitesse de l’équipe.
  • Le soin porté à l’arriéré de produit permet aux besoins d’être alignés sur les besoins business avant chaque sprint, ce qui permet aux clients de prioriser selon ses objectifs business. Par exemple, donner à l’intégration du site Web à PayPal pour les achats en lige la priorité sur un tableau de bord pour les partenaires, atteignant ainsi une présence en ligne avant que la campagne publicitaire « achetez en ligne » ne devienne virale.

Voici quelques-uns des aspects d’Agile auxquels je crois que les organisations doivent s’adapter. Mais un point important est que les clients doivent aussi changer la façon dont ils engagent dans un Monde Agile.

Voici une petite vidéo de Vincent McGevna sur comment « Agiliser » l’approche « Waterfall ».

%d blogueurs aiment cette page :