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.
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”.
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.
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.
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!
