Q6 - Israel Gat

Q6: What should question 6 be?  And what's it's answer?

I would suggest the following question: Can one apply Agile beyond software?

While I have not really done any systemic primary research on the subject, my hunch is that the answer is a resounding “Yes!” I offer three data points to support my hypothesis, as follows:

1. Jim Highsmith has been doing Agile with an architecture firm in Italy.
2. Paul Beavers and Becky Strauss are currently working on introducing Agile in BMC’s Customer Support organization.
3. My own experience with my staff.

Of these three data points, I will elaborate on the deep transformation we went through as the staff of BMC’s Distributed System Management business unit for the simple reason that it offers special insight on the nature of Agile principles.

As mentioned in previous postings, we started doing Scrum in 2004. By 2006 we had mastered many of the aspects of Scrum. Furthermore, the business unit was “Scrummed” in entirety at this point in time.

During this year (2006) a product line was moved into my business unit. While the leaders of this product line were generally competent, their assimilation in the business unit was not working. It was clear they were struggling. We, as staff, were struggling to figure out why they were struggling…

The answer to the question why they were struggling eluded us for quite sometime. Examination of the “usual suspects” – strategy, market, execution, structure and time (for integration/assimilation) yielded no insight. There existed, of course, all kind of very legitimate differences in thinking and approach between the old hands and the new product line folks, but nothing to write home about, nothing that could shed light why the assimilation was so problematic.

Sean Duclaux, who was the director of product management for the business unit, came up with the insight we needed. Sean grasped that doing Agile transformed me and my staff with respect to our mode of operation. Unbeknown to us we became so-very-agile in the way we functioned. Actions were taken quickly; decisions were postponed to the latest responsible time; something we were working on in a certain staff meeting would be dropped in favor of a more important item in the next meeting; etc. None of these was conscious – we did not set ourselves to run staff using Agile principles. These things were just happening.

Checking with the struggling product line team, Sean’s hypothesis was validated. From their perspective we were an unbelievably chaotic bunch. We were not even managing an “organized chaos” – in their eyes we were increasing chaos. They found it next to impossible to operate within the fluidly dynamic environment that de facto prevailed in my staff.

The problem actually proved very hard to solve. While we had any number of staff members and staff members of staff members who could immediately help with just about any implementation aspect of Scrum, we really had no expertise on the transformation in our own functioning as decision makers. I am out of my depth here, but I tend to think we had gone through a prolonged evolution period in which Agile principles, in the most general sense, sank into us and became part of our standard operating procedures in any domain we focused on. This evolution period was missing altogether for the new folks on my staff. Expecting them to adapt quickly, we were sort of implicitly asking them to skip a developmental phase that one has to go through whether one is doing Agile in the R&D lab or performing in an agile manner in staff.

I find it fascinating that we had not realized Agile was transforming us as staff while we were transforming software engineering practices at BMC through Agile. There is an intriguing symmetry here that speaks straight to the heart of the software craftsman that I am.

[Clarke: My thanks to Israel.  If you have a question for Israel then leave a comment and I'll pass it on.]