Is your Development Process Too Agile?
By Randy Terbush on November 2, 2014
Raising this question in some circles these days is nothing short of complete heresy. So much so that it appears many large organizations have not asked that question for themselves but instead, have plunged headlong into adoption of Agile. There is also a thriving Agile industry whose entire livelihood is dependent on convincing you that Agile will solve all of your software delivery challenges. The flood of positive stories about the use of Agile tend to drown out the more cautionary voices, sharing experiences that could be seen as somewhat contrary.
One size does NOT fit all when it comes to process. Whether it be a software development process, enterprise architecture process, change management process or any other process du jour that you can name. These rarely work out-of-the-box for an organization, and could actually cause REAL damage to your business if not chosen and implemented carefully.
Origins of Agile
If you read about the history of the Agile methodology, you’ll learn that the concept was contemplated several decades ago. However, judging by the number of software development process questions I was fielding between 1995-2000, I believe that Agile became popular as a result of an effort to codify the success of open source software development processes. The Internet was successfully using much of the software developed under open source processes, and many developers were asking their managers why they couldn’t operate in this same fashion since it was obviously delivering results much faster than current commercial processes.
Realities of using Agile
I’ve met with many large, globally distributed companies that are trying to behave like ten person startups. Not only does this forego the advantages of being a Fortune 500 company, but some of the processes commonly used in startup companies, like the Agile development process, put long established customers at risk and generally don’t work well in large, distributed organizations.
Know This: Adoption of the Agile development methodology means that you are accepting the fact that you will be releasing software to your customers that includes bugs and incomplete features. The goal of the Agile process is to release software quickly, knowing that the next release cycle is close behind and will fix more bugs and complete more features. I’ll repeat this point below in case you missed it here.
Should I use Agile?
Below is a list of questions that you should be asking yourself when choosing a methodology for your software development processes. If you answer “Yes” to more than one of these questions, then you should seriously reconsider using an Agile methodology. Instead, you might look for ways to create new technology by creating smaller incubation projects or look at some type of hybrid process that does not put your end product and customer at risk.
These questions are asked in the context of a single, standalone product. The Agile methodology may apply to some products within an organization and not others, provided that the product being developed under Agile methodologies does not have dependencies on other products and their release schedules.
- Do your customers consider your software to be mission critical to their business?
In my opinion, this is the most important question, and an answer of “Yes” should allow you to skip the rest of the questions.
If your customers cannot tolerate a few bugs or incomplete features in your product or service, then you must recognize that you will lose customers as a result of adopting Agile processes to deliver that product.
Agile, by its definition, means that the very short release cycle will contain bugs and will likely include features that are incomplete or at least have not had any real customer feedback to establish a complete set of user stories (requirements).
- Is your development team for this product more than 20 people?
The number “20” is somewhat arbitrary. The point being made here is that the team must be relatively small in order to remain “Agile”.
- Does this product have integration dependencies on other products not following an Agile development methodology?
Agile teams will struggle to work with other application teams not working at the same pace. Even individual Agile product teams will more than likely be on their own schedules, so expect that there will be misses between the teams. The good news is that the development cycles are short enough that you might resolve the issue before anyone notices.
- Are any of your functional teams not co-located?
“functional teams” are defined as your development team, test team, product management team, operations team, etc.
It would be bending the rules a bit to not have everyone in the same building. That said, it can work if at least the functional teams are in the same building and your interactions between the functional teams are effective remote working relationships.
This question will knock out most large organizations since some component of a development team is often “off-shored” or the product serves multiple divisions of the business, each with their own product management duties for that customer segment.
- Are any of your functional teams not using the Agile process?
It is nearly imperative that every functional team in the chain of the Software Development Life Cycle be using the same development process. This will become painfully obvious if one segment in that chain of responsibility starts using Agile while others do not. Therefore, at least from a standalone product standpoint, a commitment to Agile is an all or nothing endeavor.
If any of this resonates, rest assured that you are not alone. Many large organizations are realizing that being Agile means adopting many other changes to their business that are not necessarily positive change.
Why would anyone use Agile?!!
Now before anyone threatens me with bodily harm for taking such a position, let me give credit to the things that Agile does well.
Agile is ideal for small, self contained teams that are trying to change the world. These types of development projects need to get things done fast, with some amount of structure in the process of delivering the product. Startups, Innovation teams within larger companies. There is no reason to burden these types of efforts with excessive rigor and overhead when the end goal is to try to get something done that can prove a concept or market.
Agile might be the right methodology if you are developing a gaming or media product that is not necessarily mission critical to your customers; (ie. Failures are not going to cost your user money, lives or business) However, as soon as that product crosses the threshold into where it costs YOU revenue when there are failures, it might be time to add a bit more rigor into your SDLC.
I hope you’ve enjoyed reading this post. Please share if you feel others would be similarly entertained.