Agile - why sometime doesn't work #^
#6 - Agile has limited project planning, estimating and tracking. There are tools available in the Agile arsenal for planning estimating and tracking, but as Agile proponents will tell you, there’s very little emphasis on these core aspects of project management. By design, Agile minimizes planning through the use of backlogs – prioritized to-do lists of software product features – and by fixing deadlines instead of scope. In most cases, estimating level-of-effort is done for each iteration (sprint), with only rough estimates for for each release.Efforts to track progress vary – some projects ask the developer to mark a specific task on the backlog as “done”, while others ask team members to report hours while tracking which work items are designed, developed an tested as though they flow through a miniature life-cycle in each iteration.In most cases, this lightweight planning, estimating and tracking process suits small, non-strategic projects well. But often is not acceptable when the customer is a third-party who requires scope and cost defined via contract or a senior manager who wants to know what will be provided, when it will be done and how much it will cost.
#8 - Challenges making contractual commitments. For many projects, the client and/or senior management want commitments about the triple-constraints – what will be provided (scope), when it will be provided (time), and how much it will cost (cost). For Agile projects, in particular, it is extremely difficult to prepare estimates for fixed-bid contracts and its not uncommon to see senior managers pound their fists on the table when they fail to received detailed estimates
#9 - Agile increases potential threats to business continuity and knowledge transfer. By nature, Agile projects are extremely light on documentation because the team focuses on verbal communication with the customer rather than on documents or manuals. As a result, a switch of a single team member, much less an entire development team, away from one product and over to another can significantly impact the organization’s ability to maintain and improve that product. Much of the knowledge resides in the team’s head and is gone when they are.
# 10 - Agile lacks the attention to outside integration. Both large software development projects and small projects in large environments require multiple points of integration with other systems in their universe, such as sharing data with a downstream system (from order processing to accounting) or retrieving data from another system (such as inventory quantities to order processing).
CONCLUSION
In most cases, these integration points need to be identified early, then they need to be clearly defined so that both sides can develop the two software components to work well together. The problem is worsened with third-party integration, when another business needs to integrate with you or you need to integrate with them. In these cases, contracts and service level agreements come in to play, requiring lawyers, approvals and frequent meetings before the first line of code is written, pushing the total completion time up by 2 to 10 times.
Because Agile teams often do not invest the time in identifying and designing the integration points with other systems in advance, the need for an integration point can become a last-minute surprise that often requires re-work, additional time, removal from scope, or a poor-quality product. For many of us, none of these options are acceptable, which explains the weakness of Agile in this area.
With all the strengths of Agile methodologies, these ten weaknesses can (and should) prevent some businesses from adopting Agile in its most common form. While Agile is very popular with consultants, IT journals and on the Internet, it’s not well suited for every business and every project.