Before there was Agile and Scrum, there were no Product Owners. In my first job as a software developer at a bank, in the 1980’s, we had a team developing software for securities administration. The team consisted of a project manager, a team lead, three programmers, a tester, and an information analyst. There were two users that would drop in once a week, with the information analyst they formed the liaison with the users. The information analyst would spend half their time at the head office, talking with staff and users and analysing the information need of the bank and the users. In the other half they would document the information need and they would talk to us. The information analyst spoke bank language with the users, they spoke data language with the rest of the team. Because users were present in our team regularly, we were all aligned at all times.
Based on the information analysis, we would create what we called a “functional design”, that is, a design of the system we needed to build without any reference to software or computers. This functional design described the “what”, not the “how” of the system. Once we all agreed on the “what”, it was straightforward to document the “how” and to program the system. During development, users were available at all times to answer questions and clarify business needs.
Scrum works in the same way, more or less — except for the sprint thing. It does for every feature what we did for the system as a whole: you analyse what is needed, you create a functional description, then you implement and test. A major difference — except for the sprint thing — is that Scrum inserts a Product Owner.
What does a Product Owner do in Scrum? Scrum.org says
(the) Product Owner is accountable for maximizing the value of the product (….) The Product owner is also accountable for effective Backlog Management, which includes:
- Developing and explicitly communicating the Product Goal;
- Creating and clearly communicating Product Backlog items;
- Ordering Product Backlog items; and,
- Ensuring that the Product Backlog is transparent, visible and understood
In our project at the bank, the team was responsible for the value of the product, the project manager was accountable. We did not have a backlog. Instead, we had a functional design that guided us, this functional design was the project goal. Whenever we started work on a new feature, we looked at the design and decided which features would make most sense to pick up next. This means our “backlog” was not a random list of unrelated features, but rather a grand plan of features and their relationships.
We did not have a Scrum Master. We did not have pre-scheduled meetings in our project, we had no ceremonies. What we did have was ongoing conversation between team members. On Monday mornings, the project manager would meet briefly with the IT manager. In that meeting, progress and plan for the next week would be discussed. In the team, the project manager had an enabling and coaching role, more than a managing role. We discussed issues as they came up, typically two or three of us at a desk, drawing, typing and talking. This whole model was based on mutual trust.
So, what about the Product Owner?
In my view, a Product Owner is a person who is inserted into the organisation between the users and the development team. To me, as a software developer, it seems that the Product Owner has a magician’s hat from which they produce random features for me to implement, saying “this is what the business wants”. If I have questions about the feature, the PO needs to go back to the business people, so I’ll get my answer three days later. In some projects, I have to wait asking questions until there is a “refinement meeting”. In the bank, I could just ask the information analyst, or one of the users, and I’d have my answers instantly.
It’s interesting that three out of four PO tasks are about communication: the PO communicates the product goal and the backlog items and makes the backlog “transparent, visible and understood”. The PO is in between the user and the developer, with the sole goal of communicating between the two. How much more efficient — and effective — would it be if the user and the developer could just talk to each other. The fourth task of the PO is ordering backlog items. As I said, if you have a grand design of what you are building, reading priorities from the design is more effective than ordering a backlog.
My conclusion is that we should not have product owners. Instead, we should have teams and users communicate directly. We should not have lists of unrelated features but rather a functional design of the system we envision. Features in the design do not need to be detailed upfront, but rather, the details will be added when we start development on them. The design should be a living ever changing vision, maintained by the team. For this, you want the team to be cross functional, with users, designers, developers, devops, UX experts, testers, etc. Some of the team members need to be super senior so they will coordinate, coach and manage when necessary. This brings me back to the bank: in my second project, I had my own cross functional team of people I knew I could rely on. I programmed, I was the coach, I spent time with other teams, helping them out so I knew they’d help me out when I needed them, bringing teams together to solve some of the nasty issues we encountered.
I learned that “being a team” is more important than having the right procedures, ceremonies in place. Or Product Owners, for that matter.
About me
My first developer job was in a time when we did Fortran and Cobol, using ancient technologies like IMS and CICS on batch-oriented mainframes. I developed my skills, adopting new technologies as they came along. I have developed AI systems in the ‘90’s, I wrote my first Java software in 1995. I currently work as a freelance developer for Spring boot, Android and React. My Github space is here, my LinkedIn is here, my web site is here.
