Agile: Not A Complete Solution.

Tuesday, May 21, 2013

Agile: Not A Complete Solution.

Share this ARTICLE with your colleagues on LinkedIn .

I am one of many strategic planners and project managers who has seen some very disappointing results from over-dependencies on Agile. It would seem that many IT and professional programming participants use this admittedly time-saving organizational and communications tool as a substitute for continuous, responsive communication (i.e., in real time), and for an actual planning process which follows a sensible, step-by-step path.

There are no automated substitutes for the native Human thought processes of goal-setting, envisioning success, real-time communication and feedback (especially for the purposes of truly measuring progress, reaffirming goals and for trajectory correction), and step-by-step planning. These things require organized, educated thought and interpersonal action. All too often planners, managers and implementers foster unwarranted reliance upon automation where it is insufficient for problem-solving or objective achievement.

The article which follows speaks of the deficiencies in Agile technology, as well as of its unintentional misuse.

Posted by Mark Corley
on May 08 2013

Agile software development is an often misunderstood and misused term. In an exclusive new series of articles, IDG Connect offers expert insight and opinion on Agile. In this piece, Mark Corley, UK CTO of business technology services company Avanade, explains why Agile is sometimes just an excuse for no method.

A customer I know uses Agile and is relatively new to it, having moved away from a highly stage-contained, waterfall approach that was designed by committee. At each stage there was full documentation and a committee would come together to discuss it, ask questions, catch up on any previous meetings and, eventually, sign it off. It was a slow and arduous process that didn't mitigate risk or serve the company's intentions particularly well. Recently they've moved to what they call Agile and have a small team to do Agile projects. And really they're using it as a way to avoid documentation or process...

I'm not a fan of documentation for the sake of it, but they've gone to almost no documentation, which causes problems downstream when the project is handed over to new people to support. Agile is sometimes used by organisations as an excuse for no method.

Others try to develop on a ‘Waterscrumfall' basis, combining elements of Agile/Scrum and waterfall methodologies but this is an immature field. They're not confident or comfortable enough to ‘do' Agile so they do an analysis, come up with a list of requirements, list all the sprints and prioritisation before they get into an iterative process. Then it gets handed over to support and with immature customers it can whimper out.

There is a hybrid way to capture some of the advantages of Agile. I like the practice of demonstrating to the business early and making sure the users are involved. Iterations and milestones keep the pace up. But too often in Agile projects you see no product owner or representative form the business, no endpoint and it's forgotten that most of the cost in a software project lies in support and maintenance.

If Agile gives you an excuse to stand up and explain what you're doing and show work rather than delivering a status report every week, great. But common sense should apply in any methodology and I've yet to see a methodology that says you shouldn't have regular interaction with customers.

Perhaps it's a generational thing and a reaction against mega-projects and some of the worst-case failures. Or maybe because of the sheer amount of data that's processed today and the way devices have proliferated, the hype is amplified. But the problems we're trying to address today are all the same problems as before and we have the answers. It's just that people come up with new ways of packaging those answers.

Mark Corley is the UK CTO of business technology services company Avanade
---------------

To many in the C-Suite, and to many corporate directors, "Agile and Scrum" would be perceived, conversationally as a comedy team or a country-western band. It is not because these people are ignorant - it is because they are dependent (and justifiably so) upon the simply direct verbal communication of answers to these questions, and metrics to accompany and bolster them in terms of visualization:

1) What is our target objective?

2) Are we still on the right course in terms of budgeted assets, time and capital?

3) What are the difficulties or barriers, if any, and how do we overcome or solve them?

4) When can we expect completion of the project?

Human beings provide answers to these important questions, and, generally speaking, simple graphs or charts of metrics enhance these communications so that they may be better visualized and understood. There is no out-of-the-box product or technology that does these things.

Douglas E. Castle

Sponsored By:
CFI - CrowdFunding Incubator LLC
ICS - International Connection Services
Global Edge Technologies Group LLC
CFI Business Growth
Douglas E. Castle On LinkedIn - Join Me!