|Entradas de Blog Apresentadas|
Roll call: 5 questions for...Millard Ellingsworth
sjpeich 270000KJQC Comments (2) Visits (3355)
We're calling on Millard Ellingsworth. He is a member of the software development team for Rational Team Concert; a musician and golf enthusiast; and the author of Get ready to Sprint with Rational Team Concert, the featured article this week on developerWorks Rational.
What books have influenced your ideas and thoughts the most?
I'm going to lead with what may seem like an odd choice: Janet Kagan's Hellspark. It is dense with ideas that resonate for me, including understanding and respecting cultural differences in a team environment, particularly how to adjust your behavior to be more effective through that understanding. There's a character in the book whose culture highly values speaking accurately and truthfully, to the point that they award bracelets to individuals who have done so reliably over time. Rattling or shaking these bracelets while making a statement is a way to emphasize how strongly you feel that your words speak true – and to put some of your reputation on the line at the same time (bracelets can be revoked). As I write or speak I will sometimes ask myself if I would rattle my bracelets about the point I'm trying to make. It's an internal dialog that I hope keeps me clear and honest. Oh, and it's a heck of a good book, too.
From more of a technical book perspective, I was impressed by early work around analysis and design activities by Tom DeMarco, Structured Analysis and System Specification and Larry Constantine's Structured Design. In software construction, we still worry about coupling and cohesion – two of many concepts that developed from these early works. Pretty much everything that Gerald Weinberg wrote is worth reading. Ivar Jacobson's Use Case Driven Development is another one that injected truly new thinking in this space. You can check out my developerWorks blog for additional books I like.
How do you handle defeat and/or failure?
It's all a learning exercise and you learn the most when you stumble. That old saying is useful to remember during difficult moments: Success is a poor teacher. The important thing is being able to review your goals, intentions, actions and results and determine what you might have done differently and consider how it might have changed the outcome. Even more important is incorporating that understanding into future efforts. The only real failure is to not be improved by the lessons life hands you.
How do you handle obstacles and roadblocks?
You have to lean into the pain. If something is difficult for you, you need to do more of it until it isn't so difficult any more. Most things can be mastered if you care to. And that's the other side of the answer: you need to consider the obstacle and decide if it matters. Perhaps walking away or looking for a different path is better than powering through. Sometimes when you step back and take a broader view of your goal, you realize there are better ways than the one you had been focusing all your attention on.
What interests you outside of your job (hobbies, activities)?
Music is a big part of my life both as a listener and creator. I was in several different bands when I lived in Southern California (if you look hard enough you can find stuff I've worked on as both a musician and producer on Rhapsody and iTunes). These days golf is a bit more of an obsession. I started playing again (with the IBM Beaverton Golf Club) after many years away from the game and am very much enjoying both the physical and mental aspects of playing a good round. The rainy Oregon winters leave plenty of time for some woodworking projects – my wife is expecting me to build her a “pie safe” over the upcoming holiday.
What do you see as the top driver to Application Lifecycle Management tools?
The same as the top driver for any tool: Value. An important part of the agile mantra is delivering value quickly. For tools to play well in that space, they have to support exactly that -- they must help teams do more, do it better and get it done and delivered. I've been an unabashed supporter of Rational Team Concert since the very beginning because I believe it brings together a remarkable suite of capabilities and integrates it beautifully. That suite has expanded on both ends with Requirements Composer to help organizations do a better job of being clear what needs to be done and how it should behave and Quality Manager to traceably prove that we've passed the tests that matter. Any organization not considering adopting these tools does not yet understand the value they provide.
If you haven't yet used Rational Team Concert customizations to help improve your practice, did the article give you some ideas on how you could do that? Leave a comment here or connect with Millard on both Google+ and Twitter (@millard3)