Agile Software Development

Risk analysis in traditional software development projects is often performed for real only before getting the financing and actually starting work. After the project ends there are often the "lessons learned" sessions, which in case of a failure are called postmortems. During these pre-project and post-project risk analysis activities an attempt is being made to reduce the risks and maximize the probability of success. The recent addition to this collection of methods is the idea of a premortem that is a risks review that happens before the project start as if the projects has failed already. While all the pre- and post-project risk analysis techniques are indeed useful and can help organization to improve own practices, they only look at the potential problems at only two moments of time. Therefore there is always a danger of missing the important factors that either did not exist at the point of analysis or team members did not have enough information about those.

Agile software development methodologies discourage the use of the fixed price contracts. When forced to commit to the fixed price, agile approaches advocate unfixing the project scope. However, even if it is impossible, there are still ways to realize the benefits of agile methods.

Poorly predictable complexities

Sydney opera house, a beautiful piece of art, the Sydney's best known landmark and international symbol was started as a fixed-price, fixed-date project. Unfortunately, since it was no standard building time, it was impossible to estimate all the difficulties and complexities in advance. As a result, it took 13 years and 102 million Australian dollars to build instead of 3 year and 7 million estimated - 330% time overrun and 1350% costs overrun!

Agile software development methods are sometimes criticized for the inability to rely on. Agile project managers are unable to produce the fixed upfront effort-time-costs estimation. Sometimes it is even the core argument of the waterfall process proponents.

In fact agile manifesto principles "Customer collaboration over contract negotiation" and "Responding to change over following a plan" do not state that contracts and plans are useless. Agile community recognizes the value of contracts and plans, it is just so, that the agile developers value collaboration and responding to change more. If there is a possibility to create the upfront time and costs estimation, the agile team

Most if not all of the agile software development processes are based on the assumption that it is hardly possible or not possible at all to predict the real requirements and real workload size at the beginning on the project. The whole idea of agility is to try implementing the most critical stuff, see how it goes, get customer feedback and adjust the close plans.

Such limitation of the upfront planning minimizes the amount of time wasted on never used overplanning and on developing features, that after later consideration happen to be wrongly understood or unnecessary at all. Also the detailed plan non-existence welcomes changes easier. If there are no planning results to modify, there is no temptation to just follow the obsolete plans.

Measurement is fundamental to any engineering discipline and the planning of a software creation work is no different. Whenever you plan to make or renew a piece of software the most important metric as the workload size. Measure of size is important because knowing the amount of work to do and the team skills (i.e. velocity) you can easily derive the work costs and duration. Agile software development methods do strive against the overplanning and overdetalization