Better Software - March 2009 - (Page 16) eNEWsLEttEr ExtrA A sampling of content from our eNewsletter archives iterations: Agile in Motion: Music and Metaphor Interview with David Hussman David Hussman leads DevJam, a company comprised of agile collaborators working on assignments worldwide. In the following interview, he elaborates on Jonathan Kohl’s “We Need More Metaphors” by answering our questions about connecting music to software development. iterations: What are some things you picked up in the music industry that have transferred to your work in software development? david Hussman: The recording studio is filled with a collection of bright, shiny, technical distractions. Producing records taught me that, while processes and technology were helpful tools, my greatest hits happened when I got to know the band, got to know their music, and went to see them play live, either in the rehearsal room or on stage. With this knowledge, I always did a better job guiding them through the recording journey, helping to select a set of techniques and gear, which helped bring the best they had to the final product. January 15, 2009 www.stickyMinds.com/enewsletter11-2 I do the same thing in my coaching. My greatest coaching hits happen when I get to know the community before suggesting which practices or variations of agile processes (e.g., Scrum, XP) it should use. Even though I cannot see a project community perform, I can take a short trip to its world, so as to better understand who its members are, how they work, why they are moving toward agility, and where they see their strengths or challenges. Instead of prescribing a path, I combine my experience with what I know of that community’s world to suggest, teach, and coach a set of practices that help its members deliver more value in a more predictable fashion. Contrary to what the many agilists teach, this does not always mean faster. Similar to learning to play difficult music, many people need to slow down to deliver more; simply playing a song faster does not mean it is better. iterations: Jonathan writes about the over-reliance on manufacturing as a metaphor in agile. How have you seen that metaphor used, both successfully and unsuccessfully? david Hussman: I think there are many great tools we can draw from the manufacturing community. Trying to find and fix (or stop) wasteful work habits is a great one. I took this and many other gems from my first read of The Toyota Production System by Taiichi Ohno. When I engage with a community to help it improve, I do look for waste, but I also use Ohno’s Five Whys to make sure I am not simply running toward the first solution from my past that might seem to apply for this community. So, while I do see ideas from manufacturing helping tune processes, I also see them being applied in an ever-increasing and simplistic manner. We are not building cars! For instance, the manufacturing world has physical constraints that need not limit software development. Where automobile manufacturers may need to keep five radiators in place as a tool to make decisions at the last responsible moment, software developers can build systems in an evolutionary manner, making incremental changes to systems without the need to build five parallel systems. I have seen software teams overly focused on process only, trying to fix problems by applying ideas from manufacturing (in the name of “optimization”) that could have been fixed in a much simpler manner by employing a few development practices—many of which they simply did not know. While there is evolution in manufacturing, once the product can be produced, a great deal goes into how to produce more units faster. For me, this is where a great deal of art can be pulled from software development when manufacturing ideas are simplistically applied. I have met many teams who have consistent velocity and who are iteratively and consistently producing more mediocre code iteration after iteration. In the name of being lean, they have leaned out all the incremental innovation that happens as you try to bring a product to life and keep it alive—instead of working hard to produce 10,000 units with the highest quality in the least amount of time. iterations: Why is the concept of “metaphor” in general important to software production? david Hussman: Software is an abstraction that cannot be simply defined with prose. Kent Beck tried hard to raise the value of metaphor. I think it failed because it was too difficult for many (most people do not consciously wield metaphor). If you take George Lakoff’s approach in his book Metaphors We Live By, you find that metaphors are everywhere. In my coaching, listening for the active metaphors—those that communities live by—I find one more tool to help me make connections and improve my ability to coach more effectively. Metaphor also helps feed creativity by allowing people to “think outside the box”—an excellent example of what Lakoff discusses in his book. 16 BETTER SOFTWARE MARCH 2009 www.StickyMinds.com http://www.StickyMinds.com http://www.StickyMinds.com/enewsletter11-2 http://www.StickyMinds.com
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.