Optimal control and cost-effectiveness with properly adjusted parameters
With the agile and lightweight development method Scrum, large software projects are more manageable with respect to functionality, project duration and quality. In practice, however, this will only succeed if the basic parameters are set in a well thought-out manner. Among other things, optimal sprint length and team size, as well as the balance between functionality and quality, are of decisive importance.
IT PROJECT MANAGEMENT WITH SCRUM – QUICKER BENEFITS, ONGOING STATUS REVIEW AND CLEVER STAKEHOLDER MANAGEMENT
In recent years, agile methods for organising and controlling software development processes have gained hugely in importance. Among the various approaches, especially Scrum is growing in popularity. The reason for the increasing prevalence of this extremely slim framework is that, when using traditional methods, even very extensive planning is often unable to improve management security. While traditional approaches such as the waterfall model rely on a detailed master plan, factors such as self-organisation, direct and rapid generation of benefits, continuous status checking and adaptation, as well as the ongoing involvement of both users and clients are foregrounded with Scrum (see Fig. 1).
Figure 1: Scrum process overview
Yet, although long concept phases as well as detailed product and requirement specifications are missing, Scrum is anything but haphazard: The framework stipulates a fixed set of rules along with well-defined roles and a clear and flexible workflow that is repeated cyclically. The Scrum framework owes its popularity primarily to its impressive simplicity. However, quick and easy as it may be to learn and apply the principles of the framework, especially for complex projects it is critical to correctly set a number of important parameters.
IT PROJECT MANAGEMENT WITH SCRUM – CUSTOMISING SPRINT LENGTH IMPROVES QUALITY AND FLEXIBILITY
At the heart of Scrum is the self-organising project team, which, in close consultation with the client, or product owner, implements the sub-tasks at pre-established time intervals. The aim of these so-called sprints is to generate executable functions or modules. Scrum recommends a sprint length of one to four weeks. Particularly in large and complex software projects, however, there is a tendency towards the maximum sprint length. This may allow sufficient time buffers to be scheduled, but frequently undoes the greatest advantage of Scrum, namely its flexibility: The feedback loops grow larger, as do the response times. Furthermore, to eliminate errors, the team members repeatedly have to work their way back into older topics. New requirements or priorities, which are prone to change at short intervals in large-scale projects, can also cause delays. Subsequently, forward-looking and, above all, reliable planning becomes increasingly difficult. In the case of short change management cycles, a sprint length of only two weeks, for example, is therefore highly advisable. It allows obstacles as well as changes by individual stakeholders to be taken into account at an earlier stage. Moreover, it forces both the product owner and the team to focus on the current target.
IT PROJECT MANAGEMENT WITH SCRUM – TEAM SIZE IS THE CRITICAL SUCCESS FACTOR
Team size is another key success factor. The framework stipulates a team of no more than nine members, always coming from different disciplines so that all technical requirements can be dealt with autonomously. If the team is too small, it often lacks the expertise required to implement all tasks in an optimal manner. However, if the team size exceeds the recommended maximum, communication problems become virtually unavoidable. The individual members are no longer able to communicate with each other in sufficient detail, and the decision-making process begins to stretch out. Accordingly, there is also the risk of losing focus on the respective iteration targets.
IT PROJECT MANAGEMENT WITH SCRUM – DEFINING THE TRADE-OFF BETWEEN FUNCTION RANGE AND QUALITY
Budget constraints, ever shorter time-to-market cycles and technical complexity form an everyday part of development projects. They inevitably contribute to the tension between functionality and quality. This often leads to power struggles between the product owner, who demands the immediate implementation of new features or requirements, and the development team, which usually wants to deliver a high-quality product that corresponds to the so-called ‘definitions of done’. If new functionality, in the form of prototypes and geared only towards short-term benefits, is added to a system, then what is known as technical debt begins to accumulate: Over time, imperfect software design, inadequate or no testing, unclean code or inadvertent complexity results in a more and more unstable system that in the worst case can bring all further development to a halt. This dilemma can only be resolved if all parties involved come to realise that short-term implementation strategies will not accelerate a development project. Experience shows that sooner or later, the technical debt – plus interest – will have to be paid back in order to obtain a clean, expandable and maintainable system.