Re: Technical Tasks in the Product Backlog
- A "product development management framework" strikes me as accurate and does not conflict with other meanings I attribute to those words.
--- In firstname.lastname@example.org, Adam Sroka <adam.sroka@...> wrote:
> On Mon, Jun 27, 2011 at 10:14 PM, gregc <greg@...> wrote:
> > Adam,
> > I've enjoyed many of your contributions to this list, but if I think you might be doing teams a disservice to describe Scrum as a "product" management framework.
> > Product management deals with identifying unmet needs in the marketplace that working with the development teams and company to create products and services to profitably address those needs. Tasks include customer research, business case analysis, market analysis, competitive analysis, product positioning, pricing, whole product definition, sales tools, launch plans, etc.
> > You might say Scrum is a framework for building complex products.
> Sure. How about "Product *development* management framework?"
> It's a fair point, but you out pedanted me, which doesn't happen often :-D
- Hello, Kathleen. On Friday, July 1, 2011, at 9:47:13 AM, you
> In some posts, there seems to be a focus on doing things 'by theYes, I do agree. And at the same time one does need to start
> book', rather than exploring the possibilities of other concepts
> or techniques that might be useful. It implies that the method is
> the 'one true way' of doing things, and that you don't need to
> learn anything else to be successful. Unfortunately, reality is
> way too messy for that to be true.
> To get really good at something, you need to go beyond mastery of
> a given method (or words of a specific master). You need to learn
> the underlying theory and principles (like what was mentioned
> before), then integrate the ideas and processes in new ways to
> deal with your current situation.
/somewhere/, inside the "safe region" for learning before you die.
Scrum purports to define part of the safe region.
> Creating new concepts should be encouraged. We should all beAgile got started based on the combined experience of a large number
> challenging the status quo and pushing for better ways to do
> things. Isn't that how agile got started? Why stop now?
of people who had observed a large number of teams for a large
number of years. It is possible that those people knew rather a lot.
It is also possible that teams starting out to do this stuff are not
yet qualified to make decisions about what to do and what not to do.
Show me the features!