Agile (R)evolution

Anyone with a job developing or maintaining software must have heard about Agile Software Development by now. If you haven't, you have some serious catching up to do. It has swiftly won over many development teams and has promised and delivered a positive change for business developers and software developers alike.

The list of advantages compared to the old and dreaded (especially by devs) waterfall approaches is quite extensive. Customers' needs are better met through higher customer involvement and more realistic expectations, higher agility is achieved through iterative life-cycles that accommodate change, serious improvements in time-to-market are gained, improved cost control and risk management and, the list continues.

Quite frankly, if you're developing software, your first question should be: "How can we develop this product with Agile?".

Developing software without agile methods is seriously hurting your pocket and should only be done if organization restraints or conscious business decisions dictate a different approach. And by conscious I mean: you better know what you're doing for the full scale of your product ;)

Agile revolution by the people of software

The agile revolution in software wasn't cooked up by multinationals and universities but is firmly rooted in Japanese and Western proven business practices. In my view, adaptation of agile development methods snowballed incredibly fast for two particular reason: 1) job enrichment for developers and 2) shift of locus of control for end results to the developers. In this sense, the rise of agile developing methods are a "true revolution of the people": the software people.

In the "bad old days of software development", developers resided at the bottom of the development funnel. How was a software product developed? Some management guy interpreted some customer reports to some requirement analyst who gave his documents to some designer. Designer then put his documents in an envelope, seals it and mails it to the developer with a note on it: "please create the code for this abstract description of software, and , oh, please hand in the code before next Monday".

Any questions the developer might have would have to travel reverse order through the designer-analyst-manager-customer chain. Node by node. Developers never actually got to talk to customers and got treated like mine workers doing mysterious work underground. A tiresome and frustrating experience for any dev, no doubt. No wonder many software products incarnated with plenty of confusion between what was actually desired by the customer and how it ended up in compiled code. And bugs, so many bugs.

Job satisfaction = ROI

This couldn't last. Software developers are intelligent people with scarce skills and somehow they were at the bottom of some inefficient production loop. Due to some cosmic mistake they had become buffaloes of software. Workers instructed with narrow SOPs. This situation was not sustainable.

They rebelled and won. They increased their control in software end results by introducing small iterative steps executed in close co-creation and cooperation with actual customers. Personal developer visibility was regained. They won because, in the end, the trade off is a proven higher business value for software products. Who could resist a true revolution of software quality and profitability?

Many devs are energized by their new enriched position and refuse to go back to the old waterfall development funnel. And who'd want to. Everyone benefits from the new agile (r)evolution.