Why Agile Isn't Working: Bringing Common Sense to Agile Principles

Agile promises many things, but the reality in the field is often very far from the expectations. Is it agile we need--or an agile way of thinking?

By Lajos Moczar
Tue, June 04, 2013
Page 3

Remember, the goal is to deliver a quality product on time and to budget; as a rule, there are always some elements that have to be sacrificed to fulfil the needs of the others. It's the How to Develop Next-Generation Project Managersrole of the project manager to define and maintain the project priorities so they can function as a decision framework for team members as they carry out their tasks.

One of the hardest things for many developers is pragmatism. Rather than think practically, they inevitable fall into abstract approaches to problems. I was on one very expensive project based on a purist design in which everything was reusable and could be dynamically coupled together. It was a marvel of abstraction. The only problem was that it didn't work. It had the worst performance I have ever seen in a Java system and was incapable of supporting the required load.

The core problem there was that the team attempted to solve real-world problems with an abstract approach. No matter how virtual technology gets, it's still ultimately based on the physical world that we humans operate in.

Physical problems cannot be solved abstractly. Look at any factory machine and see how many oddly shaped parts it contains, each good for just one very vital physical function. Software is no different. Sometimes things are meant for one use only. That's not a bad thing if it gets the job done and functions properly for many years.

Related: How to Adjust to the Changing Face of Software Testing

Finally, dynamism means the ability to switch strategies when the current one isn't working. Many times, despite our best planning, what seems like a good project, design or development strategy hits a brick wall. The most important thing in this situation is to know when to call it off.

If the brick wall is only a brick wall, a bit of brute force—i.e. one or two late nights—will get through it. But if it's really a mountain of rock, it's best not to risk the entire project but, instead, find another way around. It sounds like a simple concept, but I've watched projects go on for weeks, team members beating their collective heads against the mountain, only to conclude too late that another approach was needed.

Agile promises solutions it cannot deliver. It promotes sloppy requirements, hides the true cost of development and prevents effective management. Contrary to what we're told to expect, this leads to long-running projects, dissatisfied customers and an overall IT ineffectiveness.

What we hope to find in the methodology, however, is achievable through agile thinking. With this thinking, we can in fact solve the problems of IT project management and learn how to deliver stable products on time and to budget. If the project team knows how to think and work effectively, then we don't need to look to a methodology to save us from project failures. We can do it ourselves.

Lajos Moczar is a senior technology strategist and consultant, operating as The Consultant CTO. When not consulting, he writes on various IT topics. Follow everything from CIO.com on Twitter @CIOonline, Facebook, Google + and LinkedIn.

Copyright Lajos Moczar, 2013. Reprinted by permission

Our Commenting Policies