Agile methods originated in software development, and are widely used in a number of very mature, market leading technology companies. However, these approaches are an ideal way to start the process of introducing discipline into organizations that are at a very low level of project maturity.
At its most basic, an agile project only has three prerequisites:
1. A customer that is able to communicate some idea of what the desired end state is, and is willing to help define & prioritize requirements. The customer should also have some idea on how much they are willing to spend and how long they are willing to wait to receive the desired outcomes. One could be even more minimalist and start an agile project without having some firm idea of budget or schedule constraints, but this could tend to transform the project into a never-ending operational activity!
2. A project leader that is willing to remove more obstacles from the team’s path than he/she places in front of them, and is able to facilitate customer’s scope refinement & prioritization through the team.
3. A team that is somewhat motivated and partially available to work on the project. This might seem like a very pessimistic view of the world, but with the exception of true “projectized” companies, it is very rare to find team members that are 100% available to work on a single project, and with these competing demands on their time, it is unlikely that the team as a whole would be 100% motivated to work on any individual project.
As most “just do it” companies can still see some benefit of “to do” lists, the typical agile work backlog list should be a much easier sell than a detailed functional specification or scope definition document. So long as the customer and project team can group and prioritize the work items using some logical process, and the customer can provide some idea as to what would make for a “meaningful” deliverable at the end of each iteration (or set of iterations), very little else is necessary to completing the project. The project leader can use progress on the backlog relative to time and effort expended as a means of estimating velocity, and the regular re-prioritization of items in the backlog will ensure that the outcomes are what the customer wants. Once the customer is sufficiently happy with what has been delivered, they can hit the Stop button.
This is not to say that both efficiency and predictability would not be gained through introduction of more traditional project management methods and documents such as schedules, financial forecasts, risk registers and formal communication plans , but the change magnitude and effort required to convince key stakeholders of the value in creating and maintaining these might be insurmountable challenges in a truly low maturity company.
By focusing on customers’ priorities and making them responsible for key project decisions, agile methods can kick-start the capability maturation process. Once success has been demonstrated on the initial projects that used these methods, the happy customers should hopefully be more amenable to acting as true champions for gradual capability improvement.