Product Scrum and Project Scrum

21 October 2013

Alexei Zolin
Deutsche Bank



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. 
 

Project delivery 

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. 
 
User feedback 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. 
 
Metrics (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

Product delivery 

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. 

User feedback 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. 
 
Metrics: 
  • 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



Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4 (1 ratings)

Comments

Phillip Stiby, CSM, 10/21/2013 4:36:47 AM
Product scrum comes in 2 variants....

Milestone delivery and continuous delivery: this alone I have worked on all three of the above and the key reason for milestone and continuous and the virtues of continuous is that milestone delivery to the team is very much the same as project delivery.

The product owners are driven by the PMO and marketing teams who are using the product road map to make up the sales pipeline, the next version of the product is a major release set in 6 months time with functionality delivered monthly which is not necessarily customer facing with hardening sprints at the end.

Now the continuous delivery or the SaaS business model isn't about getting customers to pay for the upgrade, these customers pay for the service each and every month in an easy to budget and manage way, and the business has to keep these customers by provided they user with constantly updating features and business benefits.

The scrum teams here were delivering value to the customer every spring, what you delivered in that 2 weeks was released to the customer.

No taking the classic product ROI which is if I invest in these features the sales team can close X deals worth Y currency. The business is managing risk, it spending millions over a 6 month period will see a return and profit over a period of time. Now an established SaaS scenario we have A customers generating B revenue and to maintain our customers we spend C of the revenue in developing the system either improving services, reducing costs through optimization etc..

That same business may then invest X to deliver functionality for new business which could generate additional sales and or increased revenue Y.

As an individual rather than charging customers i amount for a service/website which does j,k,l they pay a monthly amount which is more over time but ensures I am able to manage my workload and budgets whilst providing the customer with an ever evolving product which unlike there previous big bang approaches mean that 2 years after there investment they have an aging and out of date and very expensive project to refresh.

You must Login or Signup to comment.