Agile is a software development methodology to build software incrementally using short iterations of 1 to 4 weeks so that the development is aligned with the changing business needs. Whereas the traditional “waterfall” approach has one discipline contribute to the project, then “throw it over the wall” to the next contributor, agile calls for collaborative cross-functional teams.
Agile isn’t defined by a set of ceremonies or specific development techniques. Rather, agile is a group of methodologies that demonstrate a commitment to tight feedback cycles and continuous improvement.
With Agile development methodology –
- In the Agile methodology, each project is broken up into several ‘Iterations’.
- All Iterations should be of the same time duration (between 2 to 8 weeks).
- At the end of each iteration a working product should be delivered.
- In simple terms, in the Agile approach the project will be broken up into 10 releases (assuming each iteration is set to last 4 weeks).
- Rather than spending 1.5 months on requirements gathering, in Agile software development, the team will decide the basic core features that are required in the product and decide which of these features can be developed in the first iteration.
- Any remaining features that cannot be delivered in the first iteration will be taken up in the next iteration or subsequent iterations, based on priority.
- At the end of the first iterations, the team will deliver working software with the features that were finalized for that iteration.
- There will be 10 iterations and at the end of each iteration, the customer is delivered working software that is incrementally enhanced and updated with the features that were shortlisted for that iteration.
Advantages of Agile Methodology
- In Agile methodology the delivery of software is unremitting.
- The customers are satisfied because after every Sprint working feature of the software is delivered to them.
- Customers can have a look of the working feature which fulfilled their expectations.
- If the customers have any feedback or any change in the feature then it can be accommodated in the current release of the product.
- In Agile methodology the daily interactions are required between the business people and the developers.
- In this methodology attention is paid to the good design of the product.
- Changes in the requirements are accepted even in the later stages of the development.
Disadvantages of the Agile Methodology
- In Agile methodology the documentation is less.
- Sometimes in Agile methodology the requirement is not very clear hence it’s difficult to predict the expected result.
- In few of the projects at the starting of the software development life cycle it’s difficult to estimate the actual effort required.
- The projects following the Agile methodology may have to face some unknown risks which can affect the development of the project.
Why choose agile?
Teams choose agile so they can respond to changes in the marketplace or feedback from customers quickly without derailing a year’s worth of plans. “Just enough” planning and shipping in small, frequent increments lets your team gather feedback on each change and integrate it into future plans at minimal cost.
But it’s not just a numbers game—first and foremost, it’s about people. As described by the Agile Manifesto, authentic human interactions are more important than rigid processes. Collaborating with customers and teammates is more important than predefined arrangements. And delivering a working solution to the customer’s problem is more important than hyper-detailed documentation.
Agile software development methods
Agile software development methods support a broad range of the software development life cycle. Some focus on the practices (e.g., XP, pragmatic programming, agile modeling), while some focus on managing the flow of work (e.g., Scrum, Kanban). Some support activities for requirements specification and development (e.g., FDD), while some seek to cover the full development life cycle (e.g., DSDM, RUP).
Popular agile software development frameworks include (but are not limited to):
- Adaptive software development (ASD)
- Agile modeling
- Agile unified process (AUP)
- Disciplined agile delivery
- Dynamic systems development method (DSDM)
- Extreme programming (XP)
- Feature-driven development (FDD)
- Lean software development
- Rapid application development (RAD)
- Test Driven Development (TDD)
Let’s go though some of the methods in detail.
eXtreme Programming (XP)
Extreme Programming technique is very helpful when there is constantly changing demands or requirements from the customers or when they are not sure about the functionality of the system. It advocates frequent “releases” of the product in short development cycles, which inherently improves the productivity of the system and also introduces a checkpoint where any customer requirements can be easily implemented. The XP develops software keeping customer in the target.
Extreme Programming is a software development methodology consisting of practices like –
- Pair Programming
- Test Driven Development
- Continuous Integration
- Code Reviews
Why is it called “Extreme?”
Extreme Programming takes the effective principles and practices to extreme levels.
- Code reviews are effective as the code is reviewed all the time.
- Testing is effective as there is continuous regression and testing.
- Design is effective as everybody needs to do refactoring daily.
- Integration testing is important as integrate and test several times a day.
- Short iterations are effective as the planning game for release planning and iteration planning.
Extreme Programming involves −
- Writing unit tests before programming and keeping all of the tests running at all times. The unit tests are automated and so this eliminates defects early, thus reducing the costs.
- Starting with a simple design just enough to code the features at hand and redesigning when required.
- Programming in pairs (called pair programming), with two programmers at one screen, taking turns to use the keyboard. While one of them is at the keyboard, the other constantly reviews and provides inputs.
- Integrating and testing the whole system several times a day.
- Putting a minimal working system into the production quickly and upgrading it whenever required.
- Keeping the customer involved all the time and obtaining constant feedback.
Feature Driven Development (FDD)
This method is focused around “designing & building” features. Unlike other agile methods, FDD describes very specific and short phases of work that has to be accomplished separately per feature. It includes domain walkthrough, design inspection, promote to build, code inspection and design. FDD develops product keeping following things in the target
- Domain object Modeling
- Development by feature
- Component/ Class Ownership
- Feature Teams
- Configuration Management
- Regular Builds
- Visibility of progress and results
Kanban is a popular framework used to implement agile software development. It requires real-time communication of capacity and full transparency of work. Work items are represented visually on a kanban board, allowing team members to see the state of every piece of work at any time.
Kanban is enormously prominent among today’s agile software teams, but the kanban methodology of work dates back more than 50 years. In the late 1940s Toyota began optimizing its engineering processes based on the same model that supermarkets were using to stock their shelves. Supermarkets stock just enough product to meet consumer demand, a practice that optimizes the flow between the supermarket and the consumer. Because inventory levels match consumption patterns, the supermarket gains significant efficiency in inventory management by decreasing the amount of excess stock it must hold at any given time. Meanwhile, the supermarket can still ensure that the given product a consumer needs is always in stock.
When Toyota applied this same system to its factory floors, the goal was to better align their massive inventory levels with the actual consumption of materials. To communicate capacity levels in real-time on the factory floor (and to suppliers), workers would pass a card, or “kanban”, between teams. When a bin of materials being used on the production line was emptied, a kanban was passed to the warehouse describing what material was needed, the exact amount of this material, and so on. The warehouse would have a new bin of this material waiting, which they would then send to the factory floor, and in turn send their own kanban to the supplier. The supplier would also have a bin of this particular material waiting, which it would ship to the warehouse. While the signaling technology of this process has evolved since the 1940s, this same “just in time” (or JIT) manufacturing process is still at the heart of it.