Tuesday, 10 October 2006 - 6:16 PM EDT

I think perhaps my post wasn't very clear. I don't see people over process as a weakness of Scrum or Agile. I agree it is a strength. I focus on process only to the extend which is hinders or helps the team.

What I see as a problem is focussing on people over features -- emphasizing that people are 'fully optimized' rather than that features are being completed at an optimal rate. This is what happened with my Scrum team.

I don't think this is a problem with Scrum. Rather, it is a pitfall that is easy for beginning Scrum teams (used to a more command-and-control form of management) to fall into. As you mentioned in a comment on my blog, it mostly boils down to incorrect implementation of the process.

My main goal was not to blame Scrum for our problems. It was to point out some tools which made it easier for us to do the right thing. This doesn't mean I think the process is responsible for our success or failure. It just means that some tools will always be more helpful than others (depending on our context), and we must keep our eyes open and choose those that are most useful to us. The team itself will always be the primary factor which will determine our success or failure.

Wednesday, 11 October 2006 - 9:35 AM EDT

Thanks for the clarification. I'm sorry I misunderstood your point. Unfortunately, there are a lot of people in the industry who really do doubt the value of people-over-process. For them, I think it boils down to a fear of falling.

To your point, I can see how some people might interpret agile principles to mean that the whole purpose of a project is to make work fun and easy for developers. Of course, that's not the purpose. IMO the reason work turns out to be more satisfying is that we can deliver better value to our customers, and we're directly in touch with the customers so we can hear their feedback (usually positive). But to lose sight of the real purpose of a project is clearly a mistake. I hope you will be able to help the team in that regard.

Thursday, 19 October 2006 - 6:14 PM EDT

Lean does in fact value people over process.  Lean comes from the Toyota Production System.  Steven Spear and H. Kent Bowen in their article "Decoding the DNA of the Toyota Production System" show that there is one central tenet on which TPS and therefore Lean are built:

All work processes are controlled, scientific experiments, constantly modified and improved by the people who do the work.

This tenet clear puts people before processes.  This page contains a good summary of the article, but I recommend that you try and read the original, it is worth, IMO, the $6 HBS charges for it.

As well in the Poppendieck's  latest book: Implementing Lean Software Development chapter 6 is all about "People" and they make very clear that it is people before process.

I distinguish between Agile and Lean by observing that Lean focuses on improving how to deliver value to customers by through continuously eliminating the sources of waste that occur between when a customers asks for functionality to when it is delivered to them.

Friday, 20 October 2006 - 8:03 AM EDT

Norbert,

Thanks very much for your comments. I have a feeling we're saying approximately the same things, but we interpret certain details a bit differently. I'm aware of the origins of the idea of lean software development, and (I think) I understand it reasonably well. I address your comments in a separate blog post.

Tuesday, 24 October 2006 - 11:22 AM EDT

I don't think its as clear cut as you put it, my understanding is that lean, in all forms: lean software development, lean production, lean product development and any other lean, does put people ahead of process.

My reasoning is thus:

- Lean is a set of tools and way of thinking to eliminate waste

- Eliminating waste is a learning activity

- Therefore Lean is rooted in ideas of the Learning Organization; true Toyota were practising lean before the term Learning Organization was invented but the principles are the same

- Processes cannot learn.  Only people can learn, through people learning the process is improved and waste elininated.  Therefore, people must be put above process.

Or, to skin it another way:

- Toyota embodies the thinking of Deming

- One of Deming's 14 points is: when faults occur it is the process that is at fault not the people, i.e. the process is there to serve the people and allow them to do a good job.

In my book Agile is an implementation of Lean principles, the only difference is that any particular Agile brand (XP, SCRUM, etc.) implements those principles in different techniques.

Tuesday, 24 October 2006 - 1:04 PM EDT

Allan,

I see your point, and I think your reasoning is sound. I like the Deming reference, too.

In theory, you're probably right. In practice, agile and lean are so similar that they may be treated as variants of the same thing to a large extent. But your argument is based on process theory, and I still see practical differences in application. The people-over-process idea is a key difference I perceive between agile and lean, and I think it has implications for how we can approach specific customers, based on their cultural values.

Here's the key thing, as I see it: A lean process may be implemented in a real organization whether or not that organization genuinely embraces the agile value of people over process. The "mechanical" aspects of lean development add value by reducing waste. When an organization's existing processes are very wasteful, this can represent a significant improvement. Improvement on that level can be achieved even when an organization retains a cultural emphasis on process over people. Of course, results may be even better when cultural change can be realized, but cultural change is not a prerequisite to success with lean development, because there's still enough of a process framework to keep things moving in more-or-less the right direction.

In contrast, an agile process cannot be successfully implemented in an organization that fails to internalize and live by the principle of people over process. It's a show-stopper. A "fully" agile process (if I may use such a term without offending those whose working definition of "agile" is broader than mine) is completely dependent on people to do the right things without supervision and without being "driven" (or maybe "guided" is a nicer way to put it) by formal process steps.

Both agile and lean processes call for a people-over-process mentality in theory, but I doubt most IT organizations can actually establish that sort of mentality in practice. When they can't...when there is an institutionalized fear of falling...lean methods still offer an excellent approach to process improvement. I wish that sort of fear were not so prevalent in the industry, but wishing won't make it so. The next best thing is to deal with it pragmatically.

I'm not sure why people argue as if this were a bad thing. On a practical level, it seems to me to be an entirely good thing. It gives us a lot more scope to help customers improve the effectiveness of their IT operations, since we need not require them to undergo a painful and difficult cultural change before they can even attempt to apply the methods we recommend. By recognizing this difference, we can more accurately match a proposed process change to the realities and capabilities of a given organization, and possibly avoid the sort of failure that can occur when we expect too much cultural change too rapidly.

I just don't see the conflict, unless it boils down to the fact that it doesn't "sound good" or "feel good" to say we can work with a process-over-people mentality. I can relate to that on an emotional level, but I still can't avoid the fact that many organizations won't easily make the cultural shift "all the way" to agile...at least, not quickly. That's because it requires an honest change in the way people think, and that is a much greater challenge than to ask them to change the procedures they follow in their work.

It makes sense to me to deliver the value-add that is practical at the moment, and then to build on that foundation to promote incremental improvement. Eventually, the cultural change may occur...or it may not. Either way, we have to be pragmatic about what will or will not work on a case by case basis. I worry that if we ignore this key difference we may miss opportunities to offer customers the level of help they are able to absorb. If we go that way, what will be the use of winning an argument about whether A is more "agile" than B, or vice versa?