Les méthodes Agile / Lean Software Development, empruntant des principes de Lean management pour mener les projets informatiques, sont à ce jour reconnues pour leurs bénéfices en terme d’efficience et d’apport de valeur aux clients.
Cependant, comme pour toute méthode, il y a des écueils à éviter.
Cet article de gantthead, proposé par Mike Griffiths impliqué dans la création de la méthode DSDM en 1994 et ayant pratiqué les méthodes Agile pendant 16 ans, traite des 5 erreurs à ne pas faire lors de la mise en place de méthodes Agiles.
Morceaux choisis :
Agile methods are powerful approaches that bring many benefits to how we undertake project work. However, they are not immune to misuse or failure. The following list of five common pitfalls is often seen in organizations switching to agile. As they say: “To be forewarned is to be forearmed.” So look out for these pitfalls and if you see any developing, a side step can be useful to help avoid the mistakes of others.
1. Agile as a silver bullet.
Yes, agile methods can save time, increase business buy-in and create a high quality product, but they are no silver bullet. They will not bend space or time and allow you to deliver more work that is possible within the constraints of limited time, budget and resources.
Deciding to switch a doomed project to an agile approach will not make it succeed. You may fail faster, or at least discover realistic progress indicators (velocity) earlier than with a traditional approach–but unachievable goals will remain unachievable.
2. Agile as an excuse for no discipline.
Contrary to some people’s beliefs, agile methods do not abandon discipline and jump straight to coding without the need for plans and estimates. Agile methods involve many high-discipline activities and techniques like Test Driven Development, Wideband Delphi estimation, and bi-weekly iteration planning and estimation sessions take a lot of discipline.
If team members are pushing back on estimating or cannot explain the release plan, these are warning signs that they may not be following the agile practices.
3. Agile without explanation.
Projects and teams do not exist within a vacuum; they have interactions with many other stakeholders in the organization. While it might seem easier at first to keep the agile practices to your team (a domain you have more influence over), there comes a time when you need to explain the working practices to others.
Groups like enterprise architecture or the database group may not understand the iterative nature of agile projects and may mistake the progressive elaboration of requirements and churn. Where the agile team is iterating toward the true business requirement, they may just see the lack of a defined end-point and so it is important to educate other stakeholders.
4. Shallow feedback.
Agile methods rely on feedback on an evolving system to confirm understanding and gain acceptance of work done. Typically new features are demoed to the business and left with them in a test environment for their trial and feedback. It is tempting to think that if we receive little or no feedback then the users must be happy with what we have developed. However, it is far more likely that they have not really looked at it properly or tried it with real data or scenarios.
Rather than hoping users will thoroughly test new functionality without any help or guidance, consider scheduling lunch-and-learns sessions and reviewing it together.
5. Agile process fixation.
People get passionate about agile methods, which is generally a good thing. But if people start to focus too much on the process at an expense to delivering business value, then we have a problem. Projects are usually undertaken and funded to effect some business change or improvement. We are not in business to practice perfect methods; the ultimate goal is delighting our sponsors and users, not obsessing on process or building resumes.
I like project metrics that focus on the end goal–like customer satisfaction and features completed and accepted–but am leery about process fixation metrics like percentage of agile practices followed or time spent pairing, etc. These are okay to examine in retrospect with the goal of improving our execution, but conformance for conformance sake is (in my book) a sign we have lost the plot.
So, go boldly with your agile adoption–but be mindful of some common mistakes that can be easily avoided providing you know what to look for.
