This article is about Agile, iterative and incremental delivery, and how it can take such different forms even when it is based on the same values and the same understanding of the underlying framework -- i.e., Scrum.
I've had a chance to see Scrum in two different forms: Product Scrum and Project Scrum. Looks like a play on words, unimportant semantics, right? Maybe it is. However, depending on what we are actually delivering, Scrum can demonstrate a variety of behaviors. I'm not pretending to describe the full range of differences, just some key things that are in my mind at the moment.
A project manager (or someone who performs that role) has committed to deliver some scope to the business sponsors, has obtained a budget, and now has to deliver the project on time and on budget. Quality is not generally insisted to have an explicit definition. Sometimes it is treated as product delivery, where product=project.
The team is a project team.
They are good guys if they stick to the milestones and the major deliverables -- i.e., follow the orders. Innovation is good if it makes the project go faster. Long term, the team is justified by making velocity stable (see below, the most important metric).
If there are several teams, the management may tend to normalize (and in some frameworks may actually recommend normalizing) velocity for the teams, or even map it explicitly to man-hours (and at least this is honest). Why? Well, the counting is simple, in terms of comparison, performance management, etc.
is important when it is related to project delivery. As users may have intraday needs that are quite different from the project goals, they quickly cool down to the demos and giving feedback. The project team tends to say that users aren't interested in the success of the project, though they own half of the risk and should be interested in the result (or something like that).
The most important metric
is velocity. It tends to pop up from the micro level of the team to the macro level of the organization. For example, it's used in forecasting to know how many iterations the team will need to complete the project. At some point it can become a direct input to the budgeting process. Indeed, the fun starts when velocity is used to forecast the work for the next year (PERT'ed and weighted velocities are included). When managers see velocity, they tend to manage it so as to increase it. It looks OK from their point of view, mathematically, if it increases against the committed scope, so the project will go faster.
(generally adopted project management metrics):
Velocity of the iteration
Derivative of the velocity: Iterations to complete = story points left/Velocity
Budget to complete (simply how much money we have left)
Estimated cost of the project = estimated effort cost * the project duration; estimated effort cost is derived from velocity, i.e., progress is measured in terms of effort
A product owner commits to deliver a product to the business sponsors, commits to some explicit quality standard of the product, and maximizes the value of the product with each increment. The product is delivered incrementally.
The team is a product team.
They are good guys if they know the product and deliver value ($$) in the iteration. Innovation is good if it makes the product cheaper to operate, support, and engineer. (By the way, everyone is learning how to express any decision in $$.) Long term, a cross-functional team is an asset, because it delivers value with every increment. The more we keep this asset at hand, the more dividends it will generate.
ROI = Value / cost. If you have several teams working on the same product, you can calculate ROI for every increment the teams deliver.
is critical, more important than any delivery plan, as it gives input to prioritization of the features for the next increment. There is no problem in involving users in the delivery.
The most important metric
is ROI of the increment. Velocity and other micro factors (for example, the estimation model) are irrelevant on the macro level.
Value in $$ is delivered in each increment
Innovation, expressed in $$ as an operational/engineering cost-reduction delivered in the increment
Violations of the quality standard (expressed in $R if possible)
Cost of the increment = team cost in the iteration duration; constant if the team is constant and the iteration duration is constant as well