History of agile development
It was not until a part of evolution in opposition to traditional models of software development that many software companies relied on the model of developing software named Waterfall model, which most developers found that it was inflexible and unrealistic in the new era of rapid technological software development, which users have more desires for everything they ever imagined of. Back to the Waterfall model, suited for timing control, and on-time project delivery, but fails to adapt to changing requirements that many times defects are found in the testing phase of development that developer might have to go back to the earlier phase of development to start coding again, and of course, could lead to failure in project development. Then, many developers came up with the idea against single release of software product until the expectation of new models was initiated in the mid-1990 as a software development approach of agile development. Until now, there are many methods of agile software development, such as, Scrum, Extreme programming, Crystal clear, Adaptive software development, Feature driven development, Dynamic system development method, etc.
What is Agile development?
Agile development is a methodology to develop software in which the whole piece of software is divided into many small pieces. Each piece has its cycles, such as, gathering requirement, design, coding, and testing. Each piece of software may be called release, delivery, or iteration because the developer may iterate each piece again until it's fully complete. Every agile methodologies share the same idea that accepts changing requirements. Each methodology of agile development describes how much time it takes to complete each iteration, whether or not requirements can be changed during its iteration, and how each iteration is handled.
10 principles to apply agile development
- Getting customer involvement throughout the software development process. Customers or users are the ones who can give developers clearly-defined requirements, or can accept or deny you products. Getting customer involvement can clarify you requirement. When the requirement seems to be unrealistic, you can discuss and find the ways to change something in requirements with the acceptance of the customers that both developers and customers have the responsibility for some issues in changing requirement. Customers can track your progress and have more confidence that they can get the software they want in your delivery of product.
- Getting team member involvement. In order to complete project effectively, everybody must get involved throughout the lifecycle of the project. Everybody is considered as the owner of the product and take on responsibility of the whole product if the product is fully complete. Starting from requirements to delivery of product, everybody must understand all requirements to identify defects, communicate, and find the way to solve them, design, develop, and test together to get multiple brain power. In order to make everybody meet the same objective, agile development promotes face-to-face communication more than other ways of communication such as documentation or telephone conference. This can improve understanding and cooperating among the team members.
- Prioritizing requirements. Back to the traditional development, when programmers develop software based on the requirements, nobody knows which features is the first priority for customers. They consider everything equally important that should be developed on time within budget before delivering the product to customers. However, it comes out later that they use only 20% of the product and they want to change something to accommodate them at least for the look and feel. So, the developers have to work hard later to fix many things based on the emerging of requirements. Unfortunately, they need to change database structure that affects all work structure resulting in endless development. Agile development uses the assumption that allows changing in requirements, which developers select the highest priority task to work as the core of development.
- Gathering requirements for your vision and scope. When you start the requirement gathering, you should start with a high level, which is vision and scope, but don't go to the details of the requirements until you prioritize the requirements. From your vision and scope, you can make a plan and estimate the size of the project, and the resources needed to work on. The high level requirements should be visual format, such as story board, which show the outline scope of the project and how the work will flow in the scope, which everybody must contribute and understand basically what the customer's needs are. We use a user story board to reflect what the customer's needs for the software. You must know who the customers (position) are, what they want from this software, and why they want. For example, customers are the students(who are the customers?) that want to search for secondhand textbooks(what do they want?) in order to buy it online(why do they want?).
- Breaking up the entire project into various small mini-projects. First thing we have a high level documentation and select a task you want to complete to do by passing through the development cycle, that are requirement analysis, coding, testing, and releasing the task that later might come to this cycle again when changing requirement occurs. You don't have to wait until all parts of project is done as a traditional development, instead, releasing a small part of project when it's done is enable users to see how it looks, acknowledge how it functions, and allow them to get involved in requirement process again to change some features based on their ideas.
- Releasing each task frequently to customers. The benefit of releasing each task frequently is to get customer feedback of each task before you integrate every part of work product together. This comes to the question that how frequent it should be. Well, the answer is it depends. Let's consider the case of developing Enterprise Resource Planning System of a large organization, which is divided into many functional modules, each modules include both front office and back office that make entire project take more than 2 year to complete. So it is impossible to deliver each task to customers in 30 days. However, in case of developing web blog of a company, which is the same for all users with only single click that provides easy understanding among users and no need for training. 30 days might be considered too many days to deliver.
- Completing each mini-project before selecting the next. Developers have to make sure that they have completed everything without something missing, and then get the mini-project verified by the users before you consider your task is done. If you have multiple tasks separately by multiple developers, make sure that every task is fully-developed and can integrate together without some problem arising later.
- Applying 80/20 rule. This rule means that use 20% of your effort to build 80% of software product. You have to develop the application that the customers really need, not the application that has a lot of features. Microsoft research shows that there are only 8% of the features of Microsoft Vista product which have been used by the users, but Microsoft still provides a lot of features more than the customer's need because Microsoft has a lot of budget to invest in developing software in response to market competition. Come back to 80/20 rule, when you develop software under the timeframe and budget, you do not have to use your effort to develop all 100% of features, just spend your effort to the main features first, and develop the rest until it's good enough.
- Testing each release of mini-project throughout the development process. With agile development, testing plays an important role in getting releases to meet software requirements. Developers are responsible for writing their unit tests to verify if their program is working correctly. But testing in agile software development should depend not only on developers, but also professional testers could get involved in testing software to make sure that its release meets the requirement's specification since the requirements of agile development are flexible resulting in ambiguous among developers, and can not make sure that everybody understands them well. So, testing by both developers and testers play an important role in improving standard of each software release.
- Encouraging and promoting communication and cooperation among the team members, users and stakeholders. Requirements in agile development do not have to be in-depth, but allow changing that is always happened throughout the development process, so the ease of understanding depends upon how successful the communication and cooperation are in order to make everybody keep up with a rapid changing in requirements that everybody must pay attention to the same work, which get everybody on the same ship moving toward to the same direction, and finally reaching the same destination together.
There are many agile methods that share the same idea that divides the project into multi deliveries of software product, but different details in each delivery. I would like to introduce some agile methods that have been popular so far.
DSDM or Dynamic systems development method
DSDM divides the entire project into 3 main phases.
The Pre Project phase
This phase takes place before a project starts after a project is defined. In this phase, the project manager makes sure that the project can be funded by stakeholders or customers and everybody in the team is ready to develop the project before making decision to start the project.
The Project Life Cycle phase
This phase is subdivided into 5 stages that developer must go through these stages to develop each incremental release. These stages are the feasibility study, business study, functional model iteration, design & build iteration, and implementation iteration. The last three stages are developed in incremental iterations.
- Feasibility study is to estimate the project feasibility in case the resources and time are fixed. They might find some alternatives to complete this project in order to deliver project on time within budget.
- Business study is getting users and developer involvement to analyze if this project is necessary for business. The developers can prioritize the features which they will develop depending on what users really need instead of developing rich features.
- Function model iteration is to create prototype that is a structured way to show idea and easy to make everybody understand. It is subdivided into 4 stages.
- Identify functional prototype is to use business study to identify functionalities of prototype, and how long to complete prototype.
- Everybody makes an agreement to create prototype on time defined.
- Create functional prototype
- Review functional prototype is to identify defects and review if the prototype can perform functions based on business study.
- Identify design prototype is to use prototype to identify features of this project, and how long to complete project.
- Everybody makes an agreement to create prototype on time defined.
- Create design prototype is to develop project.
- Review design prototype is to test system if it can work well or not based on requirements, if not, will go back to the iteration again.
- User approval and guidelines is to document the project to get user agreement of the project
- Train users, create user manual and train them.
- Implement, set up the project in the user environment and test the project again.
- Reviewing business aspects is to review if the project meets the requirements, and define future requirements. If the project is not fully complete, it can go back to the earlier stages to develop.
The Post Project phase
After the project is released, it is still in post project phase to monitor if this project works completely and effectively. If not, it can go back to the iteration again to maintain the project. The user support and maintenance is being assigned to company who develop this project too.
XP or Extreme Programming
XP divides the entire project into many small iterations, which each iteration looks like the traditional waterfall model, which consists of requirement analysis, design, code, test, and deployment. The XP team releases each iteration every week to three week as it is defined, so they have to work through these activities within one week.
The XP concept emphasizes the team to work in the same room, the same environment to have face-to-face communication, which can promote more understanding and cooperating among team members. They are encouraged to get feedback from team members and customers frequently, so when the issues or problems are raised, or customers require changing requirements, they can use multiple brain power to help eliminate these problems on time.
- Planning/Requirement Analysis
- Design and code
The XP team and customers get involved in planning together. Customers have to know their business process, and their direction to explain to developer, so the developer can suggest how application should look and estimate the project size. Developer creates data flow diagram, or use case to present to customers, so that customers can see the idea. Requirement analysis may take more time in the earlier stages of the project, so that the developer can communicate with the customers about the entire project scope and requirements. And the rest of development process, customers provide feedback and additional requirements to the developer.
Developers design and code their project in the incremental step, which means that each one develops a small piece of software in order to integrate together. They use version control to know how many times the project is released. When they meet some problems, everybody get involved and come up with their idea to solve the problems. So, there is no one man show in the art of developing software.
With XP method, a lot of bugs and defects might be identified during iterations. We can not prevent bugs; however, bugs are encouraged to be raised during iterations. Developers, testers, and customers have their contribution in testing software. Developers test their own software that it could function well. Testers not only test the software to qualify the requirements, but also make sure that the software has high performance to run in the customer's environment. Customers test software to make sure that it meets their desires.
The XP team releases software to the environment where there are any users or tester to test software. The XP team also provides maintenance and support to the software as the defects might be found later causing this software to go back to the iteration again.
Definition of Scrum terms
Scrum team consists of team member from five to nine working together through the phase of requirement analysis, design, code, and test. Team members can come from any areas of knowledge to share their ideas in order to move toward the project's goal.
Scrum master is the project manager.
Product owner is someone who funds the product, such as stakeholders, users, or customers.
Product backlog is the entire project document that provides the scope or framework for whole project and divides into small features and prioritizes them. The product backlog is written by the product owner with close suggestion from scrum master.
Sprint is the iteration that scrum team selects the work they want to complete depending on the product priority to the sprint.
After project starts, scrum master divides the whole project into small parts that are prioritized and defined scope of each part, and group together as a product backlog. Each part is called sprint that is scheduling from two to four weeks to complete each sprint. Then scrum master arranges the meeting for scrum team to make agreement that what tasks scrum team wants to complete. During each sprint, requirements are not allowed to be changed until scrum team releases the sprint. After each sprint, product owner will see and test again if it meets the requirements or desires, if not, the product owner will change some features, or requirements and send it to product backlog again.
Before I chose agile development as a topic for my research paper, I had heard a lot about it, but I did not know what it was. Back to when I studied undergraduate program, the model that I studied was the Waterfall model, which I realized that every software company follow it. After I first read definition of agile development, I accepted that there were a lot of changing requirements in this software era as I had experienced before. I had so much curiosity about it, which inspired me to choose agile development as a topic for my research paper. As I have done research in the area of agile development, I understand that when changing requirement is unavoidable, agile methodologies are best suited. No matter what methodologies in agile development I want to use, they emphasize cooperation, collaboration, and communication among the team members, stakeholders, and customers the most. As I have seen that all methodologies divide the entire project into many mini projects because they want to get everybody involved at every point of development as much as possible, rather than getting requirement at one time, and developing the whole piece that is almost impossible to go back to the earlier point again.
After I had studied 3 methods of agile(DSDM, XP, and Scrum) , I compared the differences between these three methods as follows.
Comparing DSDM, XP, and Scrum
Selecting a method for developing software depends upon the characteristics of each project as the team should know the characteristics of project they would develop that they can choose the appropriate method to apply as each one has different aspects.
Characteristics of project and the method used
Time. If the project requires fixed time to develop it, the method that is best suited is DSDM because DSDM defines fixed time to handle project and control risk in each iteration.
Quality. If the project needs high quality, we would select Extreme programming because XP defines engineering practice to improve quality of the project, such as Test driven development, refactoring, or Pair programming.
Change. If the team is afraid of handling a change in each iteration of development, we would choose Scrum in which changing requirement is not allowed in each sprint.
Size. If a project tends to grow bigger in response to the needs of customers, we would choose DSDM as a development method as DSDM provides better framework for the scalable project.
Moreover, in order to manage project more successfully to fit in the characteristics of the project, we can combine each method together as each one has the ability to mix and match together. For example, we can combine XP and Scrum together as XP focuses mainly on the engineering practice and Scrum focuses mainly on the overall process of management. We can use Scrum process as a framework for the project to improve ROI, but within each sprint, we can adopt XP practice such as Test driven development, or pair programming to use as a development technique to improve quality of the project.
- The art of agile development by Chromatic and Jim Shore.