SmartAdvice: Agile Programming Not For The Risk Averse
Once an architectural framework has been set, agile programming can give a quick turnaround on specific modules, The Advisory Council says. Also, built-in code tests or unit tests remain the best way to get quality apps.
Editor's Note: Welcome to SmartAdvice, a weekly column by The Advisory Council (TAC), an advisory service firm. The feature answers two questions of core interest to you, ranging from leadership advice to enterprise strategies to how to deal with vendors. Submit questions directly to email@example.com
Question A: What is agile programming, and should we be interested?
Our advice: In the quest for smaller, faster, and cheaper software, companies have been looking hard at a new paradigm in programming methodologies called agile programming. The first agile methodology, "extreme programming, or XP, was developed in the late 1990s by Kent Beck, Ward Cunningham, and Ron Jeffries.
By 2001, the umbrella term was coined to describe a number of methodologies that shared the common characteristics of breaking projects into small, manageable modules and using a highly iterative development approach instead of traditional "waterfall" schemes. It's particularly effective in startup situations or in secret projects where the final product is, by necessity, ill-defined at the initiation. From a business perspective, this can be very attractive as it more closely maps to the natural market-development cycle.
What distinguishes agile programming from the more traditional "top-down" design methods is that once an overall architectural framework has been established, the entire project is divided into small modules that can be developed into fully functional, tested, and potentially usable releases in a short amount of time -- often in less than a week or even a day.
Since the agile approach places a higher value on risk management, early user feedback is highly valued. Agile projects should either succeed or fail early on, before too many resources have been committed. There's nothing worse than investing a lot of resources before finding out the product has features the users didn't want or need. That means that teams can focus on only the modules and features that have the most value to the users. Marketing types love the approach, because even early in the development cycle, important features are functional and ready to demonstrate.
Although it's not essential, it's a good idea to plan the overall architecture at a very high level, in the sense of deciding on the interfaces and protocols, vendor libraries, etc., before creating the individual working modules. It's best if everyone on the team has a good understanding of the overall design and the reasons behind the design decisions.
Because agile methodologies are so dependent on creating separate working modules, they require lots of embedded and iterative testing throughout the development cycle. Yes, quality-assurance and user-acceptance testing is part of the process, but instead of tacking it on at the end, where the temptation to truncate the testing to meet deadlines is high, it's built into the coding cycle.
Agile programming used in the right context and for the correct project can be an extremely effective technique. By modularizing the project into interlocking, manageable chunks, each feature can be developed separately while maintaining overall product functionality during the process. Of course, as with any methodology, the keys to a successful application of agile programming tools are good programming practices and excellent project-management skills.
Building A Mobile Business MindsetAmong 688 respondents, 46% have deployed mobile apps, with an additional 24% planning to in the next year. Soon all apps will look like mobile apps – and it's past time for those with no plans to get cracking.