Scrum in software development: agile and structured

Scrum is an agile form of collaboration that relies on flexibility and self-organization of the team. There is an official Scrum Guide for its application, which proposes precise rules and actions.

Although many people refer to Scrum as an agile development method, it is actually a "framework", a process model used in product management and project management. According to Scrum, development is organized into iterations called sprints. The sprints give the team a rhythm through their regular length.

At Projektron, we have four Scrum roles: Development Team, Scrum Master, Product Owner and Chief Product Owner.

1. The Development Team (Dev Team) consists mostly of developers.
2. In addition, each team has its own Scrum Master. The Scrum Master acts as a kind of moderator in the team and makes sure that the collaboration runs smoothly. For example, he procures resources, helps the team with problems and is the contact person for outsiders.
3. The product owners represent the interests of the customer and are the contact person for other stakeholders. They collect customer requests, prioritize them and pass them on to the dev team.

A Scrum team should have five to nine members. With more people, organization and communication become very costly. With fewer people, you will hardly find all the required competencies in the team.

There are recurring activities that are scheduled as regular appointments.

1. First, there is the sprint - a fixed time interval of one to four weeks in which the team works on user stories. User stories reflect the new requirements requests of the customers.
2. The teams then take a break, the intermediate sprint. Only then do they start the next sprint. During this time, the teams work on bug tickets, plan the next sprint and carry out sprint-independent things (e.g. staff meetings).
3. Each Sprint starts with a Planning. The purpose of this meeting is for the product owner to present the user stories planned for the sprint to the developers, to clarify questions of understanding and to make the sprint goal clear. After planning, the developers then work for two weeks on the implementation of the user stories planned for the sprint. Depending on the capacity of the developers (vacation, deadlines, etc.), the implementation volume varies from sprint to sprint.
4. Within the Sprint, there is a short meeting of about 15 minutes every day, the Daily Scrum. Here, each developer is invited to present a short update of his work to his colleagues: Where am I right now? What difficulties have I overcome? What challenges am I facing? Where do I need help?
5. At the end of the sprint, the implementing team presents its achieved work results in the demo. All product owners involved in the user stories appear at this meeting. If necessary, developers who are affected by the impact join them. This appointment offers the developers a stage to present their performance in the past Sprint and invites the exchange and feedback of all participants. The demo also shows whether the sprint goal has been achieved or whether rework may still be necessary.

Finally, the sprint ends with a retrospective. The sprint team meets to reflect on the collaboration and to make agreements for future sprints. The retrospective is not about the results of the work, but primarily about the work process.

In addition to the roles and the activities, there are three process documents in Scrum - the Scrum artifacts:

1. The Product Backlog is the overall list of all User Stories (requirements) to be realized for the product.
2. The Sprint Backlog is the list of all User Stories that are to be processed within a Sprint.
3. The increment is a potentially deliverable partial result at the end of a sprint. The decision about its delivery is at the discretion of the product owner.

The basis for the acceptance of the user stories at the end of the sprint in the demo is the Definition of Done (DoD). All points of the Definition of Done must be fulfilled for a User Story to be finished, i.e. implemented completely and ready for release. For the Sprint Demo it is only allowed to present finished User Stories. The following criteria are usually included in the Definition of Done:

• Build, Deploy, Download ready
• Runnable installation routine
• Runnable Projektron BCS server
• Side effects checked
• Code review according to the 4-eyes principle
• Acceptance by developers themselves
• Unit tests implemented and run through
• Function tested according to the 4-eyes principle
• Code conforms to conventions (no warnings)
• Architecture
• Code is documented
• Branches maintain
• Configuration standard/custom
• Custom-compatible
• Backward-compatible

The hype around Scrum in software development was followed by a popularity trend of Scrum in agile project management that continues to this day. This hype quickly makes one forget that Scrum may bring undeniable advantages, but also some disadvantages. Only those who know the potential pitfalls and traps can make appropriate adjustments at an early stage. Let's dare to take stock!

Scrum offers a number of advantages for software development. By using short sprints and regular meetings, Scrum enables continuous adaptation to changing requirements. This is a key advantage in an industry characterized by rapid change and technological advancement. The development team can respond quickly to feedback and make changes to ensure the final product meets the customer's needs. This avoids investing valuable resources in developing features that end up not being needed or do not add the desired value.

Another significant benefit of Scrum is that it encourages collaboration and communication within the team. The different roles and meetings in Scrum ensure that all team members are on the same page and develop a common understanding of the goals and requirements. The product owner, scrum master, and development team work closely together to ensure that the project is successfully delivered. This close collaboration minimizes misunderstandings and miscommunication and contributes to the efficiency of the team. Through the constant exchange of information and open communication, problems can be identified and solved at an early stage.

Another advantage of the Scrum framework is the transparency of the development process. Through regular meetings and the use of visual artifacts such as the sprint backlog and the product backlog, everyone involved has a clear overview of the progress of the project. Everyone can see which tasks have been completed, which are still pending, and what the current status of the project is. This makes it possible to identify bottlenecks or delays early on and take action to get the project back on track. Transparency also fosters trust between the development team, the product owner, and other stakeholders, as everyone understands the progress and challenges of the project.

A finite time frame, as given in Scrum by the sprints, can lead to not covering all aspects of a project sufficiently. While a sprint covers certain elements and tasks, other important aspects of the project may be neglected. As a result, there is a risk that the final product will not meet all of the desired functions or requirements.

Another disadvantage of Scrum is its limited scalability. Scrum was originally developed for smaller teams and can reach its limits in larger projects or in large companies. Communication and coordination between team members can become more difficult as the team grows larger. As a result, information can be lost or misunderstandings can occur, negatively impacting the effectiveness of the team.

Dependence on a well-functioning team is another critical aspect of Scrum. The methodology requires that all team members work well together and perform their tasks effectively. However, if one team member fails or is unable to contribute, it can affect the overall team performance.

The strong focus on the sprint goals can lead to other important events or tasks being disregarded. The team is so focused on achieving the sprint goal that other urgent requirements or customer expectations are not fully considered. This can lead to bottlenecks or even delays in other areas that affect the overall state of the project.

Another disadvantage of Scrum is the possible incompleteness of the product documentation. Since Scrum places particular emphasis on actual development, there is a risk that an important piece of information, event or decision may not be adequately documented. This can lead to problems if the team or other stakeholders need to access this information in the future.

Backlog entries can also be a problem. If product requirements are not clearly defined or prioritized, this can lead to confusion and reduce the effectiveness of the team. If important elements in the backlog are missing or not clearly described, this can lead to uncertainty and misunderstanding.

Finally, Scrum requires a good knowledge and application of the methodology. If team members or stakeholders are not sufficiently familiar with Scrum, difficulties can arise. Proper implementation of Scrum elements and practices requires training and some time to become familiar with the methodology.

We made the decision to introduce Scrum in order to achieve higher satisfaction in development. In December 2009, we established Scrum as a way of doing things in software development. In contrast to other companies that usually introduce Scrum to work in a more agile way, we at Projektron established Scrum in software development to work in a more structured way.

The need for this arose from the previously prevailing unstructured approach: Account managers requested developers of their choice when they felt like it and asked them to quickly implement requests from their customers and support tickets. Sales staff promised on-site adjustments to the software during customer meetings, which developers now had to quickly bring into the next release. Customer complaints were hastily translated into customization requests.

In this way, it was often not clear

• what the next release should contain,
• whether further implementation requests would be received in the short term,
• how long it would take until the release could be made,
• what other requirements (apart from those of the specific customer) the enhancement would also have to meet, and
• how the customization or enhancement would be tested.

No process existed at the time Scrum was introduced to ensure that all new software enhancements were included in the documentation and made known to the customers.

So the most important goals at our company were:

• fixed dates for releases and shorter duration until the next release date
• Transparency regarding the contents of the next release
• bundled requirements of as many customers as possible for enhancements through a product manager role (which did not exist directly before)
• significantly more effort and planning for tests
• complete documentation
• protection of developers from interference by sales people and consultants.

Currently, three Scrum teams are working on the development of Projektron BCS in-house at our headquarters in Berlin. Each team works in two-week sprints, which start one week apart. The sprint is followed by the intermediate sprint, staggered for each team, which is intended to provide time for further training, support and troubleshooting.

If we look at the entire sprint scheme, it becomes clear that there are always two teams in the sprint and one team in the intermediate sprint per week. After a total of twelve sprints, a product release is made. In this way, we ensure a continuous production rhythm without overloading our development or neglecting the necessary view of the bigger picture, including customer contact.

We introduced Scrum as a process model in software development at Projektron in December 2009. To do this, we did not simply adopt the standard Scrum procedure according to a standardized template, but rather we successively adapted it to our specific requirements.

Four major adjustments were as follows:

1. We split the role of the Product Owner: There are now over 20 domain product owners (DPOs) who are responsible for specific domain-specific features.
2. In addition, there is a three-person core product team and a Chief Product Owner (CPO), who sets the strategic direction and prioritization. The CPO therefore already existed at Projektron before it became part of the Scrum doctrine.
3. We use three women from the Marketing and Documentation departments as Scrum Masters. Since they are not developers, they do not contribute their own professional thoughts on technical issues and remain neutral in the internal discourse. And since they are not consultants, they are not tempted to push solutions for their own customers. At the same time, they bring fresh motivation from the outside into the development teams on a daily basis. Since Scrum teams are still heavily male-dominated, we are thus deliberately breaking down structures and stereotypes and creating an incentive for female developers to join our teams.
4. The planningwas divided into two meetings. In the second meeting, the development team discusses the user stories in detail without the presence of the product owner.
5. Every Monday afternoon, two hours are reserved for all developers to estimate efforts for internal and external requirements.
6. The intermediate sprint lasts one week at Projektron. During this time, the developers of one team each provide competent 3rd-level support. The other two teams can continue their concentrated work at the same time.

Overall, Scrum is proving to be a flexible and effective method in our software development to develop a high-quality software product like Projektron BCS. By fostering collaboration, communication and transparency, Scrum enables our teams to continuously improve and meet customer requirements.

Are we content with this status quo? Of course not. We are continuously optimizing our processes and procedures. In addition, further far-reaching changes and enhancements are in the pipeline. Currently, the following tasks are on the agenda:

• The three existing Scrum teams are to be expanded to include a fourth development team.
• Each team is to specialize step by step in certain areas and aspects of development.
• Our own project management software is to provide even better support for long-term release planning.