Because of close cooperation between business, IT and suppliers the chance of derailment in agile software realization became less, and the success rate of software realization projects improved in recent years. This is evident from a survey published in the Chaos report of the Standish Group. Despite the increased percentage of successful projects a significant percentage of agile development projects get into trouble: 45% of the agile projects end in the trouble zone and 12% of the projects fail.
Large agile projects are risky as well
One of the most important failure factors is complexity. Also in agile the size has a negative impact on the chance of success. Larger projects are still risky and close progress monitoring is an absolute must. Grip on an agile project is just not easy because of the key principles in this development method. Indeed, the product owner in collaboration with the client and the business, prioritizes functionality to be worked out in the form of user stories in a product backlog. The scrum master and the members of the scrum team determine independently how and when they take the prioritized backlog items in the various sprints and develop the user stories in the software. This way a realistic work schedule is guaranteed and the team has ultimate commitment to achieve the set short-term goals.
Also in an agile development approach, you want to control the progress and not lose sight of the dot on the horizon around the roadmap, budget, quality and deadline. The scrum team uses story points in most cases as a measure of the effort it takes to develop a user story in the software. For the team, it is an excellent way of working and performance IDC Metrics based on story points such as velocity are very useful on team level. The story point approach however is not a standardized and objective method to measure size and therefore not suitable to get a grip on the functional size, the project cost and processing time. On tactical and strategic contract level, it is important to use additional performance indicators for productivity and quality of software development, standardized and based on best practices. The collection and analysis of this information also provides the possibility to capture empirical data around project- and program management, to benchmark and to compare the suppliers’ performance to the industry. Data-driven process improvement can bring software realization projects in the organization to the next level and increase team predictability.
Story Points and Function Points
Story points may be valuable in the context of specific teams, IDC Metrics based on story points are not suitable to get a grip on the functional size, effort, cost, duration and quality of software development. Standardized function point analysis can offer this basis, because it is a measure for the functional size independent from the technical solution. This method, developed by IBM in the seventies, is available in the form of an ISO / IEC standard and it is well applicable for monitoring the realization of transaction processing systems like, for example, ERP systems or policy processing systems. This method enables organizations to measure the functional size of software, just like the wall surface is still measured in square meters, even if the walls are built from all kinds of new materials. Grip on the Progress With function point analysis, you can determine the output in a standardized unit of measure and then it becomes possible to calculate productivity of software development in an objective, repeatable and verifiable way, by combining the processed function points with the hours worked. With a specific variant of function point analysis, it is possible early in the budget process to make a pretty accurate estimate of the size. By measuring requirements in user stories in the backlog, an accurate estimation can be made about when certain functionality will be completed given the size of the application and the development team. It also provides practical insight at an early stage if the minimum required functionality (minimal viable scope) will be in time available or that actions may be required.
Function points were ostracized by many in the past, because this method would require detailed documentation of the software and would be impractical in practice, especially in agile teams. That classification is unjustified, because a function point analysis is relatively simple to perform in practice. Moreover, new developments, such as automated function points measurement based on delivered software code, provided this method with new added value. This way, the impact of the measurement on the scrum team remains low, while the product owner and the stakeholders have adequate instruments at their disposal.
From the customer side, intelligent measurement of the functional size offers the ability to manage potential risks in large software realization projects. Relevant KPIs provide insight into the productivity of software development, the duration, the structural quality of the software code and the costs. These are excellent tools to control the progress of scrum teams and to serve as input if the quality and progress of suppliers must be addressed. This method can also reveal potential risks that can lead to serious problems later in the life cycle, like for example, possible issues with the security or performance issues with the software.
IDC METRI has entered a partnership with CAST software to run automated function point and code quality measurements in the form of a continuous Supplier Performance Measurement service. Besides information on productivity and market conformity of cost, organizations also gain detailed insight into the structural quality of the produced source code. In this way, agile teams can be compared with the performance IDC Metrics in the market. Budget Owners get control over their sourcing in the application domain so that they can address the risks associated with software development with highly relevant parameters.