Avoid Non-Agile Thinking: Hacks, Egotism, and Stagnancy
I have been reading Andy Hunt's books and find them very insightful. The latest book is Practices of an Agile Developer, which he coauthored with Venkat Subramaniam. At the beginning of each section, the authors offer a quote, which embodies non-agile behavior.
Some of the behaviors are prominently seen in software groups with people who are not used to agile. To overcome these unproductive behaviors, we must first identify them. Hunt and Subramaniam nicely describe some of these behaviors, to which I’ve added some anecdotal advice.
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 developers 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 considered, but a hack mindset only leads to distressed code in the end. Weigh the options. Refactoring and understanding the code with which you are working will quickly pay for itself.
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 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, especially when considering others' input. Don't invest too much in upfront design. If you do, you are missing out on evolving your design.
Stagnancy
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.
This is my favorite. That's not agile—at all! In an environment of continuous 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."
In our comment section below, feel free to add any quotes based on your own past experiences.
