People and process Continued

June 5, 2006 — Posted by Al Shalloway

I put my earlier post on people and process on the LeanDevelopment user group. Some interesting comments have ensued, along with my response (included here). You'll get the jist of my points just reading below, but if you'd like, see the entire thread starting at http://groups.yahoo.com/group/leandevelopment/message/887?l=1

More...

Instead of responding to each message individually, I am going to give a summary here while embedding different comments by people.

There is no question that the purpose of a process is to serve people. I am very glad Dale pointed that out eloquently, but I guess I assumed everyone knew that. This _is_ a lean discussion group and I am a very strong evangelist, coach, trainer of lean. Lean’s roots go back to Deming who claims that 94%+ of errors are due to the process. His 14 points discuss how people are important and how management has to continuously strive to improve the process so people can get their job done. Much of this improvement is letting people themselves improve the process – since they are the one’s closest to the problem (known as “go to the gemba” in lean).

Lean takes on a bigger scope than does XP and issues that XP does not deal with are dealt with lean and require more complex (not more than necessary, but more complex nevertheless) models to explain it. One of these has to do with knowledge creation (one of Mary’s principles). How do we create, manage, and retain information?

In a small group, tacit knowledge works fine. In large organizations, it does not. How to manage the information so the process of the organization can serve the people is actually part of the process itself. Pairing, while awesome, is limited in the scope of what it can do. Do not read into this sentence that I am espousing large command-control or heavy documents. I am not. But I am saying that there is tremendous value in the process – when they are done correctly.

The fact that most processes are not done correctly does not mean that processes are inherently bad. Command and control processes are bad. But those are not the types of processes I (nor Deming) are talking about.

Some of the problem is that some people set up people Vs process, one or the other. Or, as Ron said, imagine that there are two directions on the line:

< --- agile/lean commandAndControl --->

However, agile and lean do not necessarily relate to commandAndControl in the same way. This highlights that agile and lean are different. Lean is much larger in scope. It might be appropriate to say that agile is the way to run an adaptive process, using iterations, validation, customer contact, high code-quality, … This is not what Lean is (although lean implies you must do this).

The over-simplification of juxtaposing lean/agile with command and control is it sets up a thought process that puts two things that must work together (people AND process) opposed to each other.

Lean is a combination of several things. From Taiichi Ohno, we can see that Lean Manufacturing is:

  • a strong respect for people
  • a relentless pursuit of a process that results in high quality

Taiichi bases his approach on Just in Time and autonomation as the main principles. He focused on process to create value to the customer while respecting people.
Lean includes the ideas of mindfulness as set forth by Weick and Sutcliffe in their Managing the Unexpected: Assuring High Performance in an Age of Complexity where they set out the points of:

  • Preoccupation with Failure
  • Reluctance to Simplify
  • Sensitivity to Operations
  • Commitment to Resilience
  • Deference to Expertise

Lean also is about knowledge management – creating, retaining and disseminating information.

In other words, process is all around us. I’m not referring merely to the command and control type which should not be in any process as far as I know.

Referring to Glen’s comment that “most large orgs I've worked in the ’process’ is an proxy for people who are not present at the time the other ’people ’ are making decisions.” This is clearly not the process I am talking about.

I agree with Ilja's comment about having to have an equally good reason to follow the process. Since the team builds the process in Lean (or had a voice in it at the very least) they should understand why they are following the process.

I do not agree, however, that it is all about the people as Ron said. I believe it is all about adding value to the customer while respecting the people doing the job and the companies involved.

I think the statement people over process ignores one of the biggest issues – transitioning to a better way of doing things. I’ll admit, I am primarily an educator. True, I do a lot of coaching, but it is always from the point of view that I won’t be there long (in fact, the shorter the better). My approaches are geared towards showing people how to do it themselves instead of having them watch me or requiring me to lead them. This requires me to somehow help them create models in their heads that are useful and can be expanded upon when I am not there. This is one reason I don’t typically use things like the very useful XP Koan of simple (incredibly useful if you continue to think about it – which most of my clients won’t).

If people can understand that they need a process that serves them and that they also need to continuously improve the process instead of just counting on their judgment, they will continue to improve as a team.

This is very clear when the transition starts. People don’t understand why up-front testing really works. Oh, they get enrolled in the idea of automated tests and some other ideas, but up-front testing has so many things going for it people don’t truly understand all of them at the start. So, for a little while, they trust the process of specifying tests and writing them before writing code. They refine this and make it their own before long.

This is a follow up to this post People and process redux

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