How Are You, Scrum Master?

How Are You, Scrum Master?
January 26, 2024
This article is our way of demonstrating a process of building, maintaining, and advancing professional, yet friendly relationships with one of our numerous happy clients. Here you will find some interesting remarks regarding our agile process, as well as how Petr managed himself, as well as his team during his project.

Petr Hendl joined SABO in April 2022 as a senior consultant. In September, he agreed to take over project management and Scrum master duties for one of our many ongoing Volkswagen projects.

So, Petr, what is your experience with agile project leading?

I was already a member of agile teams in a developer role (both programming and testing), but I never led such a team. I have however long experience with project management and team leading. I had several months in SABO to watch and learn, and I must say I was surprised. Positively. Agile projects are popular nowadays, but if you ask companies, usually they say: “We do something like scrum, but we modified it to our needs”.

Do you therefore think SABO does agile well?

Yes, the processes are the best I have seen so far. And I have seen teams in big international companies, paying expensive coaches, as well as small start-ups, trying to optimize their development process. I have always seen the same mistakes – overcrowded boards, delayed releases, unfinished tasks. Decisions are made by developers, lacking input from product owners—endless poker meetings, teams sunken in bug fixing, customers asking for deadlines, and so on.

Are product owners important for the software development process?

Definitely. Having no requirement nor functional specification is perfect. It can be good or bad, but there are always questions and doubts. If programmers decide, they might be often wrong, because their point of view is different. But it helps a lot if developers can ask and they promptly get answers, because they do not program something wrong or too difficult.

Agile development itself is not faster utilizing produced lines of code or whatever units of functionality. But is supposed to implement the most important and most useful parts of requirements in the given timeframe. My observations are, that there are three types of product owners:

1. POs, who never know an answer, have only generic ideas and take all questions resulting out of the conversation to be discussed later with some other team. They never come back and never make any decisions. The team usually waits a long for an answer and then makes assumptions or implements the most complex solution.

2. POs, who are not sure, but can ask and bring answers within a few days. This creates delays in development and forces developers to jump between topics, but at least in the end, there is a resolution.

3. POs deeply involved in the business, who define the scope and use the system under development. Such people can usually give answers right away, making the development

smooth and efficient. If they can even set priorities and give up on too complex solutions. In such a case, you found a golden trophy and the key to your project's success.

I am happy to say we have the 3rd case in our Volkswagen project.

Is the waterfall project process dead?

In my opinion not. There are still cases when it fits better – from my experience especially large, fixed-price projects for government or corporations, where you need to know, when, what, and for what price must be delivered as well as systems with interfaces and dependencies, which must be planned for a long time because of synchronization with other systems and institutions.

Also, within the waterfall principle, you should use techniques like MVP (Minimum Viable Product), continuous integration, automated testing, and other techniques, which are usually mentioned in the context of agile development. In the waterfall process, it is however crucial to split a big project into smaller phases, milestones, teams, etc. to make the amount of work manageable. It is necessary to have well-implemented change management. The same as in the previous paragraph applies – developers always need clarifications and decisions – also here is involvement of business stake holder necessary.

Thank you and good luck in your projects!

Petr is an experienced developer, architect and project manager. In SABO his role is mainly Java backend development with overlap to databases, system architecture and devops. To relax, he enjoyes mountains and photography.

Other articles by same author

Article collaborators

SABO Newsletter icon


Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

About SABO Mobile IT

We focus on developing specialized software for our customers in the automotive, supplier, medical and high-tech industries in Germany and other European countries. We connect systems, data and users and generate added value for our customers with products that are intuitive to use.
Learn more about sabo