Customer satisfaction by rapid, continuous delivery of useful software
Your customers and users will be satisfied because you are continually delivering value with usable software. This is a stark contrast with the traditional Waterfall product delivery process. If your customers are used to Waterfall, they may find it strange to have working software sooner. The big downside of Waterfall is that you deliver large pieces of functionality towards the end of the project life-cycle. This means that all throughout the development stages of Waterfall, your project is incurring cost with no return on investment. By delivering working pieces of functionality sooner and more regularly, you're giving your users an opportunity to get a return on their investment sooner. Sure, they may not have all the functionality they need upfront, but they can start to make use of the solution to make their lives easier and start realizing the benefits sooner. People and interactions are emphasized rather than process and tools.
Agile is focused very heavily around people and the interactions between people rather than the processes and tools
This is a core value of the Agile Manifesto. This is important because it is the input from your team and customers that will ultimately make your project a success, as opposed to what tools you use. Continual collaboration throughout the entire development cycle of your project enables everyone involved to build a good working relationship based on trust. This trust-based working relationship is crucial when building software incrementally.
Continuous attention to high quality code and design
When working with Agile, you're working short iterations and only build what is necessary to satisfy the requirements for that iteration, and nothing else. This forces you to keep your design simple, which helps you design testable and more reliable systems. Developers understand and choose many solutions to solving a businesses problems, and these are choices that reflect a craft that balances design, use, and support. Developers provide the technical support to the team that enables them to always move forward at rapid pace and keep code quality high. Developers like to use the latest techniques for keeping their implementations simple and clean without having to rework any of their solutions.
One of these techniques is refactoring. Refactoring is the process of improving the design of existing code without changing its behavior. In order to make changes to the structure of the code, refactoring uses a quick succession of small, well-defined steps that can be verified as safe or functionally equivalent. Refactoring is most often done in conjunction with test-driven development where unit tests and simple design make it easier to refactor safely.
Simple design
Keeping your design simple (and not repeating code) helps you keep your code maintainable. If you design your code to be modular and interface-driven, then you can reduce coupling between objects, which leads to a more robust system.
Test-driven development
Test-driven development (TDD) is a way of driving the design of code by writing a test, which expresses what you intend the code to do, making that test pass, and continually refactoring to keep the design as simple as possible. TDD can be applied at multiple levels, for example, unit tests and integration tests. Test-driven development follows a rigorous cycle. You start by writing a failing test, and then implement the simplest solution that will cause that test to pass. Next, you search for duplication in the code and remove it. This is often called Red-Green-Refactor, and has become almost a mantra for many test-driven design practitioners. Understanding and even internalizing this cycle is key to being able to use test-driven design to solve your problems.
Embracing changes in requirements
Your customer or business sponsor may change their mind about what is being built. This may be because you have given them new ideas from software you delivered in a previous iteration, or because the company's priorities have changed or new regulatory changes have come into force. The key thing here is that you should embrace it. Yes, some code may get thrown away and some time lost, but if you're working in short iterations, then this lost time is minimized. Change can be very scary at first for clients and partners alike, but when both sides are prepared to take the leap, it can be mutually rewarding. In some ways, Agile is a simple idea, but the reality is that it can mean different things to different people, depending on their role in the software development process. One of the key things, though, is to be open to change, not just in order to move in traditional ways of organizing projects, but to adapt your use of Agile itself.
Early return on investments
Another advantage to releasing higher-value features early is you start to get a return on your investment. Running a software delivery team is expensive. You have permanent developers and testers, as well as consultants with expensive day rates. There's also business analysts and project managers, as well as other hardware and software costs. These are all costs to the business. By releasing early and generating revenue from your product, you can start to offset some of the initial investments and development costs. On the flip side of that, if you have a more Waterfall-based approach where you end up with a "big bang" deployment after a year or so, you will have already spent large amounts of money to fund the development with nothing to show until the end.
Feedback from your customers
If you release early, you can start to solicit feedback from your customers a lot sooner. These customers could be public-facing customers or business sponsors. I've worked on many projects where the business customer specifies requirements, which you then build, only for the customer to want changes once they have something they can use. This always seems to happen—it’s very hard for someone to specify a system without having something to play with. You can use prototyping software to help, but there really is nothing like giving them actual functionality early on to start using. One of the principles of Agile is to embrace change in the requirements. This should be expected, so giving your customer something they can give feedback on earlier in the process will give them an opportunity to make changes sooner without causing much disruption.
Feedback from real customers
Once you start getting feedback from real customers, you can start incorporating changes and new ideas from the feedback into the product. It is much more cost effective to make changes early on in a product's development cycle than it is to wait until the end after a large release has been made. It's not just customer feedback that helps you build the right product—by testing your product early in the marketplace, you can gauge customer uptake and see how popular the product will be, and continually deliver better quality.
Everything we have discussed so far has business benefits or culminates in the fact that you should be delivering a better quality product with every release. By releasing earlier and soliciting feedback, you can learn from the product performance earlier, and use this information to create something better. Product and system development is all about continuous learning and improvement, which is much easier to do when you're delivering a project by being agile. It doesn't matter whether you're using Extreme Programming, Scrum, DSDM, Crystal, or any of the other project management frameworks. If you adhere to the core values in the Agile Manifesto and routinely deliver high-value functionality early to your customers, monitor their usage, and listen to their feedback, you can apply this learning to the ongoing development and increase quality as you go along.
Disadvantages of Agile
Now that we have examined some of the advantages of Agile development, let's take a look at some disadvantages.
Difficult to assess the effort required at the beginning of the software development life cycle
One complaint I have often heard from business leaders and project managers alike, is that compared to Waterfall, it’s hard to quantify the total effort and cost to deliver a project. On one hand, I can see why they would think this, especially when they come from a regimented Waterfall process world. Indeed, it is harder to fully quantify how long the total project will take, but the mitigation for this is that a product will be delivered incrementally by giving the users the most valuable requirements first, meaning you can plan for the coming sprint (and maybe a few sprints ahead) to deliver a specified amount of functionality.
It can be very demanding on a user’s time
Active user participation and collaboration with the users of your system are required throughout the development cycle with Agile. This can be very rewarding, and ensures you deliver the right product to your users. It's a key principle with Agile to ensure that a user’s expectations are well-managed, and the definition of failure is not meeting your user’s expectations. However, this level of participation can be very demanding on the user, and requires a big commitment for the duration of the project. I have been in this situation many times where the business users love the idea of what Agile can bring to them, but they don't like the extra amount of time they have to spend on the project in addition to their current workloads.
Costs can increase as testers are required throughout a project instead of at the end of a project
Testing is a key part of an Agile project during sprints or iterations. This helps to ensure quality throughout the project without the need for a lengthy and unpredictable test phase at the end. However, this does mean that testers are needed throughout the entire product development life cycle, and this can dramatically increases the cost. This extra upfront cost does save you money in the long run though, as you are continually having people test your code. Having a combination of manual testing and automation testing is the best way to drive up the quality of your product. The cost of a long and unpredictable test stage at the end of a Waterfall project can, in my experience, cause huge, unexpected costs when a project overruns—and they frequently do overrun.
No comments:
Post a Comment