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.
[login]
Defining Terms
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.
Waterfall
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
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
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.Most agile methods recommend iterations. These can be fixed length iterations, or regular releases. Along with iterations agile includes regularly timed planning meetings. For instance in Scrum, iterations are called Sprints. These sprints can last from 1 to 4 weeks. When the iteration is complete, teams demonstrate the features they have completed in their planning meetings. This allows the customers to see working software, which may lead to new features that they want. This also allows customers to confirm that they have features that are useful.
Since the planning meetings happen often, customers have more chances to make changes based on feedback from these planning meetings, and feedback from the market. If a competitor comes out with a new feature in the middle of the project, the customer can add that feature to the backlog, and get that feature into production before you release.
Development is more predictable
Most departments outside of IT, and especially those business departments driven by accounting and sales crave predictability. Agile development allows teams to deliver their software to business more predictably.
Agile methods ensure more predictable delivery by breaking requirements down into smaller chunks. Many methods use stories to represent the requirements. Other methods use Minimum Marketable Features or MMF’s which are then broken down into stories and tasks.
Most teams will estimate stories or MMF’s using something like points which allow the teams to give an estimated effort. If estimated effort is larger, or seem really large, these items must be split into smaller stories or MMF’s or refined.
By using consistent methods to estimate stories, this drives consistency in the requirements. Stories that are too vague, or too large, can be split to more manageable features, which allows teams to work on requirements in more of a rhythm. The team can then use tools such as burn down charts, velocity charts or cumulative flow diagrams to determine their delivery rate.
Teams that find their development rhythm help those stakeholders feel confidence in promising delivery dates. The more the team delivers consistently, the more these stakeholders rely on the team, and make them part of the whole organization.
Deliver Transparency
Transparency of the teams progress on a daily basis helps upper management in the trust category. Also, with transparency, risks can be handled more quickly and directly, than when things are hidden in reports, or in tools.
Multiple methods allow agile teams to be transparent with people outside of the IT department. Daily stand up meetings allow the marketing, sales, product owners and anyone with a stake in the project to monitor progress daily. While these stakeholders may not always be in the daily stand up, they can listen in once or twice a week to see what stories the team is working on, and if there is anything blocking the team.
The demonstrations of the software before each planning meeting, show those same stakeholders what the team can actually deliver if the project was finished on that day. Agile teams can be in team rooms with Big Visible Charts. Those team rooms keep the charts updated each day, so a stroll into that room would show a plethora of information. What stories the team is working on. What velocity the team is working on. How many features are in the backlog. Some teams also have methods to show what business value stream the team is working on.
Deliver More Value
Using many of the methods mentioned above, agile teams tend to deliver more valuable software than comparable waterfall projects. This does not mean that agile teams deliver more features than waterfall projects. But the tight feedback loops allow these teams to focus on features that are valuable to organization closer to the end of the project, as priorities change.
For instance, in a project for a health care software maker, the team starts out with a backlog of 50 stories. Within those stories, there are some stories that discuss allowing customers to track where their claim is in the process, including where in the mail it is. Those stories are kept in the backlog and not prioritized as the release date gets closer.
Three sprints away from the release date, a new government regulation is passed that affects this project. The product owner can now keep opt to keep the first story group in the backlog, until the government regulation stories are complete. The customer tracking stories may need to go into the backlog for another release, or they can decide to extend the release date to get those stories in. Either way, the team was able to deliver immediate value quickly to the business, by having a way to change what features they are working on quickly.
Sustainability
Agile methods also allow teams and projects to be more sustainable. First agile methods emphasize a sustainable development pace over the hills and valleys of death march development. Death march development, refers to development at the end of a release, when the team realizes that they are not going to be able to deliver what the requirements by the time committed to.
In waterfall environments, the manager calls an all hands meeting, tells the team they need to work overtime, at night and on weekends so they can meet that deadline. The team does all that work, but still fails to deliver what the customer wanted, resulting in some more overtime. When that is finished, team members take vacation, look for other jobs, and generally are not satisfied with their work.
Agile methods show the velocity of the team, and allow the team to adjust to what can actually be delivered on time. By allowing this, the entire team can continue developing at a predictable pace. As the team matures, that pace should increase. So keeping those team members around can increase the bottom line, by allowing the team to deliver higher quality more rapidly.
Using Agile
The ideas articulated above are some good reasons to experiment with using agile methods in your shop. There are more reasons and more resources that can help in the decision. To get started, research what method you are interested in. Then consider attending a course, or bringing in a coach experienced in that flavor of agile to help your team get started. Doing so, should help your organization become better at delivering high quality fast!
