Vulnerability theory and the product manager(owner)
The PM/PO is responsible on the project because he sets the priorities of what to be developed, comes up with deadlines, controls the budget, and in same time he is accountable on customer acceptance.
In this post I shed the light on how a vulnerable PO can be instrumental in delivering what the customer truly wants in Agile set-up.
A non vulnerable PO would avoid facing the development team without having first detailed requirements and probably documented use cases. Her strive to be perfect will preclude the project from the tremendous opportunity which can only happen if the “PO changes her mind”.
Non vulnerability will lock the PO on himself before jumping to the arena and avoids involving the team very early. Changing the PO mind is the the key for experimentation because it is based on the axiom that I am vulnerable, therefore I seek to validate the requirements and I am open to change my mind based on findings in-order to deliver what the customer truly wants. Despite the presence of many unknowns, the non vulnerable PO will still seek control and predictability!!
Baking requirements and then presenting them to the team is a common practice which is anti Agile because of:
- Development team has not been involved in requirement development, therefore, the team members’ understanding of the application will be low.
- Project risk is directly proportional to the quantity of requirements. The larger the requirements, the more non-validated learning with the end customer, which means very high risk because we are developing software to be thrown away.
Even when the development team is involved early, the non-vulnerable aspect of the PO can be barrier in having him understand what the customer truly wants which can happen only if he is open to pivoting and to change his hypothesis.
In a recent project a key architect from a prime vendor complained that there are no detailed requirements to use as basis for her development work. The PO was attacked and became so defensive and got even feeling of shame. Despite the project was so dynamic with many changes happening daily, still they demanded from the PO to provide detailed requirements!
After some coaching, the PO said bluntly “I do not know the requirements”, I only know to some extent “what I want” to be delivered in the next release after 2 months. The development team should elaborate on ” what I want” to arrive at stories in their own jargon which are at a detailed level enough to carryout both the development and testing work. I will review sprint-wise the software which the team produces to check:
- Are there changes required?
- Is that software worthy or we should get rid of it?
- Was I wrong on what I stated and should make changes or even change direction?
- Have the end customer to concur on the findings and use his input to change my mind.I will be daily involved with the team to answers their questions, if I can, or I probably will need to check with the end customer before answering team questions. I might cancel the sprint as a worst case if there is no way I can make it right. We will learn from this experiment and decide together how to improve. I even can change my mind about the release itself, I will communicate that change to the team once “I have even slight doubt”.
- Vulnerability is our most accurate measurement of courage.- For organizations vulnerability is the birth place of creativity, innovation and change.