Re: [scrumdevelopment] Product Owner overtasked by Scrum?
"mistakenly think that CSM is for developers"
"mistakenly think that CSM is exclusively for developers"
On Tue, Dec 30, 2008 at 6:43 PM, Tim Walker <walketim@...> wrote:
> Some thoughts in context (TW>) below...
> On Tue, Dec 30, 2008 at 4:03 PM, Jesse Fewell <email@...> wrote:
>> At my current project, I am an assistant for a Product Owner, but really
>> that means I do all the work and he does all the deciding. We've been
>> maturing our Scrum process, and I've hit a breaking point. As this past
>> iteration entered into its last days, things got out of hand. In one breath
>> I'm updating the backlog tool (MS SharePoint) with latest stakholder
>> priorities, and in the next breath I'm performing UAT so things can go live.
> TW> One of the things that should probably be happening is that the
> rate of development should be restricted to defects and the developers
> should be pitching in and helping with the exploratory testing. This
> is about the team, not the product owners versus the developers.
> George's question about automated regression is a good one. If the
> developers have been diligent there should be automated regression
> tests and extremely good test unit coverage. If you and the team have
> used executable requirements, or BDD, you should have automated
> acceptance, sprint over sprint, so the testing during the hardening or
> pre-release effort is really mostly exploratory. Perhaps you should
> focus on an alpha/beta program and let some friendly users have at it.
>> The day-long Sprint Review, Retrospective, Planning meeting is hard enough,
>> but all the prep work has me pulling out my hair.
> TW> If scrum overhead is hurting you might want to consider bagging
> scrum and moving towards a Kanban, iterationless, model. Two
> questions: 1) How big is the scrum team? 2) Have you raised your
> concern at the retrospective?
>> Are there any Product Owners out there with a sample breakdown of their
>> iteration tasks and timelines? We've seen tons of articles about optimizing
>> the Scrum Team's performance, but what about the Product Owner? Is CSPO
>> class really that different than CSM?
> TW> Not sure about CSPO, though I have talked to folks that have taken
> it. However, I can speak in detail to Valtech's certified product
> owner class (I have absolutely no affiliation with Valtech but I do
> know it and this subject well as ex-director of that program). It is a
> different focus and is more about story writing, effective agile
> leadership, and, well, a whole lot more. It is still only 2 days, not
> enough!, and this because product owners usually complain that they
> simply can not 'afford to take the three days in a row to take CSM or
> mistakenly think that CSM is for developers. I'd suggest training,
> workshops and coaching if you can. The little by little approach. That
> said, it used to irritate the crap out of me when I would deliver an
> intensive 3 day Agile Mastery course and during the intros I'd ask the
> class "where are the product owners?" and the team would answer "no,
> should they be?". Of course they should be there. It's great that
> you're asking these questions, a lot of product owners that I've met
> simply don't even do that. Also, if you aren't already doing it. Look
> into BDD and Executable Requirements. Definitely look in to FItnesse
> training. Stop wasting time with sharepoint (I just shudder to even
> type it) and start writing requirements as directly executable.
> Best regards,
- I think that who attends the retrospective should be more a function
of the particular history, culture and personalities of the people
than be a hard a fast role-based rule. It's the goal that matters.
The goal is to "inspect and adapt" and that everyone must be heard
(and safe) so that we can discover what is working and what is not
As servant leader, I have found that it helps the development team if
I provide the structure so that the strong personalities do not drown
out the meek ones. At the same time, we may want to exclude those non-
developers who might inhibit open conversation (but with an eye to
correct this over time so that the culture evolves). Eventually, we'd
like to see the rest of management and the PO team as silent
observers where everyone securely feels we are all on the same side
helping each other and pulling in the same direction. But Utopia was
not built in a day.