Taking a quick look at Google results regarding agile software development, it’s easy to come to the conclusion that every development agency has gone 100% agile and couldn’t imagine doing things any other way. I’m here to tell you, however, that it’s simply not true. Nor should it be.

You see, the agile development methodology is a fantastic philosophy to guide a software development workflow, and it works great for a number of different project types. But it’s not by any means the perfect solution to every circumstance, and developers or agencies who insist on shoehorning every project into the agile framework are likely facing frustration if not complete failure at times.

The Pros: Where Agile really shines

Before I go any further, I want to make clear that, in my professional experience, Agile development can work wonders in many ways:

• Increased visibility and transparency
• Faster “failure”
• Enhanced communication
• Greater productivity
• Enhanced customer satisfaction

If and when the Agile methodology is implemented under optimal conditions and for the right kind of project, there’s no doubt in my mind that it improves both productivity and quality across the entire development process. Considering the money clients are spending to have their custom software, web applications, and mobile apps developed, these benefits are well worth the effort even if it’s only a small percentage of cases.

And, in fact, Agile can work well for many different types of projects. For some development teams, the majority of their projects may fall into this category and they will therefore have a higher rate of success sticking to a strict Agile process (such as Scrum, for example.)

The reason Agile works under optimal conditions is that it provides structure to what is inherently a chaotic process: a group of people turning the hopes and dreams (read: user stories and requirements) of another group of people into functional and beautiful reality. Without something like Scrum’s short iterations and focus on shipping work quickly so it can be evaluated and returned through a feedback loop to be improved upon, that chaotic process can require huge investments in time, money, effort, and leave both parties frustrated and demoralized.

So, just to clarify: I like Agile. I agree with its tenets and I use it when I can because I believe the benefits of successful Agile development can be very valuable.

However, I’m also a pragmatic developer myself, and a businessman. I run a custom software development firm that works with many different kinds of clients on all manner of projects, and I can say with absolute certainty: Agile does not work for everything. In fact, it can be disastrous.

The Cons: Where Agile falls flat

The reality of my working situation immediately creates a logistical barrier to instituting strict Agile processes across the board.

For one thing, my team of developers, analysts, testers and other support staff are spread across the globe. Time zones and schedules make anything like a “daily standup” meeting difficult to say the least. Routine sprint planning and retrospective meetings are likewise difficult.

I’ve hired team members based on their development skills and personality because I know they’re the right fit for my team and I’m comfortable with sharing their work with my clients. Whether or not they have experience in Agile development is not part of my hiring criteria. Therefore, there’s a learning curve involved.

Likewise, the entire concept of “Agile Development” (with the capital “A” and “D”) means so many different things to different developers depending on their experience and experiences, it’s almost laughable.

Beyond these logistical issues, there come some practical business considerations that throw a monkey wrench into a formal Agile process.

For example, as the leader of a team of professionals who is paid to achieve a particular goal (fully functional software) for my clients within set time and budget parameters, I can’t go into development with little or no pre-planning. It would be impossible for me or my salespeople to convince clients to sign a contract that essentially says, “we’ll get the software to you when we decide it’s ready.”

In pure Agile practices, planning and documentation are minimized in order to get straight into creating and shipping working software for evaluation and iterative improvement. Without appropriate planning up front, however, that’s a wide open arrangement with no set end time or means of tracking progress.

Sure, we have our “definition of done,” so we should all know when the project is over. But if you were paying good money to a development team to work on your back-end web application, would you be comfortable handing them their check and saying, “just give me a call when it’s done”?

That would be ludicrous.

And herein we can clearly see the point at which Agile – at least as it’s preached by its most zealous adherents – falls apart. It’s designed for a fictional Utopian situation in which the development team is apparently on some separate plane of existence and has no accountability to outside authority, but only to the project itself. While it might be nice to daydream about being able to dive into a coding project and let the world fade away for weeks at a time, it’s simply not practical for anyone who’s interested in actually making a successful career of this software development gig.

So where is the moral in this agile methodology overview?

After nearly 20 years experience in various aspects of software development, much of which has been spent with a thorough knowledge of Agile development practices, I’ve come to believe that the very best practice for any development team involves a hybrid of Agile and more traditional methods.

Basically, what I try to accomplish with my team is a natural fusing of the best parts of Agile (the focus on continual quality improvement, the enhanced communication – both internally and with the client – and the willingness to shift priorities as needed) with the more business-friendly aspects of traditional project management.

In other words, when I begin working with a client on a development project, my initial goal is to get to know the client intimately, to fully understand their business needs and processes, and to fully grasp their goals and desires for the project. I then work with my team of analysts and developers throughout a fairly extensive planning and orientation phase in which we analyze and organize the entire project in as detailed a fashion as possible.

Assuming the client is willing to enter into a paid analysis period up front (which is sometimes a deal breaker for me because I know the project won’t succeed without it,) this phase can take up to 6 or 8 weeks. At the end, we present a collection of deliverables to the client, including:

• Spec document – details how everything in the application will function, what options are available, and that limits scope
• Wireframe – layout of application screens without design (just black and white generic controls and data fields)
• User stories (use cases) – describing how the application will be used and by whom
• Mock Ups – the exact design (look and feel) of the application
• Workflow diagram – graphical diagrammed representation of the business processes that the application will adhere to
• Project plan – outlining the phases, development order and time frames required

With this information in hand, both we and the client are in the best position to move forward confidently with the actual development process.
At that point, to the extent that it’s feasible and beneficial, we go about carrying out the project using agile values and principles. All of my development team members are highly self-managed and I trust them to be working productively for the client’s good. We check in with each other often (although, as noted above, formal Scrum meetings don’t work out so well,) and keep the lines of communication wide open by leveraging technology and staying flexible in our professional schedules.

In the end, we’re able to consistently develop a highly planned and organized project with enough agility to respond to changing priorities and client needs. However, we find that the effort put into planning up front reduces the need for drastic changes that would otherwise disrupt even the most agile workflow.

So, from my own experience and that of my team, there you have the pros and cons of agile software development.

I’d be very interested to know your own thoughts or experiences if you care to share them in the comments below.