People and Process Redux

July 2, 2006 — Posted by Al Shalloway

Since I originally posted my people and process blog, and my people and process continued blog, I put it on the Lean Development user group (a great resource, BTW) and got some interesting responses. I highly recommend reading these two:

  1. Dale Emery's entry
  2. Mary Poppendieck's entry

as they say more eloquently what I was attempting to express (note: these entries require membership in the lean development group - if you are not a member it is easy to join - but I've put these entries at the end of this blog to make it easier for you)

One last point on this (until I rewrite this entire string of thoughts into a more coherent statement) is this:

In the statement "favor people over process", I am concerned about the word "over" because it implies conflict. There should not be a conflict between people and the process they follow. The process should support them, the people should update the process. The process acts as a baseline for change. Without it, you cannot have continual process improvement. But it always serves the people for which it is intended (developers and business people).

The idea of people and process, then, is to show that there is synergy and a necessity for both of these.

This is further illustrated by a definition of Lean Software Development I use in our Lean course:

Lean Software Development has the goal of delivering as much value to your customer as quickly as possible in the most efficient manner possible. The keywords here are speed and low cost. Accomplishing this requires your team to have a commitment to continuous process improvement. This requires management to both respect and empower the people involved. Only the team can create an effective process – management must facilitate this – not control them. Only by continuously improving your process, increasing quality of both your products and your process, can you sustain the high speed and resulting low cost.

----------------------------------
Dale Emery's Entry:

Re: [leandevelopment] Re: People and Process and a podcast on Lean-Agile
Hi Ron,

> I prefer Dale's formulation, which focuses on the real needs
> of all the people, to what seems to me to be a rote denial of
> a simple phrase in aid of some undescribed set of needs from
> an undefined group of people.

My sense is that the original wording doesn't encourage us to see
the people behind the process.

I've seen "people over process" invoked a number of times in
conversations in the agile/XP related lists. Some of those times
it seemed to me that the person invoking the preference was using
"people" narrowly, to refer only to the people who are charged
with carrying out the process. I didn't get the impression that
they were attending to the people the process was intended to serve.

Unfortunately, I can't point to any specific examples.

Any process description embodies somebody's wisdom about how to
serve some set of people. But process descriptions often omit
stating the underlying wisdom explicitly.

My worry is that "people over process" subtly discourages
recognizing whatever wisdom there might be in the process. I
think (but I don't know) that I've seen that happen.

Aside: I've written some guidelines for, among other things,
making the underlying wisdom more explicit. These guidelines are
about writing policies, but many of them apply to process
descriptions:
[his Articles now at http://dhemery.com/articles]

> I prefer what Dale has done, describing a powerful way to
> interpret those words, over denying them and replacing them
> with ... what?

Consider replacing them with words that leave more readers with
the ideas the authors wanted to express.

If I were contributing to the manifesto, I'd say that "process in
service to people" expresses my thoughts better than "people over
process." And in general, "we value the items on the right to
the extent that they serve the items on the left" expresses my
thoughts better than "while there is value in the items on the
right, we value the items on the left more."

For more, see [his Articles now at http://dhemery.com/articles/]

Dale

--
Dale Emery, Consultant
Inspiring Leadership for Software People
Web: http://www.dhemery.com
Weblog: http://cwd.dhemery.com/

-----------------------------
Mary Poppendieck's Entry:
RE: [leandevelopment] Re: People and Process and a podcast on Lean-Agile
I've been studying the rationale behind process standards lately, because
I've observed the proverbial pendulum swinging back from the extreme process
focus and headed the other way - with such momentum that I fear it will
swing too far.

What I learned in my research is that process standards at Toyota have a
very different purpose than you typically find. Standards are the best
current known way to do things, and as such, they are always followed. But
standards exist to be challenged and changed. For example, one former line
worker at a Toyota automotive plant posted a comment that line workers where
he worked were continually encouraged to challenge and change standards, and
any work team (~6 people) could and regularly did change standards. The
only approval they needed was to get the one or two work teams on the other
shifts doing the same job to evaluate and adopt the new standard.

The reason for standards, then, is to have a base against which the work
team can do experiments and prove that a new approach is better. If you do
not have a base, you cannot have improvement.

The other thing I learned is that at Toyota - where suggestion systems are
amazingly effective, the reason for their effectiveness is that suggestions
are not handed off to someone else; the person with the suggestion is
expected to implement it - by performing experiments and proving that the
new idea is better than current practice.

So think of process as the current best known way of doing things, while the
people using the process are expected to constantly challenge the process,
find better ways through experimentation, and implement the better way
without any need for approval from above. With this perspective on process,
people and process work together; you don't have to choose between one or
the other.

Mary Poppendieck
Author of Lean Software Development: An Agile Toolkit
www.poppendieck.com

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban