Nowadays it is important to minimise the time span required for a new software to be introduced to the market. Notably, SAP projects are far too complex for producing an all-encompassing performance specification.
When developing a product according to a classic mode of operation, months or even years go by before a specification is complete. Even after completion this can still reveal gaps and areas needing greater clarity.
Yet even with a concept free of gaps, up to the market introduction the danger exists that, for several months (or years!), the product is developed beyond the market or respectively beyond your customers’ requirements.
Thus the main flaws of classic software development are:
- development steps taken are too big – if the project fails or goes off into the wrong direction, this is often noticed much too late
- Silo-thinking – the subject-specialist department and the development department scarcely have any direct contact
- Losses of efficiency – bureaucracy and the administrative workload obstruct productivity
- Communication problems – misunderstandings or unclear requirements are noticed too late
The cause for these problems lies in the models themselves that define how to proceed; they are too inflexible and bureaucratic, unnecessarily strapping the whole team into a tight corset of constraints.
This restricts agility and errors take too long to get noticed.
In Scrum, alongside the product, the planning is also developed on an iterative and incremental basis. As a result, viable interim results (product increments) emerge that can be presented to the customer / the specialist department, at an early stage.
This transparency means that requirements that are unstated or are misunderstood become visible quickly; they can be taken into account in the next iteration (known as a ‘Sprint’).
The development process in Scrum
Scrum is based on a very simple process. Only three roles are involved in a scrum process. The Product Owner submits the subject-specialist requirements, the Scrum Master’s role corresponds to that of a project manager, and the scrum team develops the product.
Product Backlog
In the Product Backlog the requirements are cultivated, extended and prioritised. Unlike the classic approach, with a (customer’s) requirements specification and then the (supplier’s) performance specification, the Product Backlog is changed when the requirement arises.
That way, new insights or the facts of a new situation can flow directly into the new product development.
The Product Backlog serves as the only source of requirements for all changes made to the product. It lists all features, functionalities, improvements and error eliminations that comprise the changes to the product, indicated in releases at later dates.
It undergoes an ongoing development with the product and its use, rather than being a rigid structure like a performance specification.
Sprint Backlog
At firmly-defined and regular intervals, a work package, the so-called ‘increment’, is defined from the Product Backlogs. The increment is worked-through during the sprint, the core element of the scrum methodology.
The Sprint Backlog is the quantity of the product-backlog entries selected for the sprint. The Sprint Backlog makes visible the whole body of work that the project team must work through to reach the sprint goal.
The Sprint
At the heart of Scrum is the Sprint, a time period of one month maximum, within which a product increment is produced – one that is ready, usable and can potentially be presented to the customer.
The increment is worked through during the sprint. For this purpose, the increment is divided into smaller work packages – the so-called ‘tasks’ – allocated to a specific person for processing, and the workload involved is estimated.
A task can acquire a status that is established by the team, e.g. ‘To do’, ‘Work in progress’ and ‘Completed’. During a sprint, all tasks are noted on Post-Its and attached to a pin-board, the so-called ‘ScrumBoard’.
For instance, this ScrumBoard is divided into the three columns – ‘To do’, ‘Work in progress’ and ‘Completed’. Each team or team-member characterises the level of progress in the work, by allocating the respective written note to the correct status on the pin-board.
In a daily 15-minute meeting, the so-called ‘daily scrum’, the project team coordinates its activities for the next 24 hours. In this, each team member answers three questions: What have I done since the last daily scrum? What am I planning to do before the next daily scrum? What elements acted as impediments in my work?
Checking progress towards a given goal
At the end of the sprint, the so-called ‘sprint review meeting’, the team presents the result, the feedback flows into the planning of the coming sprints, and the whole process begins anew. Through this iterative approach, you can more quickly identify requirements that are missing and more efficiently define approaches to solutions.
ScrumBoards are pinned up on a wall in an office and are thus not very mobile or flexible.
Especially in SAP projects, usually so many people are involved that they do not all fit into one office; in other instances, the facilities available in terms of space do not offer scope for a dedicated team area.
There are also logistical difficulties involved as a result of components sourced by nearshoring or offshoring their supply. Similarly, in the stakeholder meeting, a whiteboard proves to be a hard-to-manage instrument, far from practical for presenting the current state of affairs.
Backlog and burn-down are often administered in Excel lists, and the project progress is likewise administered manually in an Excel list, so as to be able to produce a burn-down chart.
Electronic alternative
Electronic ScrumBoards offer a purposeful alternative here – they bring together the whole scrum process in one application and each team member has access to it at any time.
‘Electronic Post-Its’ do not lose their stickiness and the pin-board can be used again as precisely that. If the physical facilities available provide scope for a team room, you can also present the electronic ScrumBoard on a (touch-operated) TV or screen for all team members.
Scrum in SAP
However, in an SAP project these electronic ScrumBoards have the disadvantage that there is no integration into the SAP system.
To make the best possible use of the scrum methodology, the bsc ScrumBoard for integrated SAP development projects introduces very significantly increased efficiency to your team.
By using the modern UI5 framework, our ScrumBoard makes a powerful case for itself, with the modern and intuitively-operable design of its user-interface. It can be easily operated using drag-and-drop, enabling your team members to fulfil their tasks in a faster and more concentrated way.
Status-checking operations do not need to dispense with key, up-to-date information.
The digital ScrumBoard supports you and your team in all their daily activities and in moving status forward on parallel projects, in allocating and administering new tasks and in many other operations, without additions that confuse or distract employees on their way to infrastructure transformation.
Add Comment