In software engineering, the magic triangle is a well-known concept to illustrate the relationship between scope, time, and cost of a software development project. Of the three (scope, time, cost), pick two, and the third will magically follow. (It is determined by the other two.) Scope means features (or delivered functionality), time means duration or deadline, and cost typically means number of developers or, more abstractly, available labor.Continue reading “Agile Methods and the Magic Triangle”
As noted previously, Scrum uses the term product to mean artifact. This is fine, as long as the user of Scrum is a software vendor, developing a product for a market. It is confusing, however, if the user is a consulting firm, performing a custom project for a client. If you are a consulting firm, you are not delivering a product, and every time you hear product, you need to think artifact.
The confusion is worst when we talk about a product vision. As always, there are many competing definitions and confused ones at that, but we can safely assume that a product vision is at least a particular type of vision. About a vision, by definition, we know that it is time-less. It describes an abstract future state that we want to achieve, but never actually can reach. As such, a vision serves as a guiding north star for the decisions we make about on-going work. IBM’s vision is (shortened) “client success”, SAP’s is “improved economy”, etc. Any number of management books expound on what a vision is so you can read more there.
In a previous blog post I noted how the terms project and product are being confused in open source. However, it is agile methods, specifically Scrum, where it gets really bad. To recap: A project is a human undertaking to create an artifact. A project, by definition, has a start date and an end date. A product, in contrast, is an artifact (not an undertaking) that is born but typically has no planned end date. Most vendors, selling products to a market, hope they can do this forever.
One of the most difficult aspects of Scrum is the role of the product owner. Most software vendors have a product management function, typically split into strategic and technical product management. Technical product management is usually equated with Scrum’s product owner role, that is, the guy or gal who writes business-value-oriented user stories and epics, grooms the product backlog, and then some. This is separate from breaking down business-oriented features into technical tasks, which is left to the engineering team.
The problem: A person who can do this well is hard to find. It is easy, though, to find someone who believes they can be a good product owner. In practice, most successful software vendors I have seen have a business-oriented strategic product manager for a given product or major component, and have a senior engineer play the product owner role, reaching all the way into product development, that is, not only writing users stories but also breaking them down into tasks.
I’m a strong believer in product management. It is the most critical function in product development. It took me many years to accept that good Scrum product owners cannot be groomed from MBA or other business-oriented degree programs. Almost always will you need someone with a technical background to fill that role or it will go off the rails. However, there are really few people who’d like to take on that job; they’d rather be programming. Therefore, you’ll have to ask a senior engineer or other engineering leader to collaborate with the strategic product manager and turn the roadmap into features that can go into a product backlog.
So, as I said there rarely is a (stand-alone) Scrum product owner; usually it is a senior engineer adding to their busy schedule to make things work out.
Agile methods reacquainted developers with the idea of working from business value rather than focusing on technical concerns only. Agile methods are therefore often equated with feature-driven development, in which work is driven by features prioritized by business value irrespective of technical consequences. This thinking can create code silos and wreak havoc on software architecture and component quality. Developer complaints are legion, in particular for never getting the time to fix things or do them right in the first place.
I updated this post after I realized that it is more about prioritizing user stories than it is about writing them well.
In Scrum, a product owner writes user stories to capture requirements and prioritizes them in a product backlog as the upcoming work queue for developers. The main question on my mind is:
Who has the capabilities and competencies to write good user stories and prioritize them in a product backlog?
The INVEST criteria list quality measures (of sorts) that determine what a good user story is. It should be Independent, Negotiable, Valuable, Estimatable, Small, and Testable. While fundamentally correct, there is much more to say. For example, in a product backlog, user stories should use a consistent vocabulary, based on a shared domain model (or glossary, at a minimum).
|Engineering Manager||Delivery Lead|
|Director of Engineering||Delivery Head|
|Vice President of Engineering||Delivery Hero|
I see a trademark conflict brewing… (not really, trademarks are scoped by domain, there probably is little confusion between a retail service and a corporate role).