Shades of Scrum: The Sprint Planning and the pull principle

April 15, 2013 at 8:02 pm 4 comments


The Scrum Sprint Planning incorporates the so-called pull principle. The pull principle origins from the Toyota Production System (at least it is he first occurrence I know of) and aims at creating flow while avoiding overload. A processing unit B pulls new work from an upstream processing unit A when B hast he capacity to process it. This is in contrast with the push principle where a planner defines how many items should be processed by time unit and results of upstream processing unit A are pushed into the downstream processing unit B.

In the Sprint Planning the team pulls work from the Product Backlog (the Scrum Guide says that the development team „selects“ Product Backlog Items for the Sprint).

One re-occurring question is whether the team is allowed to deviate from the prioritization – for example when a Product Backlog Item is too fuzzy or when the development team thinks an Product Backlog Item is just bullshit.

The answer is: it depends.

The very first reason fort he pull principle is to avoid overload with its negative consequences (lower quality, burnouts, developers quitting jobs etc.). Therefore it is totally valid to expect the team to pull work strictly according to the prioritization. While older literature is sometimes a bit ambiguous about the „selection“ of Product Backlog Items the current version of the Scrum Guide is pretty clear about that: „The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team.“ (emphasis added by me)

But.

Kent Beck once told me that he likes to ask developers if they would invest their own money into the product they are working on. I use this question from time to time when working with teams and I will never forget a larger retrospective at a client where I asked the team exactly Kent’s question: „Would you invest your own money into the product you are developing?“ The team laughed and answered: „We think it would be more valuable to buy Greek government loans.“

That is great feedback for the Product Owner. The team isn’t convinced about the product but it should be (remember the Scrum value „commitment“). The Product Owner should start asking questions: Is the product idea bullshit? Does the prioritization of features lead to weak product while the product idea may be great? Does the team lack the information about the market and users needs to understand the product and the prioritization of features? Working with these questions provides the opportunity to enhance the product a lot. But it requires hard work on the side of the product owner.

A Product Owner who is open for these kinds of discussions may apply the pull principle not only for limiting the amount of work to the team’s capacity but also to the meaning of work. The team would only pull Product Backlog Items into the Sprint when it is convinced that these items are valuable fort he product.

I have seen a lot of confusion about these two types of the pull principle. To make clear what we are talking about we could call the original pull principle „workload pull“ since its motivation is to find the optimal workload. The extended pull principle could be called „purpose pull“.

The workload pull delegates the decision about how much work can be done to the team. The purpose pull delegates the decision about what should be done to the team.

How much?

Pull

Workload Pull

Purpose Pull

Push

Traditional Project Management

X

Push

Pull

What?

Valve (a company famous for its computer games) applies purpose pull on a product level. Developers choose the products they are working on. If a Product Owner has an idea for a new game but is not able to motivate developers to join his project the game wouldn’t be implemented. (see http://assets.sbnation.com/assets/1074301/Valve_Handbook_LowRes.pdf)

Typical open source projects apply purpose pull on the product level as well as on the feature level. Everybody decides for himself on what product to work (and is free to quit whenever he is fed up) and within the product development the developers are free to choose the features to implement.

The following table summarizes the two pull principles:

Workload Pull Purpose Pull
Create flow of work Create better products
Avoid overload Provide meaning for the development team
Enhance work satisfaction of the development team
Avoid quality problems due to overload Avoid quality problems due to decoupling of the team from the product

Scrum as a framework supports workload pull as well as purpose pull. (Applying purpose pull to the fullest possible extend would eliminate prioritization by the Product Owner completely and then you leave the Scrum framework). Every project has to determine the appropriate pull level.

Entry filed under: it-agile-blog-planet. Tags: .

The Sprint and the ROI Shades of Scrum: Scrum outside IT

4 Comments Add your own

  • 1. Ralf Westphal  |  April 15, 2013 at 9:08 pm

    The team is pulling its work from the PO. Great.
    But who/what´s pulling on the team?

    Unless the pull principle is not originating from, well, the people who really, really are in desperate need of the software… the team won´t feel any purpose.

    But adding requirements to a backlog is not pulling on the team. It´s pushing. So where´s true pull on the team?

    Is that QA? No. QA does not need the software.
    Is that the PO? No. Firstly he/she does not need the software either. Secondly it would overload him/her with another role.

    So who´s exerting true pull on software development?

    I can´t help but view this link in the pull chain as missing in many, many projects.

    Interestingly that´s different in the world of technical open source. That´s why open source can be successful despite missing central planning, I´d say. It´s clear to every person submitting code who´s going to benefit from it. The demand, the longing, the pull is really tangible. And true, valuable, competent, honest feedback it readily given.

    No small wonder, pull is at play at Valve. Those guys are working in the same mindset as open source programmers. They are essentially working for themselves.

    But where´s the business software project living up to this pull gold standard?

  • 2. Shades of Scrum | Stefan Roock  |  August 9, 2013 at 9:53 am

    […] The Sprint Planning and the pull principle: The team pulls work into the Sprint during the Sprint Planning. The article discusses different types of pull. […]

  • 3. Debasish Bose  |  July 22, 2014 at 3:50 am

    It’s a manifestation of an eternal conflict between “what pays” and “what motivates”. My personal opinion is, unless you are working for scientific research (LHC or Genomics), the ideal sweet spot lies somewhere in the middle. However, B2B products sort of defy this in 90% of cases, most of the time it skews towards “what pays” !

  • 4. stefanroock  |  August 2, 2014 at 2:31 pm

    If what motivates people isn’t appreciated by the market you can’t build a business upon that.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed



%d bloggers like this: