When the Agile Manifesto was introduced almost 15 years ago, it proposed a radical methodology change as an alternative to traditional project management. With agile, project requirements and solutions evolve through collaboration in development cycles that break tasks into small increments. While this methodology helps businesses manage unpredictability, it also requires those businesses to adopt a different mindset in order to be successful.
Agile is designed to drive collaboration, transparency, and quality within product and software development lifecycles, but it isn't always the right answer for every organization. In fact, the signers of the Manifesto will tell you that, while there is value in examining what agile is, there is just as much value in examining what it is not.
It is not a silver bullet, nor is it necessarily the cheapest option. It's a just a framework to align delivery teams to deliver working software more collaboratively and with better quality.
With agile there are tremendous benefits from the business and the development perspectives: you can generate positive results for IT, and at the same time, get to market faster and increase your competitive differentiation. But how do you decide if introducing agile gradually (known as an agile adoption), or implementing agile across your organization (known as an agile transformation) is right for you?
A good place to start is by examining your company's product development or project management culture. If your organization has demonstrated success using the predictive, traditional waterfall development methodology, there may be real value in continuing to assemble your teams, work on discovery, generate detailed requirements, design the solution, develop the code, test the code, and then deploy it to your production environment. In other words, if your organization's SDLC isn't broken, then for goodness' sake don't fix it!
If your organization is susceptible to waterfall's limitations, however, agile may be a more viable option. Some business leaders become frustrated with the tremendous investment of the delivery teams' time at the front-end of projects as they work to make analysis and development decisions about a product they may know very little about. After all, agile argues, why spend so much time defining a product when you know the least about it?
Adages aside, if not handled correctly, the project may be subject to costly late-stage rework, as project needs shift. This also leads to the delivery of a product the business thinks it wants and not what it needs.
Agile leverages team uncertainty and lets team members do what they do best: visualize a solution, engage the right people, and build a potentially shippable product. In this sense agile turns the more traditional ways of developing software development model upside down by: 1) favoring collaboration between the development team and the client over costly time spent working through contract language and requirements, and 2) focusing on engaging individuals and fostering interactions over processes and tools.