For someone in charge of software development, agile methods should be a process that you investigate. The movement of agile methods into the mainstream makes it imperative to delve into the reasons why agile development is working in many organizations.
Organizations with software development groups have processes that allow the organization to predict development efforts. Even if the organization does not have that process defined formally, there is a process. In cases where your process is not formerly defined, that would be referred to as "cowboy coding" techniques. What follows is a brief description of Agile development along with reasons why an organization would adopt agile methods.
There are many different types of software development methodologies. Three broad categories are Waterfall, Cowboy, and Agile methods. There are many different types of these methods that could be used. Below is a quick definition of these three categories. For more detailed explanations, see the links.
Many large organizations use a heavily documented method called Waterfall Software Development, or Waterfall for short. The name derives from the method of completing one part of the process, and moving it on downstream to the next process. When shown in a graphical way it could remind you of a waterfall.
Waterfall teams will spend a lot of time planning the entire project in the beginning, using a well defined requirements document. The time taken to plan for waterfall projects all happens in the beginning of the project. When the planning is done, the team begins building the software. The team follows the requirements document and builds to "spec."
Changing requirements can cost the customer a lot since this method assumes that all requirements are captured in the original specification. An elaborate change management process allows changes to that specification.
Once development is completed, the Quality Assurance (QA) department will run tests, and send defects back to the team to fix. During this phase, the team continues to fix issues, and send the fixes back to QA for testing. Once QA deems the software is ready for production, the software is deployed to production. The project is completed by getting sign off from the customer or business rep that they agree the project was delivered. Usually this is done with a formal document.
Cowboy coding is used by many small companies with 1 or 2 developers. But those organizations are not the exclusive domain of this method. Companies that eschew processes tend to encourage this type of development.
When an idea for the software is approved, the idea is sent to the developers who implement this any way possible. Usually the QA process is done by developers and customers. The intent here is to get the product to market quickly at all costs. There is usually a belief by top levels of the organization that process wastes resources.
There may not be a project defined per se, so there really is not a clear end of the project. When a new feature or idea is to be implemented, it is given to the developer who implements it as time permits. Or if this is an important feature, they need to work on it immediately.
Agile uses the least amount of documentation necessary to deliver a high quality project quickly. This does not mean that Agile does not require documentation. Agile asks for documentation, but kept to a minimum, not to burden the team.
In agile, planning is kept to a minimum at the beginning of the project, and planning continues throughout the project. Planning involves the entire team, Customers, Developers, QA and Analysts together. Note that agile does not eschew planning! Far from it agile encourages continuous planning.
Changes can be made throughout the life of the project with little ceremony. This allows customers to get new requirements into products late in the release. This feature of agile is endearing to many of the stakeholders who work with agile teams. Tight feedback loops are encouraged through daily standup meetings, iterative development, and frequent planning meetings.
Why use Agile?
The easy advice to the question, "Why use agile?" is to ask, does your current method work? Are you delivering high quality software, quickly and when the customer needs it. If you are, then you may not want to consider agile. If you are having problems with that, or your staff is tired of running death marches at the end of your releases, agile may be for you!
Agile methods assume that the projects they are used for do not actually have a good definition of the requirements at the beginning of the project. The assumption is that a lot of discovery of features will happen during the development life cycle. Because of this methods, like Scrum, XP, Crystal, Kanban etc. encourage tight feedback loops to allow the teams to change requirements quickly. Below are more detailed explanations of main reasons to use agile.
Tight feedback loops
Having quick feedback from customers and stakeholders on software features is desirable for many reasons. The ability to deliver what the customer wants the first time is probably the best reason. But others include help in honing the requirements, receiving information on changes in a timely manner, and building trust with your stakeholders.
Figure 1: Tight feedback loops.
The methods for creating tight feedback loops vary slightly from Agile method to Agile method. But some are consistent. Daily standup meetings are common in Scrum, XP, Kanban and others. These are 15 minute meetings where information is communicated quickly and concisely. The participants are the team members, developers, QA, business analysts, business owners, Project managers etc.