My pal Bramus! (mind the exclamation mark) was so nice to post a long comment on the series. Instead of replying on the comment, I decided it deserved a full post. (I’ve snipped the comment, the original can be read here).
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).
This sounds more like a release plan to me, in which you define a feature set (number of groups of stories) that will be delivered. Generally these will take some time, and you will divide your time in sprints. Part of the power of sprints is that they allow a certain pace and rhythm (each sprint takes the same amount of time), making your process and release dates predictable to a certain degree. (you’re never sure since you’re estimating).
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.
Part of scrum is based on reducing the time between development of code and the testing of it (hence test driven development) and making sure you have something ’shippable’ at the end of every sprint. So you could indeed look at it as a mini waterfall (there are points where it doesn’t hold true, mainly in design phases and the command&control style inherent in waterfall systems)
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?
I admit, it’s not the most wonderful sentence I’ve ever used. What I intended is that he won’t get away with JUST having the high level overview. He needs more, deeper understanding. He won’t get away without any overview also, but that’s a different matter altogether 
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").
I know that one, but there is an essential difference. Women are people (yes, they really are, I’m not just saying that because of wijvenweek). If delivering a baby would only require thought (=cpu power) it would probably be possible to deliver a baby in one month with nine women. (probably little over a month due to the overhead generated by nine women). Never thought I’d say that one day
Yeah, I’m a bit confused on the placement of scope & resources in the variant (IM me :D)
Will do. Or we’ll catch up sometime at one of the local bars.
the final goal must never be kept out of sight.
Couldn’t agree more.
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")
Had an interesting discussion about this with someone arguing that a project manager (slight difference to product owner) doesn’t need technical baggage. To a certain degree I can follow this logic. However, if you think scrum is widely used on software development projects, I still would like to see the first project manager on a software project who hasn’t got a technical background and does a really good job. On more operational projects, I agree you can get away with less of a technical background, but that’s somewhat outside the scope of the series.
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
That was indeed what I had in mind when saying job. This being said, in an ideal world the fact that you freelance after hours shouldn’t have any impact since it’s after hours. Product Ownership is a full time day job, it’s because people (golf players) are not taking it seriously that they are putting it next to someone’s day to day job. This ends up in that person doing 2 jobs and generally resulting in a poor job on the product ownership side (it is perceived a side job after all). If one wants to do it right, it takes more time than what is available in a normal week resulting in less free/personal time, and in that case it starts negatively affecting the freelance business (and vice versa).
Recent Comments