What Agile Development Means to You
Agile software development isn’t new anymore; the concept has been around for well more than a decade and has dramatically shifted the way software development is done. It has moved us from a wasteful industry filled with immense design documents, big releases, and uncertainty around eventual customer satisfaction to one where the customer’s increased visibility into the project allows the end result to be exactly what is needed without the waste of unwanted features or significant rework.
This post is not going to be a detailed description of what agile is; that information is generally available. Instead it will concentrate on how agile development affects everybody involved in a software project.
As a customer, you may not have thought about what working with an agile firm or development team means to you, but the difference between agile and more traditional methods can be significant:
- More chances to review the work. Agile gives you more frequent chances to review the work being done. Rather than having to wait until a large release is ready, you can see work as individual features are finished. This allows you to quickly detect when the team is going in a direction you are not happy with and to provide your feedback so that it can be incorporated into the remaining work.
- Get important features quickly. Since you will be responsible for approving and prioritizing the individual features to be included, you can be sure that the team spends its time working on the items that are most important to you.
- Fulfilled commitments. Agile development encourages the development team to commit to work and deliver on those commitments. Because the tasks set to the team are small and well defined, it is much easier for the team to be sure they are estimating the time they will take to complete correctly.
- Can require more work. Agile provides a lot of benefits to the customer, but the extent of these benefits is directly proportional to how involved you want to be in the process. If you want the development team to just handle it and show you the end product you will see fewer benefits than if you are engaged and participating in the process.
Since agile is all about how you do your work, it shouldn’t come as a shock that it will feel very different than more traditional development management styles:
- Increased team cohesiveness. Agile makes you feel more connected to your coworkers. It becomes less about the individual’s accomplishments or failures and more about the team’s accomplishments or failures.
- Better direction. The team will be involved in planning their work and will have specific tasks to be completed. Reduced leniency for vague requirements means that you will know exactly what you should be working on.
- Better communication. Daily in-person meetings with your team mates insure that everyone is on the same page.
- Improved quality. Because agile development advocates practices such as pair programming and unit tests, you will have the tools necessary to be sure that you are producing a quality product.
- Increased accountability. Agile requires team members to feel accountable for their performance and the performance of their team. Without the drive to complete your commitments agile will not work.
The decision to follow an agile methodology often starts with you. You have read about all of the benefits to your customers and to the team, but what do you as a manager of software development projects get out of it:
- Improved visibility into project status. With agile development it can be easier to see when your team is struggling. Rather than massive project plans that you keep up manually, your team is responsible for reporting on their progress.
- Better communication. Daily meetings ensure that you know when your team hits a road block and allows you to react quickly to address the problem.
- Unexpected changes are easier to manage. When your customer changes their requirements or priorities mid-stream, it is easier to adapt. You can easily estimate the new tasks and substitute them for tasks that have not been started to allow your team to continue working on what the customer wants. In a more traditional setting, you would need to evaluate how the new request fits into the design documents that have been prepared and make appropriate modifications before the team can effectively continue their work.
- Be ready to adapt. You may read all the books and think you know exactly what you are getting into but there are always surprises. Agile is not a one size fits all arrangement and it can affect organizations very differently. The “rules” of agile development should be viewed as guidelines more than rules. If a piece of your chosen agile methodology isn’t working for your team, don’t be afraid to change it.