.

AGILE VERSUS AD-HOC V3

December 31, 2008

I was interviewing a junior candidate recently and mentioned to him that we use agile methods to develop our software. He seemed interested and asked “How does that work? I mean, how do you develop software without doing up front design and requirements?”

My initial reaction was stunned silence. Then I recovered. I realized he was young in his career and was relying on what he learned at his university – do the requirements, then do the analysis, then do the design, then do the coding, then do the testing, then do the deployment, then do the maintenance. Classic waterfall.

In his mind, “agile” meant skipping all of the important planning steps and immediately jumping into the coding. Yikes.

I used the opportunity to mentor and teach the young man that “agile” is actually the most disciplined software development approach around. Anyone who tells you otherwise is doing a disservice to software development. The idea that “agile” is the same as “ad hoc” is just simply incorrect. In many ways, “agile” is the opposite of “ad-hoc”. Agile is not “hurley gurley” like ad-hoc. You can be proud if your team is agile. If your team is ad-hoc, you should be motivated to find help.

It is true that the most important aspect of Agile is the fast development of working code. But how do you get to working code faster? You do bite-size chunks of requirements gathering, analysis, design, and test – in support of developing code. You prioritize ruthlessly. You develop user stories on index cards to capture requirements. You use these cards as reminders to discuss them further. The PM or development team writes use cases to clarify and/or regurgitate their understanding of the requirement. Preliminary object models are pulled from the use cases and documented. Key Design Ideas are captured for future reference. Test case automation is established in order to create a repeatable verification. Continuous integration of the build is set up. Test-driven development tools are installed to drive quality upwards. The team meets daily in a brief stand-up to insure synchronization. The team does a detailed plan for the upcoming iteration. The team demonstrates their working code each month.

Does that sound like “Oh, we just code?” No way.

Does it sound like “Too much”? No, it is focusing your time and talents on the things that really matter – working code with high quality – and ignoring or de-emphasizing everything else. I like to call it “ruthless focus”.

The candidate understood, so I’m still considering hiring him.


Comments? Feel Free! Contact me and let me know what you think.


Back to Blogs

.