Comments for Barry Hawkins

Comment on Empirical Process Control: Why Scrum Works by Mix Up Your Acceptance Criteria - Chris Steele on Agile

Mix Up Your Acceptance Criteria - Chris Steele on Agile — Thu, 30 May 2013 18:37:36 +0000

[...] the team, the knowledge of the product owner, the clarity of the test, and other factors. Taking an empirical approach is always a good idea in an agile environment, and there is no exception here – blindly following [...]

Comment on Ask an Agile Coach: What is an Agile Coach? by Carl Shea

Carl Shea — Fri, 01 Mar 2013 20:29:12 +0000

Great post, my answer is a little late, but it has recently become my personal soapbox. We are over using the term coach. I believe we can be an Agile coach, but we need to have and understand when we are using coaching skills and trying to nurture and facilitate our clients using their experience, vs. we are being an Agile consultant (LOL – probably not the right word either) directing and sharing of our experience through mentoring and teaching. Most in the Agile world calling themselves coaches are neither…

But then we have always been lackadaisical in our title naming; I won’t start on the title Certified Scrum Master!

One thing I will disagree with you on is that coaching skills will not add value, in fact, I strongly believe and have experienced that someone with both strong Agile and individual and/or system coaching skills will achieve better and faster transformation of a client. LOL – just my two cents

Comment on The Principle of Slices Instead of Layers by Alex Harlap

Alex Harlap — Fri, 01 Feb 2013 20:35:00 +0000

But cakes ARE made in layers and not in slices, and for a reason!

Comment on Ask an Agile Coach: What Team Members can be shared across multiple Scrum teams? by Ken Grossenbacher

Ken Grossenbacher — Thu, 31 Jan 2013 00:50:40 +0000

In Agile terminology, what is the difference between a “Shared Resource” and a “Consultant”, each of whom might provide services to an agile team, but not be full time or permanent members of that team?

Comment on Empirical Process Control: Why Scrum Works by App Square

App Square — Fri, 21 Dec 2012 01:34:05 +0000

Thanks for explain that Scrum was designed to enable empirical process control for software development.
I really want to know briefly about it:)

Comment on Ask an Agile Coach by Anthony Markos

Anthony Markos — Fri, 13 Jul 2012 19:45:37 +0000

Question: I work on business systems. Business systems tend to be complex. Effective decomposition is needed to handle complexity. How is decompostition achieved in an Agile project?

Comment on The Discipline Deficit by jay

jay — Fri, 04 May 2012 10:42:49 +0000

instead it is not different they are Agile/Lean practices and processes are neither substitute nor remedy for hard work,

Comment on Empirical Process Control: Why Scrum Works by The Chronolgist

The Chronolgist — Thu, 19 Apr 2012 13:53:07 +0000

Sorry! I maybe missed a smiley or two. You get them here:

:-) :-)

Anyway: If you are truly driven by the empirical approach, then you should be open to experimenting approaches, and pick the one that works for *you*.

One size fits all (whether you call it Scrum, TOC or whatever), does never work. You have to adapt the process to the organization, and not vice versa.

Many Scrum practitioners see Scrum as a panacea that cures everything. There is a lot of elitism in Scrum, too. (Note: This is not directed at you. It is just an observation. In general, *any* school of thought that has produced any result sometime, somewhere, will generate elitism in one way or another. Especially when it gains a following.)

Take any suggested approach – whether Scrum, TOC, or other – with a grain of salt.

So how do you know what works? You don’t.

Instead: make an experiment and find out. Maybe it turns out to be Scrum. Or TOC. Or something else.

Some approaches are more, or less, prescriptive. Those that are less prescriptive, truly require you to sort things out (i.e. think) by yourself. With this respect, Scrum is definitively more prescriptive than TOC or Software Kanban. That is one reason why Scrum is easier.

Comment on Empirical Process Control: Why Scrum Works by Barry Hawkins

Barry Hawkins — Thu, 19 Apr 2012 13:02:32 +0000

Careful, I think your elitism is showing:

“[Scrum] is so pragmatic, even “managers” seem to understand them…”

“The hardest part of TOC is that it requires practitioners to… you know… think by themselves.”

I see far too much of that type of condescension among proponents of TOC and the method called Kanban (not the original kanban the visual control system from Lean Manufacturing). When the message “these are all the same” is accompanied by that sort of thing, it translates to “we say these are all equal, but really we think the others are rubbish and ours is best because we are sophisticated and elite.” It’s rather polarizing and unproductive, and symptomatic of an unhealthy culture.

Comment on Empirical Process Control: Why Scrum Works by The Chronologist

The Chronologist — Thu, 19 Apr 2012 11:51:17 +0000

Barry, You’re absolutely right. Scrum has to its advantage that it is based on “simple rules” that anybody can understand. It is so pragmatic, even “managers” seem to understand them…

TOC, on the other hand, is even simpler than Scrum. (See “five focusing steps,” etc.), The hardest part of TOC is that it requires practitioners to… you know… think by themselves.

The point I stress is that you cannot know a-priori which approach works in a given organization. Some will pick up Scrum and find it good. Others will fly with Kanban. Others with TOC. Others with Lean. The unifying thing is: the foundation in empiricism that underly all these approaches.

The title of your post “Why Scrum Works” is spot on. It works because it is based on empiricism, feedback loops, inspection, self-reflective improvement, etc. It is the same for the other approaches mentioned too.