Thursday, September 02, 2010

Stephen Kovacs on understanding the nature of Agile

I got a very thoughtful email from Stephen Kovacs on how to develop a deep understanding of Agile and Lean. I asked him if he would allow me to publish it. He did, so here it is:

This may just be throwing a half baked idea out. That said.... I was looking around on the net for some discussion of "lean", since people seemed to be talking about it as an alternative to Agile, and my sense of Lean was not an alternative. Perhaps a less structured version of Agile? (it seems to me Agile has become an umbrella under which Lean and others congregate).
I looked at a link to Wiki about Lean development, and from there to several links down into underlying theories (psychology, etc etc).. I keep coming up with the same thing: that Agile is an effort to pull together more humanistic theories of motivation and, perhaps, communication, into a working model.
And I keep coming to the same conclusion. The more effort put into creating the model (the rules?) , the more explicit the working model, the further away people seem to get from understanding and using the concepts.
This circles back to your description of systems. I wonder though if it also points to a weakness in a straight systems approach. Ie, is describing a system technically also another way to provide more detail about the model, where you lose understanding buried in the details?
For example. If you look at theories of motivation (intrinsic vs extrinsic)..... there a decent (I think) summary of those in wiki here http://en.wikipedia.org/wiki/Motivation . If as you read through these you start highlighting elements that seem obvious within Agile.... I think there's an aha moment in the effort. There's clearly a strong leaning (pun intended) towards a Maslow, even Rogers, approach. Maybe combined with some social interaction theory.
If you look at Measurements.... for example here http://en.wikipedia.org/wiki/Measurements and scroll down to Definitions and Theories.... the concept of story points etc., seem to be based, to a high degree, on "Representational Theory"... perhaps using representational theory to get to Information theory (??). Ie, accept the uncertainty of measurements, use ranges and relativity in what you're measuring, to evolve a more accurate measurement (estimate)
Imperfect, not fully refined, examples. But in my mind these are the things that Agile, Lean, etc all seem to scream out. But people dont seem to "get" that?
I dont see how people can implement Agile successfully until they understand that. Going through the motions of the detail will always run into problems. Perhaps will always fail ?? because no two projects, no two companies, no two teams of people, will be exactly the same. The variables in the differences will respond to the underlying theories, but not necessarily implementation "rules".
Ie how can so many people spend so much time talking about specific rules, or practice, without understanding those underlying theories. Or, at least at some point, going "aha, all this "stuff" we've been talking about all relates to these theories"..... then issues like arguing for months and years over "face to face" become true Waste (in the Lean terminology)... as an example.
I have to wonder if the weakness in applying Agile, in many instances, is the result of the mind set of the people trying to implement it. That is, the developer's, or the technicians, mind set ? If many of these discussions, even books about different methodologies, are 1) missing the point entirely because the people writing them have the same mind set or 2) trying to describe the concepts in a way that mind set hears it , rather than shifting that mind set so it can understand the concepts.
#2 is not ideally said but I'm thinking back to simplistic psychotherapy concepts like : dont just look at what the world does to you, look at how you cause the world to do things to you. Ie, change, or add, to your perspective.
So maybe looking at systems helps people suspend their specific mind set to see another perspective. hmm.... interesting, if I run with the ideas, I keep ending up with a conflict between what I think of as a technical, vs humanistic, approach to things. Hard science vs intuition. Pavlov vs Rogers/Maslow. Quant vs Chaos theory. (holding head)
I agree with Stephen. Focusing too much on the details of Agile, the practices, can easily make us loose sight of the purpose of those practices. We can also loose the connection with the underlying attitudes that are fundamental to Agile. This has happened before, with TQM, with Lean, with SPC, and many other methodologies. The practices get separated from their paradigm, and retrofitted into the old paradigm. It may work, after a fashion, but most of the benefits are lost.

What about you? Do you agree? If not, why? If you do, is there a way out? What can we do to educe an understanding of the Agile paradigm?

5 comments:

Martijn Verburg said...

Totally agree, we're simply focusing on the principles and cherry picking the techniques that suit our team and our organisation. Don't even get me started on the Scrum Master certification fiasco!

Kevin Rutherford said...

Yes, I agree completely. Most of the teams who invite me to coach them have implemented some common agile practices and are wondering why there's been no improvement.

Agility is the organisational culture ("state of mind") that permits the practices to become fully effective.

Peter Saddington said...

Completely agree with you. It's more of a psychological thing with the enterprise and team.

"Doing Agile" is a state of mind!

Best,
Peter Saddington
www.whitebarrel.com

Tobias Fors said...

Henrik, this problem lies at the heart of what Russell Ackoff pointed out as the great ongoing paradigm shift of our time: the shift from analytic to more systemic thinking, or at least towards a better balance of the two. In the analytic mind set, we attempt to solve problems by breaking them down into parts, as can be seen in the many attempts to create development methodologies in the style of cookbooks, and in the many attempts to get agile to work by simply following the practices.

It doesn't work, because agile is not just the sum of it's practices. Those who get it to work do not just have the know-how, the also have the know-why, the understanding to apply the practices wisely.

On a related note, I worry that many who are now fascinated by kanban are drawn in exactly because of the lure of analytic reasoning. As I understand Ackoff's own history, it can be boiled down into this: first he helped create the very analytic field of operations research, then he realized that the field had come to way's end. He changed perspectives and started on the track of systems thinking. I remember reading how he, in one of his operations research classes, frustrated his students by first letting them optimize an organization using the tools of trade (queueing theory etc), then had them do the same thing again, this time without being allowed to change a single thing in the organization they worked with. He wanted them to focus outwards, to the reasons why the organization performed as it did, and those reasons are to be found "outside the system itself".

Finally, it might be that lean and agile are not a match made in heaven. Lean is a name created by those who analyzed a complex phenomenon. The result: an analytic solution, more recipes. This, it seems to me, indicates that lean, in practice, has turned away from the understanding of systems and thinking on your own, and turned towards the old mindset of creating recipes and rule books.

Henrik said...

@Tobias

I agree. I believe one of the things we need to reconcile with is the need to continuously rediscover the fundamentals.

Lean may be a collection of recipes, but the original Toyota Production System isn't, or at least was not.

Agile seems to move through the aging process at an accelerated rate compared to TPS/Lean. This is probably due to the very fast rate of adoption.

I believe we need to keep reminding ourselves of the fundamentals. Lean and Agile, when done correctly, have a lot of things in common:

* Pretty far towards the Y end of a Theory X/Y scale
* Fundamental understanding of how Little's Law applies to work processes
* Focus on delivering value for customers
* A systems thinking approach

...just to name a few.

The companies who actually do this are probably very few. However, this has nothing to do with whether the approach is correct or not.

(I deleted a long comparison between modern business practices, witch hunts and cargo cults here. I know you know...)

My worry about Kanban (the software development method, not the scheduling system) is that it singles out one practice and says "do this one thing and all will be well".

Reality is more complex. For one thing, excess inventory may not be the most important root cause to fix.

For example, if the software requirements process is bad, Kanban will enable the team to do more of the wrong thing.

If the contract model is unsuited to Kanban (which it often is), company profits may drop catastrophically when its development teams improve.

I know some of the Kanban people understand this very well. However, if the main message is oversimplified to "use a kanban system", the actual effects can be quite different from the intent.