In this post I'd like to elaborate on the last point from the introduction. You can read this post as a standalone, or you can go back to the introduction, part 2, part 3, part 4 or part 5.
Point 5: "No other job"
No other job, that would indicate that you dedicate all your useful time in the office (there's always some overhead). Just think about that idea. Only having to care about one project would allow you to shape up on the knowledge you need, take your time for all the stakeholders, spend enough time dissecting the backlog, have regular talks with the team, provide timelines and other needed documents for project support and follow up amongst the golf players of this world, ... AND you probably still would have some sort of social life left. Doing a good job as a product owner is a full time job, if you don't believe that, try being a good one. So really, I literally mean, not having any other job.
The statement also implies a second thing, because no other job means no other priorities.
We all know the office is rigged with politics and hidden agendas. I think as a product owner guarding your own neutrality in that jungle is something you should aim for.
Looking at it from a pragmatic side, it might be worth having a product owner governing a few related products. It means a good use of needed knowledge since, amongst similar projects, often similar knowledge is needed and generally the same (or big overlapping) group of stakeholders is involved. The downside is that it might somewhat distort the product owners neutrality.
I'd like to use these last few words as some kind of a closing note on the entire series. A lot of it was written with a perfect world in mind and with the idea that there are little to no personal preferences and/or tradeoffs to be made.
Since we don't live in an ideal world, I think it's important to carry forward the ideas and try to implement these in the best possible way. You may not always get what you ask for, but being creative with what you get is never a bad thing.
1 opmerking:
Awesome series of posts! Posting my reply here as this one is the final of the series.
[ WARNING : I'm no master here on this subject :P ]
The SCRUM methodology first was unknown to me, yet the principles it holds I already was maintaining:
Define a set of features/tweaks for the next release and go for it.
Hereby I keep a list of urgent/less urgent/nice to have which indicate the priority (the so called backlog).
However I implement these in a kind of a waterfall method (define, implement, test, fix bugs, final). Don't know if I get the full picture here, but to me a sprint seems like a mini-waterfall to me.
Anywho, to the list:
1) "A deep understanding of the problem"
********************************************
The Product Owner should indeed have a great insight into the matter. He must know the ins and outs, combined with great communication skills in order to please all parties. Above that he must be able to filter/translate requests into a language the developer/whateverer understands and see relations between some of the requests.
You wrote "In order to do all this, there is no way the product owner will get away with having a high level overview of what the product is supposed to be". Shouldn't that be without?
2) A good enough technical background
********************************************
In order for the PO to translate those requests he must indeed have an insight in what's possible and what's not. If not, he must either talk to his development team or start reading a (general) book on the matter (imo that is).
When the heat is on, some decisions must be made indeed in order to please all stakeholders. If the PO has a technical background he can set priorities, backed up with the relations he sees within the different requests.
3) Great communication and negotiation skills
********************************************
See 1 and 2. Glad to see you've used the term stories, as they indeed are stories. The product is a book, containing several chapters, each with their own stories and pages. Taking a product to this granularity and linking stuff from story A to story B (and mashing that up into a new story for stakeholder A & B) in order to start the negotiations with all stakeholders.
In order to convince them all, he must have strong communication skills, backed up by some simple people management skills (always smile, don't burst out, be positive, flatter the others, etc.)
And aah, the triangle which I recall it being cheap-fast-good:
cheap+fast=!good
fast+good=!cheap
good+cheap=!fast
To me, resources fall under the cheap part. Adding more developers, will increase the price, leaving less money for the development itself (as you indicate).
Yet, when adding more resources, the product won't necessarily improve the product (once read: "nine women can't deliver a baby in on month").
Yeah, I'm a bit confused on the placement of scope & resources in the variant (IM me :D)
4) A "business sense" and a vision
********************************************
Aaah, the Plan! One of the reasons why I quit my old job is that my boss had no bigger goal set, he was just riding along the waves not knowing where he was gonna end up. That lack of vision really bothered me, as I myself need to have a goal to strive to.
To accomplish the goal, a business sense indeed must be there. One must precisely know how what will effect the path to reaching the goal. Sometimes a sidepath must be taken in order to get on the main path again, yet the final goal must never be kept out of sight.
And to the questions you asked: no and yes. Two obvious answers imo as ones decisions are highly impacted by knowing what's possible and what's not (cfr. "A good enough technical background")
5) No other job
********************************************
Yes, guilty of that one, I'm a freelancer too after hours. And yes, that affects my day job one way or another (both in a positive and negative manner).
However, the interpretation of job can be expanded as in "no other big projects to handle" as one cannot focus the full 100% on the project otherwise (distractions from the other project, cutting corners in order to work a bit more on that other project, etc.).
Phew, big comment. Hope the submit won't give a timeout :-¨P
Een reactie posten