Recently I have been reading Andy Hunt’s books and I find them very insightful. The latest book I am reading is “Practices of An Agile Developer”, which he co-authored along with Venkat Subramanium. At the beginning of each section they place a little quote which represents a “devilish” thought. They are entertaining to read, so I thought I would pick out some of my favorite and post them along with my thoughts. If you are agile minded like myself, you will certainly think “That’s not Agile!”
Blame Game
“The first and most important step in addressing a problem is to determine who caused it. Find that moron! Once you’ve established fault, then you can make sure the problem doesn’t happen again. Ever.”
This attitude is rooted in the blame game. Agile is about providing solutions, not assigning blame. If you run into this atmosphere, try to bring a positive outlook to it and solve the problem first. Allow room for a retrospective to mitigate problems in the future, but for pete’s sake, don’t blame.
Hack
“You don’t need to really understand that piece of code; it seems to work OK as is. Oh, but it just needs one small tweak. Just add one to the result, and it works. Go ahead and put that in; it’s probably fine.”
Under time pressure, this thought will definitely come up in any reasonable person’s mind. If you think about it, this mindset is a hack. Responsible developer’s should understand what they are getting into. This doesn’t mean getting into analysis paralysis, but always look for ways to understand, refactor, and improve the code. The trade off in doing that must always be a consideration, but a hack mindset only leads to distressed code in the end. Weigh the options. Refactoring and understanding the code you are working will pay for itself quickly.
Egotism
“You have a lot invested in your design. You’ve put your heart and soul into it. You know it’s better than anyone else’s. Don’t even bother listening to their ideas; they’ll just confuse the issue.”
Agile is about collaboration and learning. I have run into this egotistic attitude many times in my career. I would hope an agile team is about ideas, not who is behind the idea. In addition, even if you have a design, it means nothing until you prove it out in code. Tracer bullet the idea instead of arguing, and you will probably come up with a better design in the end anyways if you consider others’ input. Don’t invest too much in upfront design. If you do, you are missing out on evolving your design.
Stagnant
“That’s the way you’ve always done it, and with good reason. It usually works for you just fine. The ways you learned when you first started are clearly the best ways. Not much has changed since then, really.”
I’ll just say it. This is my favorite. That’s not agile! At all. In an environment of continous improvement and value creation, this is the last thing you should hear. Especially in the technology field, we need to brace for change and accept that new ideas may be better then the old. I’ll borrow a quote from the athletic arena, “If you ain’t improving constantly, you are getting passed up.”
Feel free to add your own quotes based on your past experiences.
Reference: That’s Not Agile! from our JCG partner Nirav Assar at the Assar Java Consulting blog.
