Re: [scrumdevelopment] Re: Origins of Scrum
- i was talking about the contrast between
"Repeatable/Defined/Prescriptive process" versus "empirical approach",
suggesting that "empirical approach" is a meta-process. "Principles"
and "Values" could also be considered meta-process components.
> The biggest difference is attitude. Defined/Prescriptive is based on Frederick Taylor's
> approach in Scientific Management. If you lay it out perfectly in a plan and follow the
> plan, you will achieve your goal. The empirical approach says that the complexity is
> too great to rely on any plan. Lay out goals and proceed, keeping your eyes open
> and doing your best to achieve the goals.
On 7/1/07, Alan Shalloway <alshall@...> wrote:
> --- In firstname.lastname@example.org, "Keith Ray" <keith.ray@...>
> > Process or meta-process?
> > Part of scrum is the team (aided by the ScrumMaster) "identifying and
> > removing roadblocks", but roadblocks, other than being an impediment
> > to progress, are not defined, and HOW to remove roadblocks is not
> > defined at all. But I would consider "removing roadblocks" to be a
> > meta-process - a process in which "how to escalate an impediment" is
> > defined, but the rest of it is not a defined process.
> It is not possible to have a "how to" remove impediments for unseen
> impediments. This is where a balance between principles and practices
> comes can be useful. In the stock market, the practice "buy low sell
> high" makes sense but is not necessarily possible to follow. Nor does
> the advice assist in taking the obviously correct action.
> While I cannot give you a set of practices that will remove
> impediments, I can give you some things to look for that often help in
> removing them. A common impediment to members of teams practicing
> Scrum are rooted in delay. Delay from when information is obtained
> until it can be used. Delay from a request being made until it can be
> fulfilled. Delay from writing code until it is tested. Delay from
> completing code until you can show the customer and get feedback.
> I suspect you will find that delay is underneath many of the
> impediments that afflict a Scrum team. I believe this insight is a
> very powerful one. The nice thing about it is that we can look back
> on our own experience and often see that delays cause waste. Delays
> typically are due to doing an action too soon (e.g., too much
> analysis) or not being able to do follow up actions soon enough (e.g.,
> showing results to a customer).
> I myself got this insight by understanding Womack and Jones' view of
> fast-flexible-flox as a metaphor for Lean. They discuss that anything
> that is an impediment to flow is wasteful and that we should always be
> striving to eliminate waste.
> Many Scrum practices are consistent with this simple idea and I do not
> believe any are inconsistent with it (some are not related to time).
> Please let me know if this helps.
> Alan Shalloway
> CEO, Net Objectives
> To Post a message, send it to: scrumdevelopment@...
> To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
> Yahoo! Groups Links
C. Keith Ray
I n d u s t r i a l L o g i c , I n c .
866-540-8336 (toll free)
- Hi Alan,On 7/5/07, Alan Shalloway <alshall@...> wrote:I have made several posts illustrating these connections.
Ironically, there has been more discussion on my restatement of
_Jeff's_ assertion (as if _I_ had come up with it when I have
already said isn't that important anyway) than there has with
whether my comments about using Lean in the way I do is correct or
incorrect. I am certainly interested in people's opinions if they
think my posts are useful, useless, questionable, unclear, concise,
Thanks for clarifying that, Alan, it was a bit annoying that others seemed not to understand your intent. I can't comment on your use of Lean except to say it makes good sense to me (I am knowledeable, but can't claim to be an expert in Lean). I would like to emphasize another point of yours in the Agile methodology realm where I can claim expertise (or at least old dog status). That is, you first distinguished principles from practices, then said something to the effect that Scrum does not have clearly articulated principles (unlike XP or Crystal, for instance), even if the practices are quite clear.For me, this was a very useful observation. It is a big gap, IMO. Dave Barrett (above) did what I take to be a good first draft at articulating some principles, but these have clearly not been validated by the Scrum community. I believe, as Dave indicated, they the underlying set of Scrum principles are few and simple, but unarticulated nevertheles.Does that make sense to others? or do the rest of you just believe that that would be helpful? Again, the principles in an Agile methodology do not change (though they might slowly evolve), whereas the practices are adapted by a self-organizing team and a competent coach according to experience and circumstance (and using the applications of the relevant principle).
Michael K. Spayd
Cogility Consulting Solutions, LLC
"Business Mind, Social Heart"
"Leading Agile Enterprise Transformations"