The Agile CIO

Many of the great CIOs realized early in their careers that to rise on the organizational ladder, one must find alternative approaches for software development that focuses on customer satisfaction through continuous delivery of useful software. Others still use the questionable wisdom of developing software in the same manner it was done 30 years ago, which leads to the vast majority of projects falling to the demons of total failure, budget overruns, and release with less functionality than initially promised. Only the agile CIO has the answer to this conundrum. Let's look at the answers provided by Kello James, our agile CIO.

Kello James believes that requirements for software at the outset of a project should be kept to a minimum. He counsels not to enumerate every possible facet of what you want software to accomplish. Simply start with what functions the software must absolutely have. Kello also believes that one should not be savage at this stage about writing down all the needs of the software (comprehensive documentation) because requirements will change during the course of the project.

Our agile CIO has also instituted a process whereby the business leaders test the application on a monthly basis and provide additional guidance (customer interaction) and approval. This allows developers to get immediate feedback on areas that require additional concentration. Furthermore, it ensures that developers are focused solely on a hard-target deadline for which his staff will always rise to their finest hour. Any software that the business community tests at this stage is not released to production, but it must be functional (preferably working software).

Kello is also a fan of the movie Sniper and frequently uses the phrase "One shot, one kill" in his staff meetings. He advocates shooting a belief if it doesn't work. Bringing together businesspeople and IT frequently to evaluate software allows Kello the opportunity to determine immediately whether or not his team is satisfying the goals of its business partners. At a minimum, any software that doesn't meet the needs of the customer is killed.

The typical organization has incorporated the notion of triage into their methodology, but it usually comes too late in the game. Frequent evaluation of software with customer involvement provides the ideal opportunity to kill a software project. Kello once learned of a feature that was being developed by his application architect when he realized that no one had actually expressed a desire for the feature. Without hesitation, Kello killed it right then. Organizations no longer can afford to burn precious time and money only to realize what they are working on isn't useful.

Over the objections of his staff, Kello frequently slashes the budgets of many of the software projects, even those in progress. He has realized that small budgets force his development team to focus only on essential functionality. It also makes it more acceptable to kill failing projects. Kello's success rate has significantly increased using this approach.

Kello's nonagile CIO industry peers frequently commit to big-dollar projects that frequently crash. One of his peers is struggling to figure out how to rescue a project that has already burned through $40 million. At this stage, the only thing his peers can do is to attempt throwing more money at the problem in a rather futile attempt to rescue it rather than taking a huge loss. At the end of the day, Kello's nonagile peers further increase their losses using this approach.

Our agile CIO has mandated that the development team have direct access to the end business customer as they are in the best position to conduct tests and determine whether the customer's needs are being met. Using this approach has resulted in two separate successes for Canaxia. First, the business community can no longer claim ignorance about the software development process and cannot honestly say that they were in the dark. Second, through synergistic interaction with business communities, Canaxia has created the perfect developer: half businessperson, half programmer.