If you read Scrum literature, you may get the idea that the Product Owner is a kind of dictator of the product backlog, in that he or she unilaterally decides the priority of work remaining on a product and passes this order down to the development team.
Author of All About Agile, Kelly Waters, has this to say:
Anyone can add anything to the Product Backlog. Anyone. The Scrum process, and agile development principles generally, are collaborative and inclusive.
But… very importantly – only the Product Owner can prioritize the Product Backlog.
As I mentioned in my last post, there is a ton of writing out there about Scrum and Agile methodologies, and it is definitely possible for someone to come to Scrum with preconceived ideas about how software should be made, and then find justifications in the writing.
I want to make the point here about the importance of development team input into backlog priority.
In particular it’s very easy for a Product Owner to dismiss technical debt or other concerns that typically only the developers grumble about as less “sexy” than delivering another feature to end users.
When the decision comes down to fitting one more new feature into a sprint or paying off some debt on code quality, the decision usually goes to the former. But as the authors of Peopleware discuss, managers need to keep in mind the importance of quality to makers, above and beyond just immediate market concerns:
We all tend to tie our self-esteem strongly to the quality of the product we produce—not the quantity of product, but the quality. (For some reason, there is little satisfaction in turning out huge amounts of mediocre stuff, although that may be just what’s required for a given situation.) Any step you take that may jeopardize the quality of the product is likely to set the emotions of your staff directly against you.
The hard-nosed, real-world manager part of you has an answer to all this: “Some of my folks would tinker forever with a task, all in the name of ‘Quality.’ But the market doesn’t give a damn about that much quality—it’s screaming for the product to be delivered yesterday and will accept it even in a quick-and-dirty state.” In many cases, you may be right about the market, but the decision to pressure people into delivering a product that doesn’t measure up to their own quality standards is almost always a mistake.
Scrum expert, Mike Cohn, also discusses times when developers should be given leeway to decide their own priorities, including when they just need a break from the same old same old:
On some projects, teams occasionally hit a streak of product backlog items that are, shall we say, less than exciting. Letting the team slide slightly ahead sometimes just to have some variety in what they’re doing can be good for the morale of the team. And that will be good for product owners.
Product owners, please remember to incorporate the feedback of your development team into prioritization, as it has real effects on their morale. And unhappy developers will tend to leave your project for greener pastures.
0 comments :
Post a Comment