Agile Adoption Anti-Patterns
July 21, 2010
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. By all means use an agile approach to salvage a core set of valuable functionality from a failing project, but don’t expect agile methods to miraculously make the impossible possible.
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. Instead they could be using agile’s preference for low ceremony documents as an excuse for avoiding doing the disciplined activities that make up each of the agile methods. Hold them accountable, ask for their estimates and request their retrospective findings.
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, but 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 towards the true business requirement, they may just see the lack of a defined end-point and so it is important to educate other stakeholders. By managing expectations the barriers to acceptance can be removed or reduced before they become an issue.
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 demo’d 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. Try processing last week’s transactions, or some other activity that exercises the system beyond a cosmetic review. It is much better to discover problems early while there is time to fix them, than later when things have been built on top of the functionality and we are close to the go live date.
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, features completed and accepted, but am leery about process fixation metrics like percentage of agile practices followed, or time spent pairing etc. These are OK to examine in retrospectives 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.
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 towards the true business requirement, they may just see the lack of a defined end-point and so it is important to educate other stakeholders. By managing expectations the barriers to acceptance can be removed or reduced before they become an issue.
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 demo’d 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. Try processing last week’s transactions, or some other activity that exercises the system beyond a cosmetic review. It is much better to discover problems early while there is time to fix them, than later when things have been built on top of the functionality and we are close to the go live date.
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, features completed and accepted, but am leery about process fixation metrics like percentage of agile practices followed, or time spent pairing etc. These are OK to examine in retrospectives 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.
you've hit the nail on the head with these- all too often people view agile as a quick fix or as a less disciplined form of PM, when it is anyhting but.
Posted by: project management software | July 23, 2010 at 09:24 AM