People and Process

June 1, 2006 — Posted by Al Shalloway

In making my starting entry on our Lean Software Development blog, I considered - "what should I blog about?" I figured, maybe a discussion about why I liked Lean so much might be appropriate.My beginnings with Lean actually go back to the 80's when I studied Edwards Deming. I found some of his ideas somewhat counter-intuitive then. However, the validity of his work had already been established in Japan. I have learned that when my models do not reflect reality, I have to change my models. If my underlying belief system doesn't reflect reality, I have to change that too (my underlying belief system - not reality). It is all too convenient (but not effective) to ignore incidents which refute our belief systems as anomolies. However, I have learned to not do this. In any event, although I didn't always understand Deming in my early studies of him, I always had the sense that his message was an important one.

I'll admit I'm not exactly sure now, what I found counter-intuitive because it seems really intuitive to me today. However, I do remember not understanding his intentions well until I read Mary Walton's book The Deming Management Method.

I loved the notion of the blend of people and process. People were responsible for what they did - but only within the context of an ever-improving process. They could modify (in fact, they were expected to modify) the process to improve it as they saw fit. But they couldn't deviate from it just on a whim, or just because that's how they liked to do things.

The reason the blend of people and process is so essential is that without it, bad things happen. Which bad things happen depends upon which (people or process) gets the upper hand. Let's start with the more familiar one - process over people. In this scenario, people are told to follow the process. This process is often bureaucratic, doesn't address the needs at hand and leads to incredible inefficiencies, errors, poor morale and other things we'd like to avoid. The irony is that the heavier the process, the more likely it is to be ignored. I have worked with more than one company where ineffective processes called for filling out certain information that was to be used to guide the process. What happened was that people ignored the process and simply filled out the information after the fact (when it could do no good) to make it appear as if the process were being followed. The best example of this is the project that created Pert (the Polaris Missile System). Read The Polaris System Development: Bureaucratic and Programmatic Success by Harvey Sapolsky to learn how PERT was actually created by the team as a facade to Congress to hide how they were actually doing the project. Ironically, the great success of the Polaris Missile System development project resulted in PERT being considered an essential management tool since the success of the project was inaccurately partially attributed to Pert.

Let's look at the alternative. While many developers rant and rave at the insanity (doing the same thing over and over again and expecting a different result - Ben Franklin) of heavy methods, they ignore the alternative left to management when it is people over process. Given the two main development paradigms (leaving Lean out for the moment) available to people (craft and manufacturing) management picks manufacturing. Even though this is inappropriate, it is not surprising. Their alternative, craft, means that they are putting the future of their company in the hands of artisans - not a necessarily comfortable thought.

Actually, if software developers operated as true craftsman, this might not be that bad. True crafts have an apprenticeship program. You learn from an expert, you learn the basics of the craft and then add your own flavor to it. But in the world of software, we like to be craftsmen without having to obey the rules of the craft. Arguments such as "I have as few classes as possible because that's the way I like it" almost sounds acceptable and unfortunately, at least familiar. Conversely, saying "I like to have different methods in different classes because that's the way I like it" is equally unacceptable. If there is a set knowledge of the craft (such as cutting against the grain in wood leave a rougher scar on the wood) then we should do those things because they work, because they are standards of the craft. Just picking up a saw (or a book on programming) and starting to cut (program) without learning these rules (cohesion, coupling) is a foreshadow to danger. Actually, in a craft, doing things because you like them may be ok - you may be creating art. However, our work as software developers is not to create art - it is to create tangible value to our customer.

What we have (or should have) in software is more of a profession - professionals working together taking advantage of a set body of knowledge. This does not mean slavishly following a process - it means taking advantage of what others have learned and applying it. I believe there is an interesting (if somewhat macabre) parallel between where we are now and where the medical profession was in the late 19th century. Consider Ignaz Semmelweis. From The Wikipedia:

  • Ignaz Philipp Semmelweis (July 1, 1818 - August 13, 1865) was the Hungarian-Austrian physician who demonstrated that puerperal fever (also known as "childbed fever") was contagious and that its incidence could be drastically reduced by enforcing appropriate hand washing behavior by medical care-givers. He made this discovery in 1847 while head of the Maternity Department of the Vienna Lying-in Hospital.

This was before the germ theory of disease. I can almost hear the conversation now about how there are tiny little things you can't see causing people to die! Surprised they didn't put him away (actually he did suffer a nervous breakdown eventually and was institutionalized where he died).

Continuing on from the Wikipedia:

  • Although Semmelweis could not present a theory of why doctors should wash their hands, he was able to establish the veracity of his methods. Nevertheless (also from The Wikipedia) It was also "argued" that even if his findings were correct, washing one's hands each time before treating a pregnant woman, as Semmelweis advised, would be too much work. Nor were doctors eager to admit that they had caused so many deaths.

I can almost hear people telling me why it is too much effort to write up-front tests. ;) The point is, there is a body of knowledge all developers need to be aware of and follow (and management needs to require them to do so). What is this body of knowledge? Well, much of it is up for dispute - but much of it isn't. Having attended and presented at conferences for 10 years, I am certain that there is more agreement between the presenters on what quality software is than disagreement. The bottom line is developers are not free to do what their "craftsmanship" tells them to do. At least not in situations where there is general agreement amongst the thought leaders of the industries.

Hence, I do not like the "people over process" statements I hear so much in the agile community. I actually believe this comment is an over-reaction to the long history of process over people. But, given it's statement by our thought leaders, it is easy to abuse. We definitely do not want process over people. But people over process implies that we can condone people doing what they want regardless of the merits of the process. The intention may be different, but I am a stickler for attempting to say things correctly because people will mistake things not stated correctly (actually, they will mistake things even stated correctly, so let's not give them a head start).

Anyway, people and process is much closer to the truth to me. People are at the top of the value chain (what we value). But so is process. Mary and Tom Poppendieck's excellent Lean Software Development: An Agile Toolkit for Development Managers has 7 principles of Lean. Two of these are:

  • Create Knowledge
  • Respect People

(Actually, this is what they call them now in their upcoming second book. In this book, they were called "Amplify Learning" and "Empower the Team").

Interestingly enough, "Create Knowledge" goes both ways. If you are creating, re-using and not losing knowledge, you must have a process in which to capture, retain and use it. If you rely on verbal communications alone you clearly are not going to be able to help a 2,000 person organization. Taiichi Ohno (the father of Lean) is relentless in his improvement of process and elimination of waste. But running throughout Toyota's Lean methods are respect for people in the process, an expectation of their guiding the process.

To me, implementing Lean Software Development is therefore the finding the proper blend of:

  • people
  • process
  • structure
  • knowledge

for the development team. All are important.

How we do this in future blogs. :-)

There are two follow up blogs to this:

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