Welcome to Part 3 of my blog series covering “More Agile Great Debates.” I hope that the next set of five debate topics will spark some conversations. In no particular order, they are:
- Scrum Should Only be used for Product Development
- A Product Backlog is Never Finished
- It’s Okay to Throw Out your Product Backlog
- Scrum is a Methodology
- Product Owners should Own the Product’s Budget
Scrum Should Only be used for Product Development
I might get a few dissenters on this debate, but Scrum can be used in many different ways and contexts, and NO, it’s not just for Product Development. That said, I would argue that Scrum is the best way to do many types of product development (but not all).
This confusion often happens in organizations that are new to Scrum and is because most companies still operate in traditional ways, funding projects rather than products. This means that how the investment happens can significantly impact an organization’s financial position.
Also keep in mind that projects, unlike products, have very distinct beginnings and endings, whereas products must be constantly cared for and fed. This means the products are continuously evolving and that they always have a Product Backlog.
Projects, on the other hand, end. When they do, the team that did the work is disbanded, and whatever the project produced is turned over to someone else to “maintain.”
There is a time and place for both products and projects, but the organization needs to understand the difference and make the appropriate choice for implementing either one.
A Product Backlog is Never Finished
In traditional projects (versus products), the scope of work is fixed at the beginning, and change is resisted, especially as the project progresses.
However, when operating in an agile fashion, the focus is more commonly on building a product. As such, the Product Backlog is an ever-changing, dynamic, living, breathing artifact that is never finished (until the product is retired).
The Product Backlog is merely a placeholder for ideas of things that might be built. The Product Owner owns, manages, and prioritizes the Product Backlog, and can add, remove, or change any backlog items at any time.
Unlike waterfall projects, in which the scope is a “promise” that all listed work will be completed, the items in the Product Backlog are all negotiable, and there’s no guarantee that any specific item will be completed unless and until the Product Owner prioritizes it based on her definition of value.
It’s Okay to Throw Out your Product Backlog
This one is TRUE! Products that have existed for some time, or those that have new team members, may sometimes benefit from totally tossing the existing Product Backlog and starting anew with a fresh slate.
The reason this might be a good idea is that backlogs tend to accumulate a lot of ideas over time, and then grow unwieldy and hard to manage. Many items in the backlog either become old, stale, or irrelevant. If the quantity of items in the backlog is particularly large, it may be totally overwhelming to the Product Owner.
So, yes, it’s okay to trash an existing Product Backlog and build a new one. However, there is a caveat to this – I wouldn’t actually recommend deleting the old backlog. Instead, I would archive it somewhere in the event that something in it comes back up. That way, you don’t lose all the history and context of the item.
Another caution is technical debt – these items probably ought to remain in the new backlog if they can’t be verified as already fixed. Every product has technical debt, and unfortunately, it can’t be avoided indefinitely.
Scrum is a Methodology
This is another of my huge pet peeves when it comes to Scrum. NO! Scrum is most definitely a methodology. The definition of “methodology” is:
“a set or system of methods, principles, and rules for regulating a given discipline, as in the arts or sciences”
– Dictionary.com
The real point is that methodologies are very prescriptive; they must be followed exactly. In contrast, Scrum is a “framework,” which means:
“a basic structure, plan, or system, as of concepts, values, customs, or rules”
– Dictionary.com
As you can see, frameworks are much more flexible and may be adapted based on the needs of the team. Frameworks are also very basic – they have just the bare bones of what is needed, and much is left open to adaptation and modification.
So, when so-called agile “experts” make the mistake of calling Scrum a “methodology,” I just want to scream! I know the distinction between these terms is subtle, but it makes a major difference.
Product Owners should Own the Product’s Budget
While some leaders and managers may not want to let go of Product Budgets, it’s perfectly appropriate for a Product Owner to own her product’s budget. Without having the big picture, financials included, how could the Product Owner possibly evaluate the return on investment and make the best product decisions? It’s very difficult, indeed.
The Product Owner is essentially the CEO of the product, and that means she is responsible for all aspects of product success, including its costs and profits. Organizations that guard the financial information and keep it out of their Product Owners’ hands are only doing themselves a disservice. By not fully endowing all responsibilities regarding the product, it’s like tying one hand behind their back.
Product Owners who only deal with the tactical aspects and day-to-day aspects of a product may end up making poor decisions that result in financial losses. Likewise, how can she determine whether her decisions are good ones and that the product is successful? She can’t.
To get the most out of your investment in building a product, organizations need to let go and trust their Product Owner with the full breadth of responsibilities for developing a product, including the money.
Final Thoughts
There you have it – five more common agile topics that spark debate amongst practitioners. In closing, Scrum is a framework, not a methodology, and although its origins are in software development, it can be used for many other things. Also, the Product Owner can and should have ownership of her budget, and her Product Backlog, which should continuously evolve, although if she wants to, she can toss it and start over again.
That’s a wrap. What do you think? Have you had any of these debates with people before? What happened? Do you have a different opinion? If so, please share in the comments below!
And, if you missed the first couple of installments of this blog series, you can check them out here: