While traditional teams are based on hierarchy and bureaucracy, Agile teams are flat including Product Manager, Developers, Database Administrators, and Quality Assurance Analysts. Many Agile teams collaborate with each other to achieve a common goal without infringing on each other’s progress.
Before the use of Agile methodology, software development was accomplished via Waterfall Methodology which includes following particular phases of software development in order. The phases include Requirements, Design, Coding, Testing, and Deployment. In Waterfall method, one moves to the next phase only when its preceding phase is complete and verified. Setting the requirements and specifications of the software before starting the development is very important in Waterfall Method. Extensive documentations are written to clarify the specifications to an extent that these documentations become the user guide of the software. Software is developed in full and then tested and delivered to the customer meeting the specifications. Another phase of development starts with documentation of new set of specifications and requirements.
This presents many challenges, some of which include changing business requirements or the technology supporting the software mid development. In addition, the customer is not able to view the progress of the software development or provide feedback. The customer is stuck with the original requirements which might not be of any business value anymore.
The software delivered using Waterfall Method is sometimes simply out of date. Since the customer and features requested by the customer is the biggest driving force in the development of the software, missing this mark means disaster. Hence, instead of using the waterfall method, iterative methodology was introduced to accommodate rapidly changing requirements which became known as Agile Software Development Methodology.
Agile Methodology accommodates rapidly changing requirements by developing the software in iterations or sprints and delivering each iteration of the software to the customer to show progress and request feedback. Agile methodology offers flexible development, early delivery, and continuous improvement.
The iterations or sprints break product development work called product backlog, into small increments that minimize the amount of up-front planning and design. Backlog is broken down into iteration by the Product Owner based on the business value and priority. Iterations or sprints are short time frames that typically last from one to four weeks. Each iteration involves a cross-functional team working on all aspects of the software development: specifications, analysis, planning, design, coding, and testing. Iterative Methodology requires face to face communication including a daily standup meeting to discuss the issues and progress of the sprint.
The progress of the entire product development and each sprint is analyzed by using Burn-Down and Burn-Up Charts. At the end of each iteration, for example every 2 weeks, a working product is demonstrated to the customer. This method reduces risk by showing progress of the software to the customer and adapts to the changes requested by the customer. An iteration does not add enough functionality to make the software viable for market release as multiple iterations are required to release a version of the product.
Two of the most widely used Agile software development frameworks are Scrum and Kanban. Agile methodology and the frameworks supporting Agile Methodology themselves continue to evolve as well.
Agile Methodology Values:
1. Individuals and Interactions over processes and tools
2. Working Software over comprehensive documentation
3. Customer Collaboration over contract negotiation
4. Responding to Change over following a plan
Communication is very important. Following a set of bureaucratic process delays the communication and the process required to make a change. It is far better to have five people in the room to discuss an issue, feature, or a requirement than to route an email or an issue ticket to each one of these individual and then coordinate a formal process.
Customers want to see the progress of the project hands on rather than looking at a spreadsheet with tasks and status which they cannot comprehend. Just like a picture is worth a thousand words, presenting a piece of working software is more useful than presenting documents in a meeting with customers. This is the reason why I released minor versions of the Phonora Photo Gallery Software to show progress and new features of the software rather than providing status updates.
It is a challenge to successfully capture all customer requirements at the beginning of the software development cycle. In addition, it is difficult to get customer feedback without showing the actual working software to the customer. So, it is better to directly involve the customer in the development of the software and deliver each iteration or sprint to the customer for direct feedback. Instead of negotiating contract with set specifications, gather live feedback from the customer and accommodate any changing requirements. This assures that the software is being built directly with the features the customer has in mind.
Accommodating changing requirements is very important than following a plan. In the world of rapidly changing technology, a plan could become old even before delivering the software. Following a set and rigid plan could mean disaster. After gathering feedback and any new requirements from the customer, it is crucial to respond to these changes in timely manner to deliver the software expected by the customer.
There are 12 principles of Agile software development