...with all the emotional pain included.
Can you picture the entire development team (or company) in the psychiatrists' office? (OK, so I guess you probably could picture that. :-)
So, in the classic portrayal of psychotherapy sessions, what usually happens is that a lot of one's emotional baggage may be discussed as one tries to wrestle with "Why do I feel <fill in the blank>?" The theory being that you can't deal with that which you do not know about, or do not understand. Couples and family therapy works similarly... personal history and relationship information is discussed and revealed so that the individual (or couple) can deal with it appropriately.
The problem with therapy is that it can be painful. OUCH! No one can force an individual to undergo it. Some people get frustrated and quit. BUT for those who are willing, and who recognize the need... it can also be liberating and very useful. It is the same with Agile at the organizational level.
My most penetrating insight over the past several years of more than one Agile transformation is that Agile is really 'Organizational Therapy'. Think about it. All of the things we struggle with individually are there: power dynamics, self-worth, personality quirks, communication differences, status, history, co-dependency, and of course personal relationships.
Sidebar: So, when will the next great daytime soap opera be introduced that follows a tech company or IT group? Maybe it should be called "As the Code Churns"? Of course it would be delivered via podcast. But I digress.
Organizations are nothing more than groups of flawed individuals. Traditional development practices often shroud functional groups or individuals so that their behavior is little known or noticed initially but grows into significant problems later on in the cycle. These organizational behaviors and power dynamics become very evident, very quickly with Agile. It removes the shrouds and what is revealed must be dealt with.
From the "simplest" technology problem (such as continuous builds and test automation), to the weird political maneuverings in any company, Agile practices force these problems to the surface. Here is a link to a great video by Ken Schwaber and he illustrates the principle much better than I.
People who say Agile is a miserable failure usually believe that it was Agile that caused all the conflict in the team or organization. The reality is that these problems were always there, but we have relied on coping mechanisms that made us think we were "OK". The important thing to remember is that every conflict and problem discovered, (or discovered earlier), means better quality and (eventually) higher team satisfaction. This is an organizational quality issue... not just code quality.
Product management is inherently a political sport. I've seen this all over the place, and I've had more than one person describe their particular experiences along these lines, so tell me your story! I'd love to hear about it.
Comments