Ken argues that Agile (big A or little, your choice) is Gestalt. From this conclusion, he says that it’s a mistake to dogmatically follow a given process or proscribe particular tools when we’re trying to implement Agile and that instead, we should “. . .help remove organizational and sociological blocks that prevent teams from employing them.” While I think he may be right that Agile done correctly is Gestalt, I don’t think that his conclusion naturally follows.
For those of us who haven’t been in cognitive psych too recently, the Gestalt basically boils down to “the whole is greater than the sum of its parts” and is holistic in nature. Max Wetheimer, commonly considered one of the three founders of the Gestalt school, said this about Gestalt:
I stand at the window and see a house, trees, sky. Now on theoretical grounds I could try to count and say: “here they are. . .327 brightnesses and hues.” Do I have “327”? No, I see sky, house, trees; and no one can really have these “327” as such. Furthermore, if in this strange calculation the house should have, say 120 and the trees 90 and the sky 117, I have in any event this combination, this segregation, and not, say 127 and 100 and 100; or 150 and 177. I see it in this particular combination, this particular segregation; and the sort of combination or segregation in which I see it is not simply up to my choice: it is almost impossible for me to see it in any desired combination that I may happen to choose. When I succeed in seeing some unusual combination, what a strange process it is. What surprise results, when, after looking at it a long time, after many attempts, I discover-under the influence of a very unrealistic set-that over there parts of the window frame make an N with a smooth branch. . .
(Emphasis mine)
So is Agile greater than the sum of its parts? I agree that it probably is. But here’s the kick in the pants: so is waterfall or RUP or whatever methodology of the week that you follow to write good software. The key word there is “parts” I think. As in, without ALL the parts, you don’t get the emergent factor of Gestalt. Waterfall can be Gestalt, just ask the people who write the software that runs the space shuttle. It becomes a matter of discipline in following a process precisely.
In my limited experience, what I find happens if you don’t prescribe a practice in a shop that’s trying to implement agile is that shop picks and chooses the pieces that it likes (typically short sprints and planning at the beginning of each sprint) and leaves aside all the pieces that they don’t like which are typically the parts more likely to engender success with Agile like producing deployable code after each sprint or having access to real users, not managerial standins. When this process fails to produce the expected results, it’s the methodologie’s fault even though in reality, the methodology was hardly implemented at all. There’s a reason why we call them methodologies and not suggestologies. There is a method involved and when you short cut it, you get short cut results.
I don’t think Ken Schwaber would ever suggest that leaving out pieces of Scrum would result in a better process. In fact, his book is full of case studies where teams were trying to implement Scrum by skipping important parts of the process.
Eric Gunnerson wrote about what he called “scrumbut”, that is, the practice of saying you are doing Scrum but you’re doing it differently. I’ve written in the past how Scrum is analogous with a jazz musician. When you are a beginner, you don’t have any business going off on your own and riffing some jazz chords because you don’t have the fundamentals necessary to do that. Scrum and Agile are the same in that as a beginner, you can’t decide what pieces of the methodology are good and bad for your team because you don’t have the fundamentals necessary to make that decision without having implemented the process precisely. I don’t think a mentor should ever advocate or facilitate such behavior either. Instead, he should explain why all of the pieces of a particular methodology are necessary.
A process without ALL of its most important parts becomes anti-Gestalt because then the process not only doesn’t produce the emergent behavior expected, it can also be blamed for the failures that inevitably follow. Comparing the picture in Ken’s post with the picture above, it becomes obvious that without the critical parts, the cross in the middle never emerges.
Agile has the potential to make writing software more successful. But that doesn’t mean that it will ever be easy or that you can skip parts you don’t like. Implementing agile correctly involves prescribing and then following an oftentimes difficult process. Only by doing that can agile become Gestalt.