Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

10 things a developer wishes his boss knows about being "Agile"

Bryan Tan, Regional VP, Asia, Rally Software Development | Feb. 16, 2015
What would you hope your boss would know to make software development a profitable and controllable experience for all?

In the traditional "waterfall" approach to software development, the software developer is often constrained by a barrage of incessant feature additions, frequent unmeasured requests of tweaks and changes, and uncontrolled work schedules. It is no wonder software and applications are often riddled with bugs and vulnerabilities, and ultimately frustrate corporate management, end-users, and paying clients.

If you are a software developer working for an in-house team, or part of a team to develop an external software, what would you hope your boss would know to make software development a profitable and controllable experience for all?

In a nutshell—Agile. The Agile revolution to software development has turned the more traditional, or "waterfall" development method upside-down, all for the better. Agile is the key to unlocking the full potential of an in-house or external software project, but to do it well there are 10 things a corporate manager should know:

1. Go Agile to realise revenue early = $$
Profitability is mandatory. Developers understand and appreciate that. We strive to work towards that too. To help the company realise revenue sooner, an Agile approach is a key element. Using an Agile approach, companies release development projects early and often, delivering steady, small increments of value. This approach not only allows companies to realise revenue more quickly, but to also incorporate key learnings and customer feedback into subsequent releases—allowing dynamic steering of a product strategy and ensuring customer satisfaction. One of the main failings of traditional software development can be attributed to the missteps along the way that all accumulate towards delays and ultimately, loss of profits.

2. More features may not be better.
How many features does a typical user actually use in a typical software product, such as a typical word processor, spreadsheet, or presentation tool? Out of all the esoteric features, a typical end-user is probably only going to use a handful of them. What's worse, a typical user is unlikely to read the thick tome of a user manual. Therefore, having a dense code base does not make sense in the real world, and not only create a complex software development process, also creates many "black holes" for potential bugs. A simpler, leaner code base is light on computing resources, and easily gets the job done for end-users.

3. Customers are our allies to test and improve our products.
End-users or external customers are our allies. All too often, the classical "waterfall" approach leaves the end-users or external customers out of the equation of software development, and they only get to use and test the product when it is already in alpha, or beta, with all the inherent fixation on design, philosophy, features, and of course, bugs and vulnerabilities. With the Agile approach, we engage the end-users and external customers in the developmental stages early and often, so that they have part ownership on the process, and the ultimate deliverable. We like to think that everyone will ultimately be happier.


1  2  3  Next Page 

Sign up for CIO Asia eNewsletters.