Scrum in software development: agile and structured
When it comes to agile methods of software development, you can't avoid one term: Scrum. But what is Scrum actually and how does it unfold its strengths in software development? What roles and what activities are there in Scrum? What are the advantages and disadvantages of this agile framework? You will learn all this in this article. In addition, we provide an insight into our agile Scrum variant, which we successfully use to develop Projektron BCS.
What is Scrum actually?
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.
What are the roles in Scrum?
At Projektron, we have four Scrum roles: Development Team, Scrum Master, Product Owner and Chief Product Owner.
- The Development Team (Dev Team) consists mostly of developers.
- 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.
- 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.
What are the activities in Scrum?
There are recurring activities that are scheduled as regular appointments.
- 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.
- 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).
- 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.
- 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?
- 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.
Where does the name "Scrum" come from?
The name Scrum is derived from a play in rugby and can be translated as "scrum". Jeff Sutherland and Ken Schwaber adopted the rugby approach from IT. They renamed their newly developed framework in the early 1990s Scrum in reference to the original name. The Rugby Approach was originally defined by the two Japanese economists Hirotaka Takeuchi and Ikujiro Nonaka in 1986 as a procedure in Lean Management.
What are the artifacts in Scrum?
In addition to the roles and the activities, there are three process documents in Scrum - the Scrum artifacts:
- The Product Backlog is the overall list of all User Stories (requirements) to be realized for the product.
- The Sprint Backlog is the list of all User Stories that are to be processed within a Sprint.
- 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.
How does quality assurance work in Scrum?
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)
- Code is documented
- Branches maintain
- Configuration standard/custom
Advantages and disadvantages of Scrum
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!
Advantages of Scrum
Scrum in software development...
- can be introduced quickly thanks to a narrow set of rules.
- can be easily adapted and adjusted to your individual requirements.
- quickly delivers first results in case of unclear overall requirements.
- favors quick reaction to short-term changes in requirements.
- allows you to interrupt ongoing development at short notice.
- enables developers to quickly switch to other teams and between different issues.
- promotes an intensive communication culture with short communication paths.
- enables the testing of new techniques with relatively low risk (termination after a sprint is possible).
- causes a low administration and documentation effort.
Disadvantages of Scrum
Danger recognized, danger averted. Therefore, keep the following weaknesses in mind: Scrum in software development...
- sometimes neglects non-product or sprint-specific issues of a general nature regarding architecture, user interface (GUI), performance and system environment.
- can quickly disconnect development teams from overall company goals and issues.
- involves the risk that risks in the planning are only identified during the already started realization.
- requires a high degree of communicative and other soft skills because of the high communication and coordination effort.
- demands a high level of commitment and initiative from developers, as there are few concrete recommendations for action and there are no hierarchies.
Structure trumps agility: That's why we use Scrum at Projektron
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.
Agile software development according to Scum: Example Projektron
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.
Each team reports to a Scrum master from the areas of documentation, marketing and personnel. Marketing and documentation thus remain constantly informed about the current progress of product development and communicate new developments and adjustments immediately and directly to customers and interested parties.
- more than 20 domain product owners
- a core product management team
- a Chief Product Owner
Customized: This distinguishes Scrum at Projektron from standard Scrum
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:
- 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.
- 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.
- 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.
- 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.
- Every Monday afternoon, two hours are reserved for all developers to estimate efforts for internal and external requirements.
- 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.
The biggest adjustment had a very positive impact on the functionalities of our software. We initially started by writing down the sprint status analogously on slips of paper. After only two months, it was clear: We had to move the representation to our Projektron BCS software. Projektron BCS has long since supported the Daily Scrum with a task overview that can be flexibly adapted to our needs and yours as well. BCS graphically displays sprint status and sprint progress as a burndown chart with a cumulative flow diagram.
In addition, we made further adjustments to Scrum, but have since abolished them again. They simply proved not to be practical for our individual needs. At the beginning, for example, two developers did not participate in the sprint in order to provide support, and the Scrum Master was also the developer of the only team at the time.
Today, all developers, grouped into three teams, participate in the sprint. The roles of Scrum Master are not filled with developers, but with people who simultaneously serve the interface between development, marketing, documentation and support.
Agile towards the future with Scrum: Outlook
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 on the horizon. Currently, we are planning the following:
- The three existing teams are to be expanded to include a fourth.
- Each team is to specialize in certain areas and aspects of development.
- Our own project management software is to provide even better support for long-term release planning.
About the author
Development at Projektron has been relying on software development according to Scrum for many years. Divided into three Scrum teams, it is dedicated to the continuous further development of Projektron BCS and the implementation of customer-specific adaptations. In doing so, she has adapted the Scrum process and adapted it to her own specific needs and requirements. The agile approach enables four BCS releases per year.