How Our Scrum Team Works — Insights From a Software Developer
Reflections on Scrum and Agile
In 2016 I changed jobs and finally was able to work in a team using the Scrum Framework. The whole company had switched to Scrum shortly before. To this day the transition to Scrum has still not been completed, but nevertheless, I was able to learn a lot about agile software development.
I would like to share a few experiences and thoughts that I have gathered over the last 6 years. Not from the point of view of an agile coach or Scrum Master but from the point of view of a software developer.
It’s Good to Have a Dedicated Scrum Master
In Scrum, it is generally recommended for each person to have a clear and specific role within the team, rather than having multiple roles. This is because having clear roles helps to ensure that each team member has a clear understanding of their responsibilities and how they contribute to the team’s success. It also helps to avoid confusion and conflicts of interest within the team.
Of course, we did not comply with that. In the beginning, a developer also took on the role of the Scrum Master, later we even tried to rotate the role of the Scrum Master every three sprints — so that each developer was Scrum Master from time to time. This has repeatedly led to conflicts and was bad for the success of the team.
Believe me, it makes sense to have a good and dedicated Scrum Master. Not everyone has the right personality to be a Scrum Master. The Scrum Master is not a team assistant, he is the servant leader of the team, in possession of the right skills and capabilities to help a Scrum team to be more effective and efficient and drive continuous improvement in their process. In my opinion, the role of the Scrum Master is one of the most important and it definitely pays off to fill it accordingly!
Keep a Clear Definition of Responsibilities
In Scrum, there are three main roles: the Product Owner, the Scrum Master, and the Development Team.
- The Product Owner is responsible for maximizing the value of the product and for making sure that the Development Team is working on the most valuable items. The Product Owner writes user stories, prioritizes them in the product backlog, and communicates with the Development Team about what needs to be built.
- The Scrum Master is responsible for facilitating the Scrum process. This includes facilitating meetings, helping the Development Team and the Product Owner to understand and follow Scrum, and protecting the team from external distractions.
- The Development Team is responsible for building the product. The Development Team is self-organizing and self-managing and is responsible for completing the work necessary to deliver a potentially shippable product increment at the end of each sprint. The Development Team consists of cross-functional team members, such as designers, developers, and testers who work together to build the product.
This explanation is nothing new but we didn’t always stick to it, we mixed up responsibilities and that always led to conflicts.
One Product Owner and one Development Team
It is possible for a Development Team to work on more than one product, but it is generally not recommended as it can lead to conflicts of interest and can make it difficult for the team to focus on a single product. In Scrum, the Development Team is responsible for building the product, and it is important for them to have a clear understanding of what needs to be built and why. If a Development Team is working on multiple products, it can be difficult for them to maintain this focus and to prioritise their work effectively.
We had several product owners and worked on multiple products at the same time. This led to product owners fighting over the team and developers being frustrated because they were constantly working on something else.
Do not mix classic management hierarchies with Scrum Roles
Neither the product owner nor the Scrum master should be superior to other team members.
The development team is organizing and self-managing, and they are responsible for determining how to best complete the work necessary to deliver a potentially shippable product increment at the end of each sprint. The Product Owner and the Development Team work together as a collaborative team, with the Product Owner providing guidance on what needs to be built and the Development Team determining how to build it.
It is important for the Product Owner and the Development Team to have a strong, trusting relationship and to work together effectively to ensure the success of the product. The Product Owner should respect the expertise and autonomy of the Development Team and should not try to micromanage the team or dictate how the work should be done.
If the product owner is also the superior there is a danger that he/she will abuse his/her power and assert himself/herself against the development team. This leads to the team’s potential not being exploited, as it cannot really work in an organised manner.
Product Owner with a Technical Background
Having a technical background can help the Product Owner to better understand the capabilities and limitations of the technology being used to build the product, and to communicate effectively with the Development Team about what can and cannot be done. However, it is not essential for the Product Owner to have a deep understanding of the technical details of the product.
In our case, one of our POs had a very technical background. Therefore he wrote very technical stories and also made architecture decisions without involving the developer team.
Developers are not the slaves of the product owner, not some stupid code monkeys. They need a challenge and want to work out the best solution together.
If a product owner dictates everything and the developer team does not feel jointly responsible for the product, agile software development and the principle of organized teams will not work.
We Prefer Generalists over Specialists
From the very beginning, we followed the motto that all team members should be able to do everything. We wanted generalists, not specialists.
This had in the first place, at least in theory, the big advantage that if someone left the team — was sick, or was on vacation — there were no dependencies and someone else in the team could take over their tasks.
Furthermore, the work was varied for all team members and we could work on sprint tasks according to the pull principle.
I think there is nothing wrong with that. However, there are a few things that should be considered:
- If all team members can do everything, everyone may want to participate in all decisions. This in turn can lead to long, tedious decision-making processes and slow down the team.
- In my view, everyone wants their own thing, something for which they are primarily responsible. Something with which they can have success and earn respect from others.
For this reason, I also recommend that generalists hand over responsibility for technical and specialist areas to individual team members. Not that these then have sole responsibility and power over it, but that individual persons are responsible for areas and advance them together with the team.
Don’t Forget to Scale
Ideally, your product will evolve from MVP to an improving and better product. Your customers want more and more features, bugs and technical issues become more and more and also have to be dealt with.
Soon it will happen that the team will not manage everything and thus the team will have to be enlarged. If you suddenly count more than 10 people in the Daily and have trouble following everyone, you missed the right time to scale according to the workload.
I can only recommend dealing with the topic of scaling early on and working out a plan together with the team. It is a very challenging topic when several teams have to work simultaneously on one product as independently as possible.
For further details in this context, I recommend the book “Team Topologies” (https://teamtopologies.com/), Spotify’s Squad Framework and the SAFe Model.
Scrum is not a Ritual
Be patient if you want to work according to scrum. Hire help, external agile coaches, or experienced team members who have worked with Scrum for several years, it’s worth it. It’s not enough to read a book and get the Scrum Master certificate in order to work meaningfully with Scrum.
It’s not about doing Scrum for the sake of doing Scrum, it’s not about sticking to the rules, it’s all about establishing an agile way of doing things that overcome old habits and problems and allows you to tap into the full potential of all your team members and get much more done.
This only works if the company as a whole adapts to an agile way of working. Always remember the agile manifesto and remind your management of its content. Especially when they come up with new processes, tools, bureaucracy, documentation, senseless planning, and pointless micromanagement.
