Project vs Product thinking

[Mark Levison]

I've been trying to enumerate the differences between Project and Product mindsets but for some reason my brain has left my body and I'm so I'm here asking.

Project - is something with a fixed end date a moment by which all work has ceased. The problem is of course that work on a "project" rarely finishes, instead teams are expected to fix bugs, make enhancements etc.

Product - acknowledges that teams are really never done working on a product. It encourages the delivery of small features, frequent releases, continuous flow and releases that cover more than one "project".

Its funny I tried to find a good line from Johanna's book: Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, since this idea is at its core, but couldn't find anything more.

Thoughts? Better comments? More Detail?

Cheers
Mark Levison

Mark Levison | Agile Pain Relief Consulting | Certified Scrum Trainer
Agile Editor @ InfoQ | Blog | Twitter | Office: (613) 862-2538
Recent Entries: Story Slicing How Small is Small Enough, Why use an Agile Coach

[Steven Mak]

hmm, what drives you to asking the question?

I would also look at it with temporal dimension, where "Project" has a
"fixed" deadline while "Product" is continuously developed.

But I think it would help discussing if I can know the question behind
"Project vs Product".

BTW, the idea of "Continuous Product Development" is also covered
"Scaling Lean and Agile Development".

On Apr 25, 10:45 pm, Mark Levison <m...@mlevison.com> wrote:
> I've been trying to enumerate the differences between Project and Product
> mindsets but for some reason my brain has left my body and I'm so I'm here
> asking.
>
> Project - is something with a fixed end date a moment by which all work has
> ceased. The problem is of course that work on a "project" rarely finishes,
> instead teams are expected to fix bugs, make enhancements etc.
>
> Product - acknowledges that teams are really never done working on a
> product. It encourages the delivery of small features, frequent releases,
> continuous flow and releases that cover more than one "project".
>
> Its funny I tried to find a good line from Johanna's book: Manage Your
> Project Portfolio: Increase Your Capacity and Finish More

> Projects<http://pragprog.com/titles/jrport/manage-your-project-portfolio>,

> since this idea is at its core, but couldn't find anything more.
>
> Thoughts? Better comments? More Detail?
>
> Cheers
> Mark Levison
>

> [image: Mark] <http://www.flickr.com/photos/36331075@N00/3833840021/>*Mark
> Levison* | Agile Pain Relief Consulting <http://agilepainrelief.com/> |
> Certified Scrum Trainer
> Agile Editor @ InfoQ <http://www.infoq.com/about.jsp> |
> Blog<http://www.notesfromatooluser.com/>|
> Twitter <http://twitter.com/mlevison> | Office: (613) 862-2538

> Recent Entries: Story Slicing How Small is Small

> Enough<http://agilepainrelief.com/notesfromatooluser/2010/09/story-slicing-h...>,
> Why use an Agile
> Coach<http://www.notesfromatooluser.com/2009/11/why-use-an-agile-coach.html>

[Alan Dayley]

Some thoughts that come to mind:

- Sometimes projects are appropriate.  For example: An existing product is brought back into active development to add a specific set of features.

- Project thinking supports silo organizations.  For example: Split the product needs at boundaries that match your departments.  Define a project for each department that feeds the product.

- Silos all the way down, even to the individual, tend to be in organizations that do everything as projects.

- Product thinking supports cross-functional communication.

- Products have dates and market windows to meet and so are not necessarily continuous.

- Products tend support thinking over the whole product life, inception to end.

- Projects tend to support isolation of parts and pieces, with boundaries that divide the product.

- In my opinion, product thinking results in better products and supports Agile thinking.  Practicing Agile in a project oriented environment is possible but runs into organizational culture issues more often.

Does that help?

Alan

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To post to this group, send email to scruma...@googlegroups.com.
To unsubscribe from this group, send email to scrumallianc...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scrumalliance?hl=en.

[Michael James]

On Apr 25, 2011, at 12:01 PM, Alan Dayley wrote:

> - Sometimes projects are appropriate.

I recently moved my family to a bigger apartment. That was definitely a project, per the PMI's definition: "to attain its objective and then terminate." "Resources" were only needed temporarily: the movers, the truck, the moving equipment, the cardboard boxes, the stuff to protect the carpet. I didn't actually make a Gantt chart, though in retrospect better upfront planning and risk analysis would have helped.

The pain starts when we try to use a good tool for the wrong job. "Project management" is the wrong tool for developing new products, for reasons people have already written on this thread.

--mj
http://ScrumReferenceCard.com

[jung...@gmail.com]

I think the difference comes from the mindset. The one who thinks he has a product knows that he needs the product to evolve and factors anything around it as secondary to the product. So they treat project or even methodology only as the means and not an end. But that does not mean they will not seek the working methodology, best tools, etc.

---

From: Mark Levison <ma...@mlevison.com>

Sender: scruma...@googlegroups.com

Date: Mon, 25 Apr 2011 10:45:18 -0400

To: agile-leaders<agile-...@googlegroups.com>; scrumalliance<scruma...@googlegroups.com>

ReplyTo: scruma...@googlegroups.com

Subject: [Scrum] Project vs Product thinking

--

[jung...@gmail.com]

I think the difference comes from the mindset. The one who thinks he has a product knows that he needs the product to evolve and factors anything around it as secondary to the product. So they treat project or even methodology only as the means and not an end. But that does not mean they will not seek the working methodology, best tools, etc.

-----Original Message-----
From: Michael James <mj4s...@gmail.com>
Sender: scruma...@googlegroups.com

[Mark Levison]

On Mon, Apr 25, 2011 at 1:36 PM, Steven Mak <stev...@gmail.com> wrote:

hmm, what drives you to asking the question?

Steve - I'm asking the question because I want to change language and mindset at my current client. I'm expecting them to replace Project with something like Feature (or Epic).

Cheers
Mark Levison

Mark Levison | Agile Pain Relief Consulting | Certified Scrum Trainer
Agile Editor @ InfoQ | Blog | Twitter | Office: (613) 862-2538
Recent Entries: Story Slicing How Small is Small Enough, Why use an Agile Coach

[Michael James]

On Apr 25, 2011, at 4:16 PM, Mark Levison wrote:
> Steve - I'm asking the question because I want to change language and mindset at my current client. I'm expecting them to replace Project with something like Feature (or Epic).

Would "release" fit for them? A release typically has something in common with "project": a delivery date.

--mj
http://ScrumReferenceCard.com

[Dan Rawsthorne]

I also like to simply think of Releases as the fundamental unit. It allows a continuum from Story to Sprint to Release, and then I think of  Portfolios as a collection of potential Releases. ties together for me...

Dan  ;-)

[Andrea Tomasini]

On Apr 29, 2011, at 9:45 AM, James O. Coplien wrote:

Hi Jim,

> I avoid teaching this in Scrum, and I hate release burn-downs. This perspectives leads to a lack of team commitment to the fundamental unit: the Sprint. Teams miss a sprint commitment and say, "Oh, well, the fundamental unit is the Release, so I don't have to worry about it until then."
The fact that a tool is misused doesn't mean it is a bad tool...

> This, to me, is why every Sprint is potentially shippable. Every Sprint is a release. To formalize any other concept of Release is to ignore some of the fundamental disciplines of Scrum, and the result is the same as in old waterfall projects that plan for the next release instead of partnering with their consumers to inspect and adapt on a month-to-month basis.
It is definitely true, the Sprint is the smallest unit of time in which the Empirical Process Control takes place, by being able to inspect the Product as a whole integrated and shippable thing... that doesn't mean though that in one Sprint you would be able to produce enough value to justify to actually ship right? So I see the Release container as a very good tool for the Product Owner to be able to monitor the value accumulated and consolidated and decide (based on the business model) when it make sense to actually release the product.

> I think that this practice of a release focus and release burn-down with a granularity other than Sprints demonstrates either a lack of appreciation for Scrum fundamentals, or weakness of Kaizen mind.
I think the Release make sense for the Product Owner to measure the readiness of the product toward market expectations, at the end of the day the Product Owner "only" make his inspect & adapt on the product at the Review Meeting, so while the team can work on objective quality during the Sprint (which is their responsibility) the Product Owner can work on subjective quality (usability, value perception, business performance, fun factor in using the tool...) and adapt the Product Backlog for the upcoming Sprint(s) accordingly... is that so bad?

Ciao & Thanks
ANdreaT

[Mark Levison]

Damn - you take a few days off to hang out with family and your thread takes off :-)

On Thu, Apr 28, 2011 at 11:29 AM, Dan Rawsthorne <dan.raw...@drdansplace.com> wrote:

I also like to simply think of Releases as the fundamental unit. It allows a continuum from Story to Sprint to Release, and then I think of  Portfolios as a collection of potential Releases. ties together for me...

I thought about releases but my problem is that sometimes meaningful/valuable work is smaller than a release but bigger than a Story. Hence my picking Feature which can scale from a few stories to a couple of epics. At least it does in my definition.

 Cheers 

Mark Levison

Mark Levison | Agile Pain Relief Consulting | Certified Scrum Trainer
Agile Editor @ InfoQ | Blog | Twitter | Office: (613) 862-2538
Recent Entries: Story Slicing How Small is Small Enough, Why use an Agile Coach

Dan  ;-)

[Dan Rawsthorne]

But can meaningful work be work that is not released? where released means moving from the team's environment to some other environment for some other reason... so that moving the compiled code into a test lab for some other team to do usability testing is a release, for example.  Dan  ;-)

[Mark Levison]

On Mon, May 2, 2011 at 4:04 PM, Dan Rawsthorne <draws...@gmail.com> wrote:

But can meaningful work be work that is not released? where released means moving from the team's environment to some other environment for some other reason... so that moving the compiled code into a test lab for some other team to do usability testing is a release, for example.  Dan  ;-)

Ahhh - when I say release I mean deployed to production. In addition I have a strong preference for selling/making money from it. That's released. Since my current client is ready for continuous deployment (monthly releases right now). Several Features sit inside a release.

Cheers

Mark 

[Dan Rawsthorne]

I call that a "go-live" release as opposed to an alpha, beta, or other release.  Dan  ;-)

[Stephen Palmer]

From Planning Extreme Programming: "A user story is a chunk of functionality (some people use the word feature) that is of value to the customer.

From A Practical Guide to Feature-Driven Development: "A feature is a small, client valued function expressed in the form: <action><result><object>"

FWIW: In FDD, features are defined within activities and activities within areas. Initial cross-team planning is done at activity level, feature teams do iteration planning at feature level, building the group of features that make the most sense to develop next. More at  http://www.step-10.com/SoftwareProcess/FeatureDrivenDevelopment/index.html

Steve

Stephen R. Palmer

Certified Scrum Practitioner 2009, FDD Associate, Coad-Certified Mentor

Author of 'A Practical Guide to Feature-Driven Development'

http://www.step-10.com,

http://www.twitter.com/stephenrpalmer

On 2 May 2011, at 23:14, Steve Berczuk wrote:

I was going to say "not to pick on your words.." but since we're talking about words and definitions, that is what I'll do ;)

What's the value of having a concept like "Feature" that you measure when it overlaps with the already measurable items below (based on your definition.)

It seems like "story" and feature can map closely, or a "feature" can be a sprint theme (perhaps for a short sprint).

It's almost like saying that you want to measure "the thing I want to measure." 

I find value in the working within the constraints of stories, sprints, even releases... there is less to decide about the form of how you organize you work, and you can spend energy arguing about more important things (like what color index cards to use! :) ) 

Steve

--
Steve Berczuk  | steve....@gmail.com | http://www.berczuk.com
 SCM Patterns: Effective Teamwork, Practical Integration
     www.scmpatterns.com

[Dan Rawsthorne]

The phrase "potentially shippable" has little to do with shippability. Here is the definition from Ken:potentially shippable means that the increment consists of thoroughly tested, well-structured, and well-written code that has been documented and built into an executable reviewable by the Stakeholders [Ken Schwaber, The Enterprise and Scrum, Microsoft Press, 2007, pg. 112, paraphrased]. As you can see, it has nothing to do with amount of functionality; it has everything to with technical quality.

Dan  ;-)

Dan Rawsthorne, PhD, PMP, CST
Author of Exploring Scrum: the Fundamentals