This case study describes the change of the classic release management process in a major Central European bank towards an agile approach with iterative development and cyclical delivery of new software.
Initial situation
In the past, the Bank’s release management process was characterised by medium-term planning using classical project management.
The entire concrete content of new development projects was broken down into individual requirements in advance and defined in detail in terms of scope and effort in the form of classic projects right from the start.
The formulation of the requirements and their coordination with the teams involved often led to time difficulties at the beginning of the project and ultimately to delays.
In the spirit of the waterfall model, the work packages were then described on the basis of the detailed requirements, deadlines derived, concrete resources planned and implemented according to plan. The list of requirements, the deadline and the costs were therefore fixed at the beginning. The department then had to wait several months for the finished release.
Defects or features that had not been developed for the customer’s benefit were thus identified very late, often only after the software had been delivered. Changes were therefore only possible in subsequent releases.
Risks due to long-term nature
The risk in the project and for the business was equally high. At no time were the project managers sure that they would be able to deliver the software in the required time, quality and planned costs.
To day in advance.
Although the department was not responsible for meeting the schedules, it was always exposed to the risk of delays, quality defects and budget overruns.
New status quo
The release management process in an agile context is very different at the bank today than it was just a few years ago:
At the beginning, a rough roadmap (temporal classification of the delivery packages) is defined with milestones and roughly formulated feature packages, but without making any concrete promises.
Such a roadmap serves as orientation and to coordinate expectations. The planning of the costs for this is then based on a very rough estimate, with the aim of reserving resources and a budget for it in the medium term. It is no longer the content that is fixed as the central benchmark, but rather a team is reserved and a timeframe set in which the content is gradually implemented according to its importance for the business.
One example of the level of detail of such a feature package in the bank’s roadmap is the video identification of new customers via the company’s website, which many banks already use today to open their accounts online. The customer no longer has to go to the bank branch, but can deposit a photo of his ID online and then be identified by the bank’s service staff via video conferencing. It’s not a matter of detail yet, but of understanding the big “pieces”.
The feature packages are then broken down into individual user stories – only as many as can actually be implemented in the following sprint (one development cycle) according to the assessment of the development team.
And only these user stories are defined in detail with regard to purpose, quality requirements, user and result description.
This significantly reduces the scope and complexity of planning at the beginning and the implementation of the most important new features can be started much earlier.
The current status of the software is presented to the customer or the internal business partner at the end of the sprint. Quality defects, short-term requests for improvements or other changes are immediately taken into account in the next sprint of the same release. This makes it possible to react and correct much more quickly, which makes cooperation much easier.
Risk in the agile model
The risk in such an agile model is significantly reduced for all parties involved. The assessment of the features and the user stories derived from them now takes place over a period of 2-4 weeks, depending on the team and product.
The project or Scrum team can now make much more precise statements about the delivery status of the software at short notice. The medium-term plan remains variable until it is defined and fixed for concrete implementation.
This takes place at short notice, which is why it is now much easier to react to short-term market requirements. The development teams and business partners are in a constant exchange. Errors or developments that have passed the customer’s expectations can therefore be directly
can be considered or corrected in the next sprint.
What has changed in relation to planning horizons?
If working in short cycles reduces the risk for the decision-makers involved due to the rapid visibility of results, issues such as “protection” against errors and the associated effort are significantly reduced. So you can quickly see results, learn from them and correct mistakes long before they can have a negative impact on your business.
Where in the past you had to come to terms with long-term planning and fixed objectives, the internal customer can now concentrate on the things that you know concretely and need now. You can implement new features for the market at shorter intervals and use long-term planning and long-term objectives to roughly coordinate strategies across the organization. However, medium- and long-term planning must (and can) now be continuously adjusted.
In this specific case, even individual board members regularly go to project teams to inform themselves informally about the development status. It is not a matter of receiving a steering committee presentation, but of receiving reports on the condition of the product in an uncomplicated environment and possibly stimulating priority changes for product development right there.
Who would have expected this just a few years ago in such a large company?
Recent Comments