1. Executing Iteratively, but Delivering Waterfall
An attribute of agile methods is that project scope is delivered regularly over the project lifetime. Some organizations might structure their projects into a set of iterations, but do not deliver customer usable products as an outcome of these iterations (documentation is usually not considered a true business value deliverable). This limits a customer’s ability to refine or reprioritize remaining work items and can incur opportunity costs if the project team continues to enhance certain “in progress” deliverables which the customer might have considered good enough. A variant on this issue is a project team that delivers frequently, but the customer insists on waiting till the end of the project instead of evaluating whether their business needs have been sufficiently met.
2. Insufficient Involvement of the Customer
Agile methods work best when the distance between the customer and the project team is reduced so that refining and prioritizing the work item backlog, decision making and deliverables review can occur in a timely fashion. This can require a significant commitment of effort on the part of the customer but selling the necessity for this involvement is preferable to accepting the risks associated with compromises such as having a project team member act as a proxy for the real customer.
3. Multitasking Impacts both Velocity and Team Cohesion
Excessive multi-tasking hurts projects, regardless of their delivery approach. However, it can be lethal for agile projects as the context switching and knowledge gaps that result will reduce productivity, introduce quality issues and make it difficult to predictably calculate or use delivery velocity. These outcomes can cause organizations to lose faith in their agile initiatives and revert to more traditional approaches without understanding that the issue is not one of methodology
4. Agile does not Imply “just do it”
Contradictory to the manager’s doctrine from this Dilbert cartoon (http://www.dilbert.com/fast/2007-11-26/), planning is not wholly replaced by execution in agile projects. While the depth of planning is inversely related to the “nearness” of an activity or decision, a lack of pragmatic, right-sized planning will result in chaos for any project. This is a part of the agile transition change management process – learning to strike the right balance between too much and too little planning.
Adopting agile approaches can be a positive step towards increasing business value realization and project throughput, but ignoring the potholes along the journey will give your transformation initiative a flat tire!
Don’t forget to leave your comments below