#100DaysOfCode Day 43: Agile Software Development
In software development, Agile approaches development requirements and solutions through the collaborative effort of self-organizing and cross-functional teams and their customers.
It advocates adaptive planning, evolutionary development, early delivery, and continual improvement, and it encourages flexible responses to change.
Agile development was popularized by the Manifesto for Agile Software Development. The values and principles espoused in this manifesto were derived from and underpin a broad range of software development frameworks, including Scrum and Kanban.
The Manifesto for Agile Software Development
Agile Software Development Values
Based on their combined experience of developing software and helping others do just that, the creators of The Manifesto for Agile Software Development proclaimed that they value:
- Individuals and interactions over processes and tools
Tools and processes are important, but it is more important to have competent people working together effectively.
2. Working software over comprehensive documentation
Good documentation is useful in helping people understand how the software is built and how to use it. However, the main point of development is to create software, not write documentation.
3. Customer collaboration over contract negotiation
A contract is important, but it is no substitute for working closely with customers to discover what they need.
4. Responding to change over following a plan
A project plan is important, but it must not be too rigid to accommodate changes in technology or the environment, stakeholder’s priorities, and people’s understanding of the problem and its solution.
Agile Software Development Principles
The Manifesto for Agile Software Development is based on twelve principles:
- Customer satisfaction by early and continuous delivery of valuable software.
- Welcome changing requirements, even in late development.
- Deliver working software frequently (weeks rather than months)
- Close, daily cooperation between business people and developers
- Projects are built around motivated individuals who should be trusted
- Face-to-face conversation is the best form of communication
- Working software is the primary measure of progress
- Sustainable development, able to maintain a constant pace
- Continuous attention to technical excellence and good design
- Simplicity, the art of maximizing the amount of work not done, is essential
- Best architectures, requirements, and designs emerge from self-organizing teams
- Regularly, the team reflects on how to become more effective, and adjusts accordingly.
Overview of Agile
- Iterative, Incremental, and Evolutionary
- Break product development work into small increments
- Iterations (sprints) are short timeboxes lasting one to four weeks
- Each iteration involves cross-functional team working in all functions: planning, analysis, coding, unit testing, and acceptance testing
- A working product is demonstrated at the end of an iteration
- Iterations minimize overall risk and allow the product to adapt to change quickly
- An iteration might not be enough to warrant a market release; might require several iterations to release a product.
2. Efficient and face-to-face communication
- Co-workers work at the same location to better establish team identity and improve communication
- Face-to-face communication reduces the time taken for communicating in between media
- Each team should have a customer representative to review progress and re-evaluate priorities.
3. Very short feedback loop and adaptation cycle
- Daily stand-up: team members report to each other their current progress and the goal of the day, along with any obstacles that others can help with.
4. Quality focus
- Specific tools are used to improve quality and enhance product development agility.
- Tools include:
- Continuous integration
- Automated unit testing
- Pair programming
- Test-driven development
- Design patterns
- Behavior-driven development
- Domain-driven design
- Code refactoring
Philosophy of Agile Software Development
Agile software development targets complex systems and product development with dynamic, non-deterministic, and non-linear characteristics. As estimates and stables plans are hard to get in the early stage, Agile development seeks to reduce the leap-of-faith that is needed before any evidence of value can be obtained.
Adaptive vs. predictive
Agile development methods lie on the adaptive side of development. One key of adaptive development is a rolling wave approach to schedule planning, which identifies milestones but leaves flexibility in the path to reach them, and also allows for the milestones themselves to change. Adaptive methods focus on adapting quickly to changing realities.
On the other hand, the predictive methods focus on analyzing and planning the future in detail and cater to known risks.
Agile vs. Waterfall
One of the main differences between Agile and Waterfall development is its approach to quality and testing.
In the Waterfall model, there is always a separate testing phase after a build phase; however, in Agile software development, testing is completed in the same iteration as programming.
Another difference between Agile and Waterfall development is the presence of iterations. In the Waterfall software development method, a project goes through several Software Development Lifecycle phases; one phase is completed in its entirety before moving on to the next phase.
On the other hand, because Agile development is done through iterations, and every testing is done in every iteration, small pieces of software can be pushed to the public and therefore have its value evaluated. Being able to create plans for progression in software every iteration allows the product to adapt to any change in the environment.
This iterative approach follows the product mindset, instead of the project mindset. This provides greater flexibility throughout the development process; whereas, on a project mindset, the requirements are predefined and locked.
Code vs. Documentation
Critics of the Agile labeled this software development method as “another reason for programmers to just code without writing good documentation”. However, proponents of the Agile Development Method stated how too much documentation isn’t a good thing, as it is usually out of sync with the actual code, while too little of documentation is also a bad thing. The proposition they placed was just enough documentation.
Experience and Adoption
Although the Agile Software Development method can be used with any programming language in practice, it was originally closely associated with Object-Oriented Programming environments such as Lisp and Java.
The early adopters of Agile methods were usually small to medium-sized teams working on unprecedented systems with requirements that were difficult to finalize and likely to change as the system was being developed.
Common Agile Software Development Pitfalls
Pitfalls while using Agile are usually termed agile anti-patterns or agile smells. Some common examples of these pitfalls are:
Lack of overall product design
The goal of the Agile software development method is to work on producing software and less on documentation. This is in contrast with the Waterfall method, where any small changes in the code should also come with revisions to the documentation. In this case, failure to pay attention to design can cause a team to proceed rapidly without any proper documentation of design, which could lead to serious rework when they attempt to scale up the system.
Adding stories to an iteration in progress
In Agile software development, stories are typically used to define requirements and an iteration is a short period of time during which the team commits to specific goals. Adding stories to an iteration in progress is detrimental to a good flow of work. These should be added to the product backlog and prioritized for a subsequent iteration or in rare cases the iteration should be canceled.
If a new story appears that requires a change of an iteration, the team must then deal with the new information, which may produce additional tasks for a story. This new information should then be prioritized against all remaining stories, as the new information may have changed the story’s original priority.
Product owner role is not properly filled
The product owner role is usually someone from the business side of things. The mistake made in Agile software development is when the Product owner comes from the Development side of the operation. In this case, the Product owner will make decisions without any real feedback from the business perspective. This could also lead to distraction as the Product owner needs to reach out to the outside team for direction.
Teams are not focused
Agile software development requires teams to meet product commitments, which means they should focus only on work for that product. However, when a member of the team has spare capacity, this member is expected to help work on other work, which ultimately reduces the focus for their committed work.
Excessive preparation/planning
People who are less familiar with Agile software development are often victim of excessive planning. The team feels obliged to have a complete understanding and specification of all stories.
The proper way is to move forward with stories that they are confident in working, and then during the iteration, continue to discover new stories to work on for subsequent iterations.
Problem-solving in the daily standup
Daily stand-up meetings should not take too much time, as its goal is to create a focused, timely meeting where all team members disseminate information. If a part of the team gets stuck on solving a certain problem, then this will be a waste of time for other teams. It is best to leave the problem solving after the daily standup, where subteams can come together and take the time to work on it.
Allowing technical debt to build-up
Focusing on continuously creating new iterations might create technical debt. The team must allow themselves time for defect remediation and refactoring. Technical debt hinders planning abilities by increasing the amount of unscheduled work as production defects distract the team from further progress.
