The term “agile product development” has become indispensable when marketing the maturity of products and services. In software and hardware development, agility has become popular alongside the buzzwords speed, adaptability, customer centricity, and mindset from both start-ups to large corporations. In the fast-paced business landscape, companies are constantly striving to adapt their products and services to changing markets and customer needs in a timely and flexible manner. Beginning the journey from classic process models to agile development, Scrum is used as a framework for developing products with the highest possible value.

We will take a look at a theoretical introduction to Scrum from the perspective of a developer who is new to agile development methods. For this purpose, we will discuss the differences compared to classical development procedures (especially the waterfall model). This will help us understand what changes will occur for the developer in the Scrum team, what opportunities arise, and what challenges need to be mastered.

Scrum in a nutshell

Before we can feel the effects of migrating to Scrum, developers need to learn a little theory.

As we already mentioned, Scrum is a framework with a few rules. Playing by these rules enables you to make it possible to establish various processes and methods in the “playing field” in order to keep product development close to market requirements and customer needs. Scrum’s roles, events, and artifacts are defined in the Scrum Guide. This quickly creates transparency in the entire chain of product development. In the process, we gain insights that lead to possible adjustments and adaption in individual steps of development or collaboration.

The Scrum Team

The Scrum team, consisting of the Product Owner, Development Team, and Scrum Master, works on the product in a self-organizing and interdisciplinary manner. Self-organizing means that teams – apart from frameworks such as technological infrastructure – are not subject to any outside specifications that determine how the team should work. Interdisciplinary suggests that the teams should be set up, ensuring that all skills and experience required to handle the tasks at hand are available.

The Product Owner

The main task of the Product Owner is providing the team with work. This work is reflected in the Product Backlog. The Product Owner has the maximum value of the product in mind and has mastered the challenge of sorting entries in the product backlog, filing them for the whole Scrum team in a comprehensible, transparent, and value-oriented manner.

The Development Team

The Development Team’s task is to create deliverable functionality as part of the product using the requirements in the product backlog. Teams should be self-organizing and interdisciplinary, which means that there should be no titles or subteams within the Development Team, such as database team, frontend team, and so on. Of course, there will always be specializations in a team that will handle complex development tasks. Nevertheless, the team as a whole is responsible for processing any work that arises – while focusing on the product’s maximum value, as envisioned by the Product Owner.  The Development Team’s size should allow for overhead due to Scrum events and coordination remains manageable, allowing for added value to be created in a meaningful way. According to experience and the Scrum Guide’s recommendation, a Development Team should be between three and twelve members.

The Scrum Master

The Scrum Master’s job is to keep the agile flag flying high in both the Scrum team and the entire organization. They promote the understanding and implementation of the agile methodology in the Scrum team within the Scrum framework. The Scrum Master assists the Product Owner in planning and building the Product Backlog. They support the Development Team by removing obstacles that could disrupt the Development Team.

Scrum Events

First and foremost, the rules include Scrum Events. The goal of these events is to define the work that must be done and bring transparency to task processes. With the transparency created and the insights gained, processes can be adjusted until they’re optimized. All Scrum events should be mandatory, regularly scheduled, and fixed in their time frame.

The Sprint

According to the Scrum Guide, the sprint is the heart of Scrum. A sprint is limited to a maximum of four weeks. During these four weeks, participants work to create a usable, potentially deliverable product increment. This includes Sprint Planning, the Daily Scrum, development work on the product increment, the sprint retrospective, and the sprint review. In the following sections, we will discuss the individual events as shown in Figure 1.

Fig. 1: Scrum in a nutshell

Culture eats strategy for breakfast!

Explore the Business & Company Culture Track

Learn more

Sprint Planning

Sprint Planning is used to determine what the Development Team will work on during the sprint’s time frame. Planning also takes place within a limited time frame during which – as the name suggests – team members plan the functionalities to be included in the upcoming increment. In addition to the content (What will be implemented in this sprint?), planning also provides the answer to the question “How should the implementation take place?”. The Development Team is responsible for defining which steps are necessary to fully implement the planned content within the sprint.

Daily Scrum

The Daily Scrum is a fifteen-minute, daily meeting for the Development Team to ensure collaboration and team alignment, as well as to provide progress visibility. The goal is to stimulate discussions for collaboration after the Daily, make adjustments, or reschedule the rest of the work in the sprint.

Sprint Review

When the sprint is over, it’s time to present the results. The Product Owner invites the team and stakeholders to demonstrate which parts of the product were completed as planned in the increment. Any planned content that didn’t make it into the increment, even though it was part of the sprint goal, is also addressed. The Product Owner and the team get feedback directly from the review’s participants so that feedback can be incorporated directly into the product backlog and the next Sprint Planning.

Sprint Retrospective

Just as a company is always adapting to markets and customer needs in an agile manner, it’s also time for the Scrum team to look for ways to improve. During the sprint retrospective, team members discuss how the last sprint went in order to come up with suggestions for improvements in collaboration, processes, and tools. With these proposals, a plan is defined for implementing the suggestions into upcoming sprints.

Sprint Goal

The sprint goal is a target that can be achieved by completing all stories and tasks in the sprint backlog. A cohesive set of requirements serves as the team’s guiding principle for development within the sprint.

Product Backlog

The product backlog lists all requirements and features necessary for designing the product in future development and all associated releases. It reflects the prioritization, level of detail, and clarity of all list items in the order in which they appear. The Product Owner is responsible for the product backlog and the related formulation of the elements, sorting, estimation of entries, and the added value to be achieved from the development of individual elements in the list.

Sprint Backlog

The Sprint Backlog is composed of elements from the product backlog that are necessary to create a potentially usable and deliverable product increment in the current sprint. The sprint backlog is developed by the whole Scrum team in the planning meeting. In the sprint backlog, the Development Team breaks down work on elements from the product backlog into the required steps and tasks. This results in a plan for implementation and the opportunity to track the development’s progress in the Daily Scrum.

All new for software developers?

As described at the beginning of this article, procedures in the agile environment and especially with the use of Scrum is noticeably different for the Development Team compared to previous methods. Take, for example, the waterfall model, which enjoyed great popularity in software development since the late 1950s. In this linear process model, various project stages are tackled separately, chronologically one after the other. From the conception phase through design, implementation, and testing, to the transfer, maintenance and operation, all phases are individually delineated from one another.

Product backlog and user stories instead of specifications or requirements and functional specifications

Classically, the waterfall model starts with the conception phase. In this phase, the stakeholders, requirements managers, project managers, and other participants define the professional and functional requirements. Developers were once used to starting development with written requirements. When a software developer comes into contact with agile development models or Scrum for the first time, the initial challenge is the lack of comprehensive specification or given requirements. Developers are usually faced with a product vision and a product backlog. In most cases, user stories are stored in the product backlog as software requirements, which are purposefully kept short and formulated in everyday language. These specify exactly what should be developed. Reference is often made to the three Cs (Fig. 2):

• Card: only the most important points are recorded and brief enough to fit on an index card
• Conversation: the exchange is in the foreground
• Confirmation: common understanding is created (define acceptance criteria, if necessary)

The requirements in the product backlog don’t magically fall from the sky, of course. Even though the Product Owner is responsible for the content and prioritization of the backlog, developers are closely involved in the maintenance and detailing of the requirements, unlike in the waterfall model. In the refinement meetings, the Development Team works hand-in-hand with Product Owners, stakeholders, and even customers to prepare the requirements so that they can ultimately be implemented within the sprints. This means that the Development Team must also develop a technical understanding during the conception phases. This is essential, because in each sprint the requirements must also be estimated with regard to scope, complexity, etc. In further articles in this series, we will discuss the topic of estimates and release planning in more detail.

Fig. 2: The three Cs – Card, Conversation, and Confirmation

The product backlog is not carved in stone; it’s a living collection of requirements that’s close to what the customer or the market currently needs. In contrast to the classic waterfall model, this ensures that only requirements that bring the highest added value are implemented. In the specification phase of the waterfall model, it tends to be the case that everything that could ever be needed is included in the specifications without reflection or comparison to the added market value or the customer. When it comes to release dates and cost, in my experience, what’s necessary for productive use of the software is only 20 percent. This is compromised by special requests which up a larger 80 percent.

Self-organizing teams instead of hierarchical announcements

Reviews, approvals, and status discussions with project management are essential components within the waterfall model’s individual phases. From quality gates to different colored traffic lights, there are various control methods. It isn’t uncommon in hot project phases for project managers to micromanage developers, telling them when and how they have to complete work.

Of course, agility does not mean that there is no planning and no control, but within the sprints and the Development Teams, the agility experience is characterized by a high degree of autonomy. In addition to working out what needs to be implemented, Scrum teams are self-organizing. The team decides for itself how to best achieve the sprint goal. However, organizations will not approve a technology change in every sprint, and it won’t be possible to check source code while lying on the beach, bypassing the company’s infrastructure. Within the Sprint, however, only the team is responsible for how the work is divided and completed.

There is no external intervention that dictates how the team should carry out its work. In Scrum, the team has been given an advantage in the form of the company’s trust. It combines all competencies in a cross-functional setup in order to sail in the direction of the sprint goal, reaching safe harbor. The Scrum Master is responsible for ensuring team stability within the sprint. Scrum does not recognize the role of project manager. It does not provide for additional teams within the Scrum team. Of course, there are specializations such as user experience designers, backend, frontend, database developers, or testers. In the dynamics of a well-rehearsed Scrum team, these are deployed in a cross-functional manner in order to create added value in the increment. However, the decision remains with the team.

One increment per sprint instead of beta version 0.1

Delivering a piece of functioning software as a product increment in a four-week long rhythm or less will likely be considered new territory for a developer who has not yet been confronted with agile methods. With the sprint goal in mind, a new piece of functioning, value-creating software is delivered in each sprint. This is different from having several years of development time. Every requirement from the product backlog passes through a mini-waterfall within the Scrum framework. It is designed, developed, tested, the quality is ensured in the Development Team, and it is delivered. Delivery does not necessarily mean that the customer immediately comes into contact with newly implemented software parts. Although the software is not available to the customer in every sprint, the result of the last few weeks of development is presented to the stakeholders in the sprint review.

Nevertheless, there are also organizations that roll out new features and bug fixes several times an hour with Continuous Deployment. The newly introduced sprint rhythm brings the next innovation for developers: If the sprint was successful and achieved the Sprint Goal, the team will have a sense of achievement. Good Scrum Masters know how to effectively place these successes in the company and generate attention towards the Scrum team’s performance. Even if things don’t quite go according to plan in a sprint and the sprint goal is not achieved, the Scrum Master has the right toolbox to uncover what didn’t go according to plan.

The transparency that Scrum brings with the Daily Scrum, Review, and Retrospective is completely new for developers. Whereas in the waterfall model, feedback on the development status, sensitivities in the organization, development procedures, etc. was only received months or years later. This now happens at least once per sprint, if not daily. With the insights gained, adjustments can be planned and implemented quickly for the next sprint.

Transparency and adjusting instead of obfuscation up to the red light

Transparency is the first pillar of the learning and improvement process that every Scrum team is committed to. Starting from the product backlog and ending with the work’s progress in the sprint, content, and changes to the product are openly presented to everyone in the company at all times, enabling visibility in terms of the team’s progress. In the Daily Scrum, the sprint review, and the sprint retrospective, teams address topics and identify areas where there is potential for improvement. Only topics that are uncovered and addressed can be reviewed and adjusted. Any adjustments to the collaboration can be launched in a timely manner.

Whether it’s bugs, technical adjustments, or simply change requests from a stakeholder perspective – everyone in the software development field knows that the timing of a change in the development cycle plays a decisive role. A change that would cost us one euro in the waterfall method during the specification phase may cost us one hundred euros if the same change isn’t considered until the testing phase. The curve for change costs in agile development is much flatter. The constant transparency achieved with review and adaptation addressed changes in every sprint, keeping the cost of change low.

With this small insight into the agile world with the Scrum framework, I hope some developers – whether already agile on the road, or not yet – recognized themselves. In the next part, we will discuss agile estimating and planning.