Agile Principles and Values, by Jeff Sutherland
Microsoft Visual Studio 2010
Agile development is a term that was derived from the Agile Manifesto, which was written in 2001 by a group that included the creators of Scrum, Extreme Programming (XP), Dynamic Systems Development Method (DSDM), and Crystal; a representative of feature-driven development; and several other thought leaders in the software industry. The Agile Manifesto established a common set of overarching values and principles for all of the individual agile methodologies at the time. It details four core values for enabling high-performing teams.
- Individuals and their interactions
- Delivering working software
- Collaboration avec les clients
- Répondre au changement
These core values are supported by 12 principles, which you can find at the following Web site: Manifesto for Agile Software Development.
These values are not just something the creators of the Agile Manifesto intended to give lip service to and then forget. They are working values. Each individual agile methodology approaches these values in a slightly different way, but all of these methodologies have specific processes and practices that foster one or more of these values.
Individus et interactionsLes individus et les interactions sont essentiels aux équipes performantes. Des études sur la "saturation de la communication" au cours d'un projet ont montré que, lorsqu'il n'y a pas de problèmes de communication, les équipes peuvent être 50 fois plus performantes que la moyenne du secteur. Pour faciliter la communication, les méthodes agiles reposent sur des cycles fréquents d'inspection et d'adaptation. Ces cycles peuvent aller de quelques minutes avec la programmation en binôme, à quelques heures avec l'intégration continue, à chaque jour avec une réunion quotidienne, à chaque itération avec une revue et une rétrospective.
Toutefois, il ne suffit pas d'augmenter la fréquence du retour d'information et de la communication pour éliminer les problèmes de communication. Ces cycles d'inspection et d'adaptation ne fonctionnent bien que si les membres de l'équipe adoptent plusieurs comportements clés :
- le respect de la valeur de chaque personne
- la vérité dans chaque communication
- la transparence de toutes les données, actions et décisions
- faire confiance à chaque personne pour soutenir l'équipe
- l'engagement envers l'équipe et ses objectifs
To foster these types of behavior, agile management must provide a supportive environment, team coaches must facilitate their inclusion, and team members must exhibit them. Only then can teams achieve their full potential.
Il est plus difficile qu'il n'y paraît d'adopter ce type de comportement. La plupart des équipes évitent la vérité, la transparence et la confiance en raison de normes culturelles ou d'expériences négatives passées liées à des conflits générés par des communications honnêtes. Pour lutter contre ces tendances, les dirigeants et les membres de l'équipe doivent faciliter les conflits positifs. Cela permet non seulement de créer un comportement productif, mais présente également plusieurs autres avantages :
- L'amélioration des processus dépend de la capacité de l'équipe à dresser une liste des obstacles ou des problèmes de l'organisation, à les affronter sans détour et à les éliminer systématiquement par ordre de priorité.
- L'innovation ne se produit qu'avec le libre échange d'idées contradictoires, un phénomène étudié et documenté par Takeuchi et Nonaka, les parrains de la Scrum.
- L'alignement de l'équipe sur un objectif commun nécessite que l'équipe mette à jour et résolve les conflits d'agenda.
- L'engagement à travailler ensemble ne se produit que lorsque les personnes s'accordent sur des objectifs communs et s'efforcent ensuite de s'améliorer personnellement et en tant qu'équipe.
Le dernier point, relatif à l'engagement, est particulièrement important. Ce n'est que lorsque les individus et les équipes sont engagés qu'ils se sentent responsables de fournir une valeur élevée, ce qui est l'essentiel pour les équipes de développement de logiciels. Les méthodologies agiles facilitent l'engagement en encourageant les équipes à s'appuyer sur une liste de tâches prioritaires, à gérer leur propre travail et à se concentrer sur l'amélioration de leurs méthodes de travail. Cette pratique est la base de l'auto-organisation, qui est la force motrice pour obtenir des résultats dans une équipe agile.
Pour créer des équipes performantes, les méthodologies agiles valorisent les individus et les interactions plutôt que les processus et les outils. En pratique, toutes les méthodologies agiles cherchent à améliorer la communication et la collaboration grâce à des cycles fréquents d'inspection et d'adaptation. Toutefois, ces cycles ne fonctionnent que lorsque les leaders agiles encouragent les conflits positifs nécessaires à la construction d'une base solide de vérité, de transparence, de confiance, de respect et d'engagement au sein de leurs équipes agiles.
Working software is one of the big differences that agile development brings. All of the agile methodologies that are represented in the Agile Manifesto stress delivering small pieces of working software to the customer at set intervals.
All agile teams must establish what they mean when they say "working software," which is frequently known as the definition of done. At a high level, a piece of functionality is complete only when its features pass all tests and can be operated by an end user. At a minimum, teams must go beyond the unit test level and test at the system level. The best teams also include integration testing, performance testing, and customer acceptance testing in their definition of what it means to be done with a piece of functionality.
One CMMI Level 5 company has shown, through extensive data on many projects, that defining acceptance tests along with the feature, implementing features serially and in priority order, immediately running acceptance tests on each feature, and fixing any bugs that are identified as highest priority will systematically double the speed of production and reduce defects by 40 percent. This from a company that already has one of the lowest defect rates in the world.
The Agile Manifesto recommends that teams deliver working software at set intervals. Agreeing on a definition of done is one of the practical ways that agile teams bring about the high performance and high quality that is needed to accomplish this goal.
Over the past two decades, project success rates have more than doubled worldwide. This is attributed to smaller projects and frequent deliveries, which allow the customer to provide feedback on working software at regular intervals. The writers of the manifesto were clearly on to something when they stressed that getting the customer involved in the software development process is essential to success.
The agile methodologies foster this value by having a customer advocate work hand-in-hand with the development team. The first Scrum team, for example, had thousands of customers. Because it was not feasible to involve them all in product development, they selected a customer proxy, called a product owner, to represent not only all the customers in the field, but also management, sales, support, client services, and other stakeholders. The product owner was responsible for updating the list of requirements every four weeks as the team released working software, taking into account the current reality and actual feedback from customers and stakeholders. This allowed the customer to help shape the software that was being created.
The first XP team began with an internal IT project. They were able to have a company end user on their team work with them daily. About 10 percent of the time, consultancies and internal teams can find an end user who can work with the team on a day-to-day basis. The other 90 percent of the time, they must appoint a proxy. This customer proxy, whom XP teams call the customer, works with end users to provide a clear, prioritized list of features for developers to implement.
Collaborating with the customer (or customer proxy) on a daily basis is one of the key reasons why industry data shows that agile projects have more than twice the success rate of traditional projects on average worldwide. Agile methodologies recognize this and, as such, have created a place on their development teams that is specifically for the customer representative.
Responding to change is essential for creating a product that will please the customer and provide business value. Industry data shows that over 60 percent of product or project requirements change during the development of software. Even when traditional projects finish on time, on budget, with all features in the plan, customers are often unhappy because what they find is not exactly what they wanted. "Humphrey’s Law" says that customers never know what they want until they see working software. If customers do not see working software until the end of a project, it is too late to incorporate their feedback. Agile methodologies seek customer feedback throughout the project so that they can incorporate feedback and new information as the product is being developed.
All agile methodologies have built-in processes to change their plans at regular intervals based on feedback from the customer or customer proxy. Their plans are designed to always deliver the highest business value first. Because 80 percent of the value is in 20 percent of the features, well-run agile projects tend to finish early, whereas most traditional projects finish late. As a result, customers are happier, and developers enjoy their work more. Agile methodologies are based on the knowledge that, in order to succeed, they must plan to change. That is why they have established processes, such as reviews and retrospectives, that are specifically designed to shift priorities regularly based on customer feedback and business value.
Agile development is not a methodology in itself. It is an umbrella term that describes several agile methodologies. At the signing of the Agile Manifesto in 2001, these methodologies included Scrum, XP, Crystal, FDD, and DSDM. Since then, Lean practices have also emerged as a valuable agile methodology and so are included under the agile development umbrella in the illustration later in this topic.
Each agile methodology has a slightly different approach for implementing the core values from the Agile Manifesto, just as many computer languages manifest the core features of object-oriented programming in different ways. A recent survey shows that about 50 percent of agile practitioners say that their team is doing Scrum. Another 20 percent say that they are doing Scrum with XP components. An additional 12 percent say that they are doing XP alone. Because more than 80 percent of agile implementations worldwide are Scrum or XP, MSF for Agile Software Development v5.0 focuses on the core processes and practices of Scrum and XP.
Scrum is a framework for agile development processes. It does not include specific engineering practices. Conversely, XP focuses on engineering practices but does not include an overarching framework of development processes. That does not mean that Scrum does not recommend certain engineering practices or that XP has no process. For example, the first Scrum implemented all of the engineering practices that are now known as XP. However, the Scrum framework for software development was designed to get a team started in two or three days, whereas engineering practices often take many months to implement. Therefore, it left the question of when (and whether) to implement specific practices up to each team. Scrum co-creators Jeff Sutherland and Ken Schwaber recommend that Scrum teams get started immediately and create a list of impediments and a process improvement plan. As engineering practices are identified as impediments, teams should look to XP practices as a way to improve. The best teams run Scrum supplemented with XP practices. Scrum helps XP to scale, and XP helps Scrum to work well.
For more see Microsoft Visual Studio ...
French 
English 
Spanish