I was talking to a few of coworkers one day and I was sharing my thoughts about what it means to be Agile. One of the thoughts that I shared with them was that I believe that the most important relationship on an Agile Team was between the product and the Product Owner. I believe that the relationship between the product and Product Owner is so important that it should be viewed as a marriage. In this blog post I wanted to talk about this very important relationship and what I mean when I state that the relationship between the product and Product Owner should be viewed as a marriage. I will also discuss how this belief has benefited me on projects I have been involved in.
The Marriage
The most crucial role in an Agile environment is the Product Owner. The Product Owner serves as your product expert, often times the Product Owner is partially or fully responsible for the creation of project and the Product Owner gives the team very important insight into the Business. From my experience, if an Agile Team has very limited access to the Product Owner, often times the project will be plagued with confusion, could fail to deliver the correct product or may not deliver a product at all.
The main reason why the Product Owner’s role is so crucial is because this role informs the team what it is they will be delivering and provides frequent feedback to the team about the state of the product. The Product Owner should be available to the team to clear up any confusing regarding the product, informing the team of changes to the product, to provide product release schedules and to determine whether or not the team delivered all of the changes to the product at the end of each iteration that was agreed upon.
As you may have noticed, each time I mentioned the Product Owner, I mentioned the “product”. The Product Owner and product are inseparable and this is the reason why I believe that the relationship between the Product Owner and the product should be viewed as a marriage. Similar to a marriage, the Product Owner and product should see each other as frequently as possible. The Product Owner should be able to sense if the product is changing in a way that could threatening the entire marriage. At no point in the project, should the Product Owner ever feel like the product has changed into something that he or she no longer recognize or asked for. If the Product Owner is reviewing the product very frequently then the Product Owner will be in a much better position to inform the team about the state of the product and the team will be in a much better position to deliver a product that is acceptable to the Business.
From my experience, the projects where you have the longest gaps between changes to the product and when the Product Owner actually reviewed those changes were the projects that were rife with confusion, missed deadlines were frequent and had the most tension between the team and the Product Owner. Tension would occur between the team and the Product Owner because the product was being reviewed so infrequent by the Product Owner that the Product evolved into something that the Product Owner felt they did not recognize and this typically results in frustration on both sides.
Real World Example
I remember a project I worked on where the team members had no access to the Product Owner and how much confusion this situation caused. On this Project, as a consultant, my role was Lead Developer and we were delivering a very time sensitive Web-based product for our client. The project can be described as a Death March as the team was faced with a very tight deadline, lots of work, lots of hours and the product requirements seemed to change daily.
The team was practicing a very limited version of Agile Scrum as we had daily stand ups but we did not plan and the team never met with the Product Owner. The way the project was setup was that a Project Manager literally met with the team to tell us what the Product Owner wanted, got our feedback and then she would go to meetings with the Product Owner and inform the Product Owner about the questions the team had. I told the Project Manager that this was extremely inefficient, the messages between the team and the Product Owner were going to be corrupted and that the team should be reviewing the product with the Product Owner more frequently since we had such a tight deadline and we could not afford to have any mistakes on what we were being asked to deliver. I remember we had one emergency meeting where the QA Team was panicking about business requirements and I asked the Project Manager why the Product Owner could not meet with the team to clear up some of these issues and she politely informed me that she would inform the Product Owner of any questions that the team had for her.
As I predicted, as the project progressed, things got more and more confusing, no one seemed to know what the end product looked like and the team only heard our Product Owner by name, we never got to interact with her. And as usual, an event happens that forces everyone to rethink how a failing project is being executed. We ended up having an all hands meeting with company executives, the Product Owner, the Project Manager and the team. In this meeting, I asked everyone on the team if they felt they had proper access to the Product Owner and to a man, each of them said no. During this meeting, I suggested that the Product Owner attend every daily standup and that since we were weeks away from our deadline that we start doing daily reviews of the product with the Product Owner.
The very first time we reviewed the product with the Product Owner, I demoed each part of the application to her and it was if the Product Owner didn’t even recognize the product that we were building. She didn’t recognize the product we were building because the product had changed so much and she was reviewing it so little, that like a marriage, she didn’t recognize the product any more. This situation caused so much panic that the Product Owner told the team that we could call her at any time, day or night, if we had any issues because we were getting very close to the deadline.
As soon as the team was given frequent access to the Product Owner on a daily basis, the course of the project took a very dramatic turn for the better. As the team started to review the product with the Product Owner, we shortened our feedback loop, the product started to evolve into something that the Product Owner began to recognize, questions were answered as soon as they were asked and the team had much more confidence that they were delivering a product that the business envisioned.
Although we worked a lot of hours to get the project over the finish line, the team ended up delivering a product that was an overwhelming success. The product was created in 2014 and it is still being used by our client to this day. We were able to be successful because like a marriage, we were eventually able to keep the Product Owner and the product extremely close.