Author's Notes: For the purpose of this article, we will break software types into two categories with four sub categories: In house developed (packaged software including downloads, enterprise applications and software as a service, web) and outsourced software (can be any type). The subcategories are not mutually exclusive as SaaS software can be Web and/or Enterprise in nature and vice versa. Additionally, we will approach software development from two standpoints; strategic and tactical. Strategic software development exists when the business develops and sells software as their primary source of revenue and tactical development exists when a company develops software software as secondary to their business strategy or outsources development of custom software to a contractor or development company.

No software development model has become quite as wide spread in software as Agile. The problem is, it shouldn't be as wide spread as it is and only fits in a relatively narrow "home ground". While there isn't any readily available academic data on the failure rate of Agile adoption, a quick search of almost anywhere software developers post turns up countless posts on the topic like THIS or THIS (potential NSFW content on the second link).

Quite a few software developers dislike Agile and for good reason. Following the second link, you'll even see a post with a video of one of the original Agile creators criticizing current Agile practices. To be clear, this article isn't about bashing Agile. Quote the opposite, Agile and the Agile mindset are extremely powerful tools when properly applied. Part of the problem is Agile is treated as a methodology when it is not. Agile is a mindset that can be applied both along with and in absence of other software processes. When people talk about Agile as a process they are often referring to Scrum which, depending on its implementation, may or not be Agile. While Agile concepts can be applied to nearly any type of software project or incorporated into other development methodologies, including Waterfall-like approaches, Agile by it's very nature works the best when the Agile Manifesto is followed in it's entirety, both the values and principles.

Before reading further take a second to read the four values and twelve principles in the Agile Manifesto link above if you haven't already. How many of the principles ACTUALLY apply to your development organization? Be honest here. If you are developing custom software for non-technical organizations or are a software development group within a non-technical company who develops software for other internal groups, I'd say most if not all values and principles apply in your case. If you are developing software as your primary strategy I'd guess half, at best, apply. If you fit into the later category, you are probably a strategic development company as defined above and Agile isn't going to work for you, at least not in it's "stock" form. Feel free to skip to "Why Agile Fails in Other Circumstances". If you are in the other group where most if not all values and principles apply, adopting an Agile mindset and a process based on Agile principles may be a good decision for you. Continue onward.

Agile's Home Ground

When you have a small group of very motivated co-located developers and a customer, either internal or external, who is highly engaged in the project you are in the butter zone for Agile or utilizing an Agile development process like Scrum. In these cases, magic happens. The dev and product sponsor sit down with the customer, develop user requirements, the dev team sets out to deliver, the customer sees whats being developed in real-time and provides feedback on a regular cadence which the development team then takes and either implements or modifies what was recently developed. Ultimately, the delivered software should meet the customer's exact needs. Everyone is happy. Even when setbacks happen, the team can bounce back.

When the circumstances fit the above, Agile is at its best. The two types of projects that typically (but not always) fit this ideal are projects developed for a non-technical organization by a third party developer or projects where a technical development group develops software for a non-technical internal group (the internal customer). In these types of projects, the customer has an idea of what they want the software to do but not exactly how. The project team consisting of a mix of business and technical people sit down and solve the "how" with the understanding that they may not get the "how" exactly right on the first try. When the customer is excited to work with the developers and that excitement and collaboration mentality permeates the rest of the project, Agile is right at home and the team can properly iterate to deliver the near perfect solution to the customer

When starting any project that MAY be a fit for following an Agile-like approach, it's a good idea to analyze if the Agile approach would be the right fit. The exercise I've used is to pull up the Agile Manifesto and develop questions around the twelve principles. Asking questions like "Is the customer highly engaged or just want to give you info and get back finished software?", "Do the developers on this project have the ability to think in an Agile way or will they be frustrated if frequent changes are needed?", "Is the feedback cycle of Agile even needed for this project?". While there are quite a few more questions to answer, the key point; proper analysis is the key to successfully adopting Agile.

In my observation, there are a few unspoken skills and factors required to maximize Agile's effectiveness:

1. All team members have superior communication skills
2. All team members must be natural collaborators, including across roles
3. All team members are relatively senior in their role
4. The project doesn't have a hard deadline
5. Team members have complementary work styles
6. Team members are co-located, preferably in the same area if not in the same wallless desk area
7. Team members have preexisting friendly relationships
8. All team members have a familiarity with the chosen project tools

Of course, your experience may be different than my observations but I'd hazard you have similar observations as well.
Taking all of the above into account, if Agile or Agile based processes are incorrectly rolled out, Agile can still be a detriment rather than an asset.

Why Agile Fails in Other Circumstances

When attempting to implement Agile principles in circumstances other than those outlined above, you are frAGILE rather than Agile. The methodology may work for a little while but will eventually break down, may fail outright or may not deliver the value that adopting another development methodology or mindset would. The reasons are pretty simple if you read the Agile Manifesto. Strategic software of all types don't have a clear singular customer who can collaborate continuously throughout the software development lifecycle, many users will absolutely not tolerate frequent software changes, working software is not the primary measure of progress, self-organizing teams just can't happen in many strategic development organizations, multiple teams on a single project are often utilized and collaboration between teams isn't inherent to Agile, projects generally have a set release target and many organizations aren't tolerant to change. Yeah, these reasons kill off about half the values and principles in the Agile Manifesto.

Now layer in some of the realities of enterprise software; the need for complete documentation to meet regulator requirements, boards and investors who want to see a long term road map presented, followed and milestones met by the quarter regardless of what that means to the development team and the need for strict overarching software architectural and development guidelines. Yeah, now you are so far from being able to adopt an organizational Agile mindset that attempting to roll out Agile principles will just lead to very bad things ranging from dysfunctional teams to developer death marches resulting in poor quality deliverable, burnout, missed strategic date targets and ultimately employee and management attrition.

So why has Agile become so popular? Simple psychology. Agile has long been sold as a panacea for all that ails you by so-called evangelists. On paper Agile principles sounds fantastic to management; 'You mean we will instantly go from under performing, can change requirements constantly and the dev team will be cool with it AND we will start hitting all of our date targets? Let's do it!". When "consultants" present examples like those in the "Agile's Home Ground" section above and tell management that they too will see the same in their organization, it's hard not to get excited about Agile. That's just human nature but is a generalization fallacy. Less this article spiral into a bitchfest about my disdain for "evangelists", I'll just summarize instead. If a process is sold to you without presenting multiple options and conducting analysis to help decide which process is best for your business, that process is at best a crap shoot if it will work and at worse, complete bullshit.

Often Agile, and by extension Scrum, is presented as the alternative to Waterfall as if Agile and Waterfall are the only two options available. Unfortunately, this is a false dichotomy and a myth that has been spread in the software community for a while. There are a whole range of concepts, both processes and philosophies, that can be adopted depending on the factors that should be analyzed to determine what is best for an organization, group or team. Even different projects run by the same team may need to use different methodologies and processes that better fit to the circumstances of the specific project.

If you need help determining optimal development processes for your organization or projects, we are more than happy to help. Drop us a line HERE.