Agile Software Development
A software development project typically has many unknowns, especially early in the development cycle. Because of this lack of predictability, agile software development uses an empirical, adaptive approach which allows for requirements to change and become refined over time.
There are purposely no hard-and-fast “rules" that define a cookbook approach to agile software development, and with the mixing and matching of techniques and practices, there could be an infinite number of methodologies that might be considered agile.
In fact, techniques and new approaches continue to evolve to solve challenges around scalability, for example.
What then, makes a particular approach or methodology agile? There are certain characteristics that apply to agile methodologies that embody the principles and values in the Agile Manifesto. Let's look at how those principles apply to agile software development.
One of the primary distinctions between an agile methodology and a traditional methodology such as the waterfall methodology is the iterative nature of agile project management and development.
Rather than planning all the detail for the entire project up front, the project is broken down into smaller product increments that are developed in short iterations, with details being refined over time.
Working iteratively allows the team to deliver working code frequently, continually gathering feedback from customers so that they are able to course correct, improve processes and more easily make requested changes.
It is through iterative development that an agile development team is able to provide changes to the requirements, even late in the development cycle.
Deliver High-Value Software Frequently
Several of the agile principles stress the importance of delivering high-value software. By working iteratively and continually refining the priorities of the requirements from the business, the team is able to deliver high-quality software frequently in accordance to the customer's needs.
In agile software development, there is the concept of developing code in “vertical slices" that provide value to the end user from beginning to end. Rather than creating a very complicated user interface with no back-end functionality, the team would first create a simple function that included the user interface, the business logic and any back-end database function.
This increment of code is intended to be fully functional, but purposely does not include extraneous bells and whistles upon early delivery.
The team focuses on simplicity, maximizing the work not done. Working software is the primary measure of progress. Rather than a fancy user interface that doesn't provide functionality, it's better to start with a simple UI that includes functionally operational software.
Agile software development emphasizes the need for strong communication with cross-functional teams. Not only is communication improved within the development team with developers and testers working side by side, but also within the business community because of the constant feedback from stakeholders and business users.
Agile principles state that business people and developers interact daily. This principal is met when a business representative is included in a cross-functional team that meets daily.
Another principle stresses the importance of face-to-face communication on a development team. Though there may be debate in today's world on whether this still applies because we now have new tools available to facilitate distance communication, the principle is about the importance of strong and respectful communication.
Team members must trust one another, and some argue that if they are communicating via tools, they may lose vital communication that is only apparent through body language.
Agile software development principles are heavily focused on leadership style, which empowers and motivates teams by giving them the support and trust needed to get the job done. By providing this intrinsic motivation, individual contributors are empowered to design innovative solutions and give continuous attention to technical excellence and quality.
Rather than management pushing the team to meet unrealistic deadlines, agile software development teams are empowered to provide realistic dates of what they can accomplish and by when. Because scope is more flexible than in a traditional environment, the team is constantly delivering value, and the business requirements and priorities are continually being reassessed.
Working in a self-organized manner allows for the best architecture, design and requirements to emerge. The cross-functional team works together at a sustainable pace rather than in an environment where each functional team is responsible for a particular phase of the development cycle.
Finally, the agile software development team regularly reflects on how effective they are, tunes and adjusts accordingly. Because there is such variety in agile techniques and processes, and in opinions on the interpretation of the principles, there is often debate about whether a methodology, software team, organization or culture is “agile."
If, for example, a software team is geographically distributed, are they violating an agile principle, and thus deemed not agile? If the team understands the end objective of the principle, and reflects how they can achieve that principle, they are practicing agile.
So, the question asked above could be reframed: Is the geographically distributed team communicating efficiently and effectively? If not, the team needs to brainstorm as a group on how they can improve their communication, perhaps with increased budget for travel or by experimenting with new tools.
The goal in agile software development should not be for a team to attain a certain level of “agility," but rather to understand how to best please the customer and to continually improve.