EVALUATION OF AGILE SOFTWARE DEVELOPMENT METHODOLOGIES AND ITS APPLICATIONS.
A Thesis
Presented to the
Faculty of
California State Polytechnic University, Pomona
In Partial Fulfillment
Of the Requirements for the Degree
Master of Science
In
Computer Science
By
Mayuresh Sudhir Nazare
2019 SIGNATURE PAGE
THESIS: EVALUATION OF AGILE SOFTWARE DEVELOPMENT METHODOLOGIES AND ITS APPLICATIONS.
AUTHOR: Mayuresh Sudhir Nazare
DATE SUBMITTED: Spring 2019
Department of Computer Science
Dr. Gilbert S. Young Thesis Committee Chair Computer Science
Dr. Yu Sun Computer Science
Dr. Abdelfattah Amamra Computer Science
ii
ACKNOWLEDGEMENTS
I would first like to thank my thesis advisor Dr. Gilbert S Young. He consistently allowed this paper to be my own work but steered me in the right the direction whenever he thought
I needed it. I also thank Dr. Yu Sun and Dr. Abdelfattah Amamra for their feedback and willingness to review my work.
I also would like to thank my AAI and BABA (Shraddha S Nazare and Dr Sudhir V
Nazare) for supporting me to pursue masters. A Big thank to my beloved sister
Shwetambara S Nazare who has been my inspiration in my life and supporting me throughout my academic journey. She stood my inspiration and moral support for the thesis.
Finally, I want to acknowledge Dr. Salomon Oldak and Rebecca Rivas from Graduate
Studies for Supporting and Guiding me.
iii
ABSTRACT
The percentage of agile practices is booming. Most of the old software development companies are switching to agile development methods and Startups are preferring agile methodologies from scratch. The purpose of this thesis is to study different agile methodologies (e.g. Scrum, Extreme Programming etc.) in software development and find the best one.
Each of the agile methodologies have its own planning, practices, pros and cons.
The goal of this thesis is to gain knowledge about all the facts and understand agile software development environment. We will also see the impact of adopting agile methodology when migrating from legacy methods.
We will be analyzing most popular agile methods that will be explained and compared with each other in terms of quality and impact on software development.
This thesis will present the various reasons and benefits of agile practices and demonstrates the top software development methods which are utilized by software companies.
iv
TABLE OF CONTENTS
SIGNATURE PAGE ...... ii ACKNOWLEDGEMENTS ...... iii ABSTRACT ...... iv LIST OF FIGURES ...... vii CHAPTER 1:INTRODUCTION ...... 1 CHAPTER 2:ITERATIVE SOFTWARE DEVELOPMENT ...... 3 2.1 Iteration Model ...... 3 2.2 Applications of Iterative Model ...... 5 2.3 The advantages of the Iterative and Incremental SDLC Model ...... 6 2.4 The disadvantages of the Iterative and Incremental SDLC Model ...... 7 CHAPTER 3:AGILE MANIFESTO...... 8 3.1 The postulates ...... 8 3.2 The Principles of Agile Manifesto ...... 10 CHAPTER 4:SOFTWARE ENGINEERING - AGILE WAY ...... 15 4.1 Architecture ...... 16 4.2 Design ...... 17 4.3 Testing...... 18 4.4 Quality Assurance ...... 19 4.5 Verification and Validation ...... 20 CHAPTER 5:DIFFERENT AGILE METHODOLOGIES ...... 21 5.1 Scrum ...... 21 5.2 Crystal methods ...... 25 5.2.1 The family is divided into different color ...... 27 5.3 Feature driven development ...... 28 5.4 Extreme programming ...... 30 CHAPTER 6:AGILE METHODOLOGIES COMPARISON ...... 34 6.1 Comparison based on flexibility ...... 36 6.2 Comparison based on risk ...... 36 6.3 Comparison based on usage ...... 37
v
CHAPTER 7:IMPLEMENTATION OF SCRUM ...... 38 7.1 Define scrum team ...... 38 7.2 Defining sprint length ...... 39 7.3 Appoint a scrum master ...... 39 7.4 Appoint a product owner ...... 39 7.5 Create the Initial Product Backlog ...... 40 7.6 Planning and starting your first sprint ...... 40 7.7Closing the current and starting the new/next sprint ...... 40 CHAPTER 8:AGILE SURVEYS ...... 42 8.1 Reasons for adopting agile ...... 43 8.2 The respondents and participants of survey demographics ...... 43 8.3 Statistics of companies who have adopted agile ...... 43 8.4 Usage of agile methods for year 2018 ...... 44 8.5 Agile Initiatives ...... 46 8.6 Challenges Experienced Adopting & Scaling Agile ...... 46 8.7 Use of agile tools ...... 47 CONCLUSION ...... 48 REFERENCES ...... 50
vi
LIST OF FIGURES
Figure 1: Iterative model of software development...... 4
Figure 2: Basic Scrum Model ...... 22
Figure 3: Crystal Methods ...... 26
Figure 4: Life Cycle of Feature Driven Development ...... 29
Figure 5: Extreme Programming Planning/Feedback Loops ...... 32
Figure 6: Comparison of various Agile Methods ...... 34
Figure 7:Comparsion of Advantages and Disadvantages ...... 35
Figure 8: Usage of various agile methodologies ...... 37
Figure 9:Reasons why agile methodology is adopted...... 42
Figure 10:Demographics of survey participants ...... 43
Figure 11: Statistics of how many are adopting agile ...... 44
Figure 12: Usage of agile methods for year 2018 ...... 44
Figure 13: Top agile technics ...... 45
Figure 14: Success Measurement using agile ...... 46
Figure 15:Challenges Experienced Adopting & Scaling Agile ...... 47
Figure 16:Popular agile tools of industry...... 47
vii
CHAPTER 1
INTRODUCTION
With the continuous increasing demand of software development. The utilization of software products has increased significantly. The dependency of people on software technology is making our life easier and flexible. Resulting significant and continuous growth in startups and software industries. With this rapid growth came new problems and different challenges form previous models. Problems such as faulty documentation, Continuous change request in middle of development and lack of proper information resources which eventually impacts the software quality.
The output of this thesis is to research and understand various agile methodologies and find out the most efficient (based on scenarios) agile practices by comparing, analyzing and evaluating. The focus of agile development is on creating working software with very less time to market. Contrasting with the traditional software development methodologies which mostly focuses on creating and updating documentation in agile methodologies the documentation is not a big issue.
Agile development pushes and relies on customer involvement in software development process. This thesis will present all important aspects of agile methods and analyses important agile practices which may be effective to select the suitable agile methods for software developers and their team.
Following the chapter one the chapter two of thesis will focus on the iterative software development. The chapter will explain iterative software development which foundation of agile software development as the iterations performed in agile software development are derived from iterative software development by following small
1 development cycles continuously.
The next chapters of thesis are important as it covers all the key components of agile methodology and establishes the premise of agile software engineering. Agile methodology is tree of various methods. Each leaf has its own distinct features and practices and flexibilities most important agile methodologies are explained with their practices in thesis chapter. Also, the chapter contains comparison, pros and cons of important agile methods.
The next chapter will focus on the annual survey which is conducted in year
2018 as 12th annual state of agile report by VersionOne. The chapter will provide all the hands on and practical information on agile development. It contains information about why and how the team adopts agile what are its benefits, which are the most popular agile methodologies used by organization teams. The importance of this chapter will be the reasons of failure of agile software development. The information will help evaluating the agile practices and their application to software.
The final chapter will provide guidelines for implementation of scrum. Scrum is most widely used agile method in industry and the growth is ballooning over the time.
We will get in deep understanding scrum and scrum team, Role of product owners, team development. Further it explains the scrum relics in detail.
2
CHAPTER 2
ITERATIVE SOFTWARE DEVELOPMENT
In iterative software development model, the iteration process starts with simple implementation of the software requirements and iteration by iteration it enhances the evolving version until the completed system is implemented and gets ready to be deployed.
The iteration lifecycle does not begin directly with full specification needs. Rather the development begins by specifying and implementing small part of software and which is reviewed later to identify the remaining or further requirements.
Repetition of this process is done until it produces the newer version of software at end of each iteration of model.
2.1 Iteration Model.
The process of iterations starts with the simple implementation of small part or subset of the software requirements and iteratively moves forward with evolving versions until the full system is been implemented. In each iteration the design is updated and modified, and new functional capabilities are added. It follows the basic idea of developing the system through the repeated cycles and in small sizes.
On the other hand, the obsolete waterfall models the software if developed in phases where each phase follows each other. The problem with such model is that it is quite hard to go back when needed. The planning phase in waterfall model is first phase where all the planning is done before implementation. The testing is done when the implementation is done. This is quite error prone as the error might be found in late in the project. As it prolongs the delivery time as rescheduling needs to be done in order to correct errors made.
3
However, in the iteration development the software is developed sequentially over several iterations, where each iteration is treated as mini project.
Figure 1: Iterative model of software development (agilemodeling.com). The outcome of this iteration is iteration release, integrated, stable and partially completed system. This release is released internally not externally. The last iteration is released in market as final product. K. Schwaber (2004).
The goal of each outcome is to have workable product which will be delivered to customer. But, the outcome of each iteration is called demo presented to customer.
This gives customer a good idea about what is happening in development and where the things are heading to make changes accordingly. As it also makes easy for customer to understand previous demos and what changes have happened in new one. If the changes are requested in current phase the customer can request changes in next phase which can be understood and checked for its scope before approving, it for actual implementation.
4
A planned schedule plays an important role before every iteration. It can be done by limiting time or boxing time in every iteration deadline is determined. The most crucial thing which is time needs to be taken seriously as it is important to track the progress of development. Sometimes re estimation of task is done if time does not permit to execute the entire task, sometimes some tasks are removed.
2.2 Applications of Iterative Model.
The application of iterative model is mostly permitted in following scenarios.
1. The system requirements are clearly defined and well understood.
2. Major requirements are clearly defined or some functionalities that can be evolved
with time.
3. Time to market the solution.
4. A new technology is being used and is in learning phase by development
teamworking on project.
5. Some high-risk features and goals which may change in future.
The advantage of this model is that there is a working model of the system at a very early stage of development, which makes it easier to find functional or design flaws.
Finding issues at an early stage of development enables to take corrective measures in a limited budget, David F et al (2010).
The disadvantage with this SDLC model is that it is applicable only to large and bulky software development projects. This is because it is hard to break a small software system into further small serviceable increments/modules.
5
2.3 The advantages of the Iterative and Incremental SDLC Model are as follows:
• Some working functionality can be developed quickly and early in the life cycle.
• Results are obtained early and periodically.
• Parallel development can be planned.
• Progress can be measured.
• Less costly to change the scope/requirements.
• Testing and debugging during smaller iteration is easy.
• Risks are identified and resolved during iteration; and each iteration is an easily
managed milestone.
• Easier to manage risk - High risk part is done first.
• With every increment, operational product is delivered.
• Issues, challenges and risks identified from each increment can be utilized/applied
to the next increment.
• Risk analysis is better.
• It supports changing requirements.
• Initial Operating time is less.
• Better suited for large and mission-critical projects.
• During the life cycle, software is produced early which facilitates customer
evaluation and feedback, David F. et al (2010).
6
2.4 The disadvantages of the Iterative and Incremental SDLC Model are as follows
• More resources may be required.
• Although cost of change is lesser, but it is not very suitable for changing
requirements.
• More management attention is required.
• System architecture or design issues may arise because not all requirements are
gathered in the beginning of the entire life cycle.
• Defining increments may require definition of the complete system.
• Not suitable for smaller projects.
• Management complexity is more.
• End of project may not be known which a risk is.
• Highly skilled resources are required for risk analysis.
• Projects progress is highly dependent upon the risk analysis phase, David F.et al
(2010).
7
CHAPTER 3
AGILE MANIFESTO
In February 2001, academics and experts of the software industry gathered in Utah,
United States, in order to discuss values and principles that would facilitate a quicker software development and answers to the changes that might arise during the project. The idea was to offer an alternative to the processes of traditional development. As a result of this meeting, the Agile Alliance was formed. This is a non-profit organization dedicated to promoting the concepts related to the agile development of software and helping organizations to adopt said concepts. The result of this meeting was a document known as the Agile Manifesto. The Agile Manifesto includes four postulates and a series of associated principles, M. Huo. et al (2004).
3.1 The postulates are:
1) Value the individual and the development team's interactions above the process and the tools. Three premises sustain this principle:
a) team members are the main factor of a project's success;
b) it's more important to set up a team than an environment.
c) it's better to put a team together and to let it configure the environment based on
its own needs.
2) Value the software development that works over an exhaustive documentation.
The principle is based on the premise that documents can neither replace nor offer the added value that is achieved with direct communication between people through the
8 interaction with prototypes. The use of documentation that generates works and does not add a direct value to the product must be reduced to the essential minimum.
3) Value the collaboration with the customer over the contractual negotiation.
In agile development, the customer is integrated and collaborates with the work team, just like any other member. The contract itself does not add value to the product; it is just a formalism that establishes lines of responsibility among parties.
4) Value the answer to change over the follow up of a plan.
The speedy and constant evolution must be inherent factors to the development process. The ability to react to change over the ability to monitor and assure preestablished plans.
9
3.2 The Principles of Agile Manifesto.
The agile philosophy is based on 12 important principles as which basically covers the most important guidelines of agile or we can say it is the skeleton of agile, J Shore et al (2008).
1. Our highest priority is to satisfy customer through early and continuous
delivery
As a project manager using an agile methodology, you need to make sure that you
deliver a solution that solves user’s problems. Ensure early and continuous delivery as
well. You can achieve that by minimizing the time spent on each phase of the project.
Make the process more efficient and cut down on unnecessary activities to satisfy your
clients.
2. Welcome-changing requirements even late in development. agile processes
harnesses change for customer competitive advantage
The biggest advantage of using agile project management methodology is that it offers
you the flexibility to change. Unlike other rigid project management methodologies,
agile allows you to make changes even late in the development process. All you must
do is reduce the time between conception and implementation of the change. This
results in better customer satisfaction and customer competitive advantage.
10
3. Deliver working software frequently (weekly or monthly) with focus on
shorter timescale
While other project methodologies are heavily dependent on documentation and 100% completion, agile methodology takes a different route. Agile project management methodology reduces the documentation and planning to a minimum and put more emphasis on development. Due to this, most projects that use agile methodology completes before the deadline.
4. Business people and developers should work together daily
One of the most important principles on this list is business people should closely work in collaboration with developers or product engineers to achieve success. Your business and technical team should be present at the same place to make this possible. Even if they are not, you can use collaboration and task management software to communicate with them.
5. Build projects around motivated individual. provide them the environment
and support they need and trust them to get the job done
In agile project management, teams are self-reliant and self-directed. More importantly, there is no micromanagement. The important part here is that you should hire the right people to work for you and provide them with everything they need to accomplish project goals before the deadline and inside the budget. Project managers must trust their team to deliver results.
11
6. The most efficient way to convey information to your development team is face
to face conversation
Despite the advancement in technology and emergence of digital communication and collaboration tools, the face-to-face conversation still holds its own. That is where working under the same roof comes into play. In agile project management methodology, we need to get quick answers to questions and there is no better way to achieve that feat than face-to-face conversation.
7. Working software is a primary measure of success
For agile project teams, there is nothing more important than a working prototype.
Irrespective of how many bugs you have fixed or how many hours you have put in the development of a product, the only thing that count is a working product. If it is not working properly, then all the factors become irrelevant.
8. Agile process promotes sustainable development. sponsors, developers and
users should maintain a constant pace
Agile project management methodology resolves this issue as well. In agile project management, work is done is short productive bursts to ensure better productivity and outcomes. Setting the right pace is crucial for success in agile project management. If you move at the same pace as sponsors, users, developers, etc. you can easily drive your project to success.
12
9. Continuous attention to technical excellence and good design boosts agility
Two of the most important factors that play their part in success is technical expertise and good design. When using agile project management methodology, you do not have to spend time in refining your code. It will get better automatically with every iteration, so you do not have to worry about it. The use of scrum tools can further enhance the speed of the process so you can achieve more in less time without compromising on the quality of the final product.
10. Simplicity: - The art of maximizing the amount of work not done but is
essential
When it comes to managing projects through agile methodology, you should keep things simple and reduce the time required to go from comprehension to completion.
Track all your team members and the time they spend working with the help of a project management software. This will ensure timely completion of critical tasks.
11. The best requirements, architecture, and design emerge from self-organizing
teams.
As mentioned above, agile teams are self-directed. You will not have to tell them what they must do. Instead, they will find a way themselves and remove any hurdle that comes in the way. The project manager will only interfere when there are some warning signs or situation gets out of hand. In normal circumstances, everything goes smoothly, and all credit goes to well-organized teams.
13
12. At regular interval, team reflects on how to become more effective and tweak
behavior accordingly.
In today’s dynamic agile project environments, it is important that we keep on looking for flaws and improve. More importantly, adapting to a certain situation is crucial for success. Project managers who are still using older methodologies will struggle in today’s rapidly evolving project environments. They will have to keep pace with emerging trends and adjust according to the situation in order to achieve project goals.
14
CHAPTER 4
SOFTWARE ENGINEERING - AGILE WAY.
Agile development is a philosophy. It’s a way of thinking about software development. The canonical description of this way of thinking is the Agile Manifesto, a collection of 4 values and 12 principles.
To “be agile,” you need to put the agile values and principles into practice. The basic premise of agile software development is to match iterative developing environment, collaborations with customers and its ability to adapt to build and sustain with new software products. Through adaptable development process which can be quantified with systematic and discipline approach, agile software development is perfect as it is just enough with perfect size and JIT(Just-in-time) method to get task done, J Shore et al (2008).
There are significant differences in agile and waterfall model. Limited time iteration and Advance software development that includes good planning which are adaptable to continuous changes are some of the features of agile engineering. It advances the new delivery system which incorporates delivering a developed software at small portion at a time. Comfortable and flexible approach towards changes is important part of agile software engineering. There is no exact definition of agile methodologies, most of agile methods have almost same foundation, with varied practices. Some specific goals are been shared among different methods, J Shore et al (2008).
15
4.1 Architecture.
In the software engineering body of knowledge, software architecture is a description of software subsystems and their relationships. It is also a process of specifying, identifying, evaluating, and selecting an architectural style or pattern. In traditional methods, software architecture descriptions are major components, documenting the description, components, requirements, concepts, resources, and rationale. The skillful application of numerous description languages, analysis methods, quality attributes, frameworks, reference models, and domain analysis tools is regarded as a software architecture discipline. Agile methods have a form of software architecture called system metaphors, which are narratives that customers, managers, and programmers can use to talk about how the software product works. There is a process for developing metaphors.
One of the goals of the initial iteration is to have a functional skeleton of the system.
Customers must choose a set of user stories that will force the developers to create the whole architecture. After user stories are selected from the scope of the initial release defined by customers, customers and developers combine them into a simple narrative about how the whole system works. System metaphors serve the purpose of software architecture from the software engineering body of knowledge. The release planning methodology from Extreme Programming defines the process for managing software architecture. System metaphors may be recorded in a document that is placed where everyone can see it or stored in workflow tools. System metaphors are simple and effective tools for communicating among teams. Within agile methods, system metaphors are right- sized, just-enough, and just-in-time software architecture for maximizing business value.
16
4.2 Design.
In the software engineering body of knowledge, software design is defined as the components, interfaces, and characteristics. It is also a process of defining software structure, analyzing quality, applying design notations, and utilizing software design methods. In traditional methods, software design descriptions are major components, documenting the description, algorithms, data structures, inputs and outputs, relationships, data fl ow, traceability, rationale, and reuse options. The skillful application of numerous design styles, patterns, tools, notations, and methods is regarded as a software design discipline. Agile methods have a form of software design called simple design, which is a code design with the fewest number of classes and methods that satisfy all user stories and pass all tests. The process for creating simple designs starts with a unit test to evaluate software methods, J. Garbajosa et al (2018).
After designing and implementing just enough code to get tests running, the process is repeated; that is, create some code and then remove whatever you don’t need. The code must communicate everything you intend, lack redundancy, and have a small number of classes. Additionally, it must require only a small initial investment and must result in working software. Simplicity serves the purpose of software design from the software engineering body of knowledge. Simplicity practices from Extreme Programming define the process for software design. In traditional methods, software design is a document, but within agile methods it is part of coding. Software design considerations may also be documented directly within source code comments where software maintainers are most likely to look. Within agile methods, simplicity is right-sized, just-enough, and just-in-time software design for maximizing business value.
17
4.3 Testing.
Testing In the software engineering body of knowledge, software testing is an activity performed to evaluate software quality. It is also a process of developing test plans, designs, cases, procedures, scripts, and reports. In traditional methods, software test plans are major components that document the test levels, conditions, progression, data, procedures, coverage, schedules, and environment. The skillful application of numerous test goals, objectives, strategies, types, methods, techniques, measures, tools, and levels of effectiveness is regarded as a software testing discipline. Agile methods have practices for testing, such as test-driven development and continuous integration, which are processes of developing unit tests before coding and integrating all changes into the system baseline to validate them using automated frameworks. Other practices support the process of verification and validation. Customer collaboration is used to capture user stories, which customers verify, J. Garbajosa et al (2018).
As a type of peer review, developers work in teams and software is continuously integrated using hourly or daily operational builds. Adaptable processes are used to get valuable software into customers’ hands in 14- to 30-day iterations. Agile methods serve as means of in-process verification and validation. Test-driven development and continuous integration serve the purpose of software testing from the software engineering body of knowledge. However, customer collaboration, pair programming, and adaptable processes form a verification and validation life cycle. Defects are prevented as user stories are captured, code is produced and tested, and working software is created in smaller 14- to 30-day iterations. Within agile methods, test-driven development and continuous
18 integration are right-sized, just-enough, and just-in-time testing for maximizing business value.
4.4 Quality Assurance.
Agile methods have flexible and adaptable counterparts to their industrial-era antecedents. Like traditional methods, quality assurance in agile methods ensures that release and iteration plans, user stories, acceptance criteria, and development tasks are produced. It enforces coding standards, metaphors, test practices, and customer satisfaction. Quality assurance also ensures that workflow tools and environments are used properly to support release planning, collaboration, and development, J. Garbajosa et al
(2018).
Finally, it ensures that continuous integration is performed using version control, configuration management, and automated builds. Agile methods are accused of lacking quality assurance discipline. In traditional methods, quality assurance is an organization, plan, and process. In comparison, agile methods employ rich, high-context communications and individual interactions to ensure that users are adhering to practices.
Furthermore, agile methods emphasize training and certification. Several built-in roles ensure that teams are following agile practices, including certified trainers, coaches, Scrum masters, and product owners. Agile methods have right-sized, just-enough, and just-in-time quality assurance for maximizing business value.
19
4.5 Verification and Validation.
Agile methods have flexible and adaptable counterparts to their industrial-era antecedents. Verification and validation is integrated throughout the software life cycle in agile methods. This is true from both a technical (verification) and customer (validation) point of view. While verification is concerned with the correctness of the interim work products, validation is concerned with the final product.
Teams create test cases, simple designs, and code, and then verify what they’ve built using continuous integration. After customers create user stories, they use acceptance tests to validate what has been built in 14- to 30-day iterations. Agile methods are accused of lacking verification and validation discipline. In traditional methods, verification and validation is an organization, plan, and process. Developers perform static and dynamic verification of work products on an hourly and daily basis in agile methods. Customers perform acceptance testing to validate the final work products every 14 to 30 days. Rich, high-context communications enable integrated verification and validation. That has not been present in traditional methods. Thus, agile methods have right-sized, just-enough, and just-in-time verification and validation for maximizing business value, J. Garbajosa et al
(2018).
20
CHAPTER 5
DIFFERENT AGILE METHODOLOGIES
5.1 SCRUM
Jeff Sutherland created a method called scrum back in 1993. Together with Ken
Schwaber, Jeff Sutherland created a formal description of Scrum in 1995.Scrum is most used agile method. [1] Following SDLC was not as effective so [2] there was need of developing scrum to achieve project success were two reasons for developing scrum. Thus, scrum was developed in order to real world projects to work properly and become successful. The scrum was developed keeping one goal on priority and that goal was project success.
Entering this new product development game, Scrum have included the built-in stability, Self-organizing teams, subtle control, overlapping phases, organizational learning and multi-learning. This was already an answer to Japanese dilemma. We can understand the values of agile development, mainly teamwork, iterative development and adaptability.
Initially scrum was based on three broad phases 1) pre-sprint Planning 2) sprint 3) Post sprint-meeting.
Later sprint was divided in five phases namely 1) Sprint planning meeting 2) sprint
3) daily standups meeting 4) sprint review meeting 5) sprint retrospective meeting. The key idea and focus are daily standups and retrospectives, which often results in rich interpersonal communication and process improvement. Today the most used, and most popular agile methodology is scrum more than 50% of the developers around the world prefers scrum. Developers also includes Scrum with Extreme programming practices which includes user planning and user stories requirements.
21
The premise of scrum is to have two meetings at start of iterations/sprint. Where in the first meeting, the employees ask stake holders assign, reprioritize and refine the product backlog and release backlog. The next goal is also chosen during this meet. The next step is when the scrum team and the product owner meet, and the objective of the meeting is determined on how to achieve the request and make the iteration backlog of task to fulfill goals. New planning cycle might take place in terms of failure of estimated effort. These tasks are performed in 30 iterations which is known as sprint.
Figure 2: Basic Scrum Model (visual-paradigm.com/scrum/)
22
Important duties of scrum master include the team does not get interrupted by the customer with external work request. If such happens then he or she needs to make sure to remove them and deals with all the political and external management issues. The scrum master works also to make sure that the scrum is applied and provides resources deals with static blocks and makes decisions as requested. If someone in team is under performing it is duty of scrum master to make sure the team performs well, and work is done and delivered in time and fix such issues.
Of this such blocks are reported to scrum master at scrum meeting and needed decision are made by scrum master accordingly. The problems are ideally removed before second meeting. Only the scrum team can talk during the meeting and others need to listen but are not allowed to talk during the meeting. Adaptive planning which is client based is maintained during all the iterations Small presentation is given to stake holders at the end of every iteration where the product is made running. The demo is not presented if the product is not working.
Scrum creates lightweight and dynamic environment where changes are made continuously. Different variables are considered before planning and releases if new requirement occurs then the changes are made in planning as the customer requirements change continuously most of the important things are considered during the beginning of the project for example the time frame resources and back up. Each prompting includes 8 members, but multiple team may build a project and form the increment. Both small projects and large projects with hundreds of programmer’s scrums can be used. The works in common project room where they are arranged based on their daily standup meetings.
23
There is no strict obligation work in the same room if possible, the team can work in different room, but the communication should be proper as it is essential part of an agile practices.
Most important phases of scrum life cycles are pre game, development and post- game release. The pregame includes two sub phases. Which is planning and architecture. expectations and visions are set in planning phase the initial backlog product backlog which contains all the prioritized requirements is also made in planning phase Moreover in planning phase the vision an estimated budget is set.
The high-level design of the system is planned in architecture phase. The initial plans for the content of the release are done in architecture phase and the implementation of the system is ready for these in the series of 30-day Iterations the development phase.
Usually one process consist with around 3 to 8 sprints before the system is ready for release both scrum and Sprint planning meeting are held in all iterations.
The termination of the release takes place in postgame phase the product backlog list is totally free from the requirements and the product is almost ready for these releases.
This phase belongs to marketing sales and training.
24
5.2 CRYSTAL METHODS.
Crystal Methods is an object-oriented development method created by Alistair
Cockburn at IBM in 1991. Crystal Methods was created by interviewing real-world software practitioners, rather than following any one of numerous textbooks on object- oriented methods. The interviews uncovered ideas important to the success of software development such as good communication, high morale, and developer access to end users.
Projects that followed these practices were successful often, while those that didn’t invariably failed.
Crystal Methods are a family of software development methodologies developed by Alistair Cockburn from his study and interviews of teams. The methods are color-coded to signify the risk to human life. For example, projects that may involve risk to human life will use Crystal Sapphire while projects that do not have such risks will use Crystal Clear.
Crystal focuses on six primary aspects: people, interaction, community, communication, skills, and talents. Process is considered secondary. There are also seven common properties in Crystal that indicate higher possibility of success and they include frequent delivery, reflective improvement, osmotic communication, and easy access to expert users.
The methods are very flexible and avoid rigid processes because of its human- powered or people-centric focus. Alistair Cockburn is also one of the original signatories of the Agile Manifesto. Crystal Methods consider people as the most important, so processes should be modeled to meet the requirements of the team. It is adaptive, without a set of prescribed tools and techniques. It is also lightweight, without too much documentation, management or reporting. The weight of the methodology is determined
25 by the project environment and team size. For example, Crystal Clear is for short-term projects by a team of 6 developers working out of a single workspace.
The Crystal family of methodologies use different colors to denote the “weight” of which methodology to use. If a project were a small one a methodology such as Crystal
Clear, Crystal Orange or Crystal Yellow may be used or if the project was a mission-critical one where human life could be endangered then the methods Crystal Diamond or Crystal
Sapphire would be used, Larman et al (2004).
Figure 3: Crystal Methods (agilemodeling.com).
26
5.2.1 The family is divided into different colors.
Some examples:
• Crystal Clear
• Crystal Yellow
• Crystal Orange
• Crystal Orange Web
• Crystal Red
• Crystal Maroon
• Crystal Diamond
• Crystal Sapphire
There are five “colors” which represent the five families of Crystal mythologies, which are to be adopted based on the size of the project (i.e., the number of people involved on a project
• Clear–up to 6 people
• Yellow–up to 20 people
• Orange–up to 40 people
• Red–up to 80 people
• Maroon–up to 200 people
27
5.3 FEATURE DRIVEN DEVELOPMENT (FDD)
Feature Driven Development stresses on iterative development, effective and quality software, as well as an adaptable and flexible PM system. It does not stress on entire software dev process it focus on building phases and design part. The FDD have 8 practices form which the agile team can adopt one or more.
However, you can use all the eight practices of FDD to achieve max profit. It stresses on iterative development and quality and effectiveness of software it is well adaptable and flexible project management system. It includes five broad phases building model, feature list, plan by feature, design by feature and building a feature.
The overall guide to build a system. The guide consists of high-level diagrams that refer the relationship- between the class diagram and its sequences. But to base of everything we must follow the agile methodologies. Classes are assigned to each developer. Opposite of extreme programming but with collective ownership. As with the involvement of features teams follow the common approach considering being fault tolerant approach. The whole system is built on regular intervals. During the lifetime of building project, the code, design, analysis and testing artefacts are versioned before storing. Regular logs and statues are maintained, A. Firdaus et al (2012).
28
Figure 4: Life Cycle of Feature Driven Development(S.R Plamer et al,2002)
FDD also defines a collection of supporting roles, including:
• Domain Manager
• Release Manager
• Language Guru
• Build Engineer
• Tool Smith
• System Administrator
• Tester
• Deployer
• Technical Writer
29
Feature Driven Development consists of five broad phases: (1) develop an overall model, (2) build a features list, (3) plan by feature, (4) design by feature, and (5) build by feature. It has roles for project managers, chief architects, development managers, lead programmers, class owners, and domain experts. Its four major practices are object- oriented design, iterative development, inspections, and configuration management, David
F et al (2009).
5.4 EXTREME PROGRAMMING (XP)
The premise of Extreme programming is that we can get rid of 3 phases namely requirements, design and testing. As well as the documentation that go along with these phases.
Extreme Programming teams performs all the software development parallelly. The analysis, design, coding, testing and even deployment occurs with rapid frequency.
The Extreme programming uses iterations which are week long cycles. Every week the team does bit of planning, design, coding, testing and keep doing that in iterations. The premise is to work on small stories; Stories are small features and part of this features have customer value. Each iteration lasts for a week where every team member work on development of each story at the end of each week the deployment is done for internal review.
In Extreme programming the whole team sits in open workspace. Other than scheduled and assigned activities everyone in team plan and schedule their own work.
Team must work out the schedule are each meeting most of the meetings are done are standups. This self-organizations are hallmark of agile teams.
30
The concept of extreme programming was developed by the Kent Beck with his team of 20 developers in circa 1996.It was developed to overcome the failing project by
Chrysler. The initial practices which was considered was JIT, aggressiveness’s-chosen task, communication and model driven development. The core practices were extended later into around 13 practices which includes onsite customer service, TDD, Pair
Programming, open workspaces. However today Extreme Programming have around 28 practices for planning organizing designing and testing.
The core principles of Extreme programming have 4 values namely communication, simplicity feedback and courage. The contributors form a one team which includes a customer representative also called as business representative. The customer must provide requirements and principles to steer the project. The testers and programmers are other possible team members which are not mandatory. It is been believed that the best teams do not need to have a specialist or a contributor with special skill.
The Extreme programming team maintain coding standards. The goal is to make sure that the end code should look like it is developed by one single individual. The teams form a common program goal known as metaphor in XP team member work hard at high pace to work quickly as possible.
31
Figure 5: Extreme Programming Planning/Feedback Loops (David F. et al, 2010)
Extreme programming is well suited for small to medium sized teams. Where the communication and coordination between the team members is essential part of Extreme programming. Hence working remotely is not possible in XP.
During the planning phase of product, the customer must create story cards where they must specify requirements which are included in first release. Product team and customers are involved in planning phase of product. They discuss about the project technology they will be using to develop product. The prototype is also built in this phase.
The stories written are set into priority order in this phase.
32
The release iteration phase belongs several iterations before the first real-estate average duration of each iteration is around 1-4 weeks. The system architecture is built in this phase the system is made ready for production in last iteration.
The production phase of software the performance check and tests are performed before the system is put in release. Some additional changes might be done before the system is put in production. The enhancements and ideas of documentation are postponed for later execution. The Extreme programming approach have maintenance phase where support is given to customer.
33
CHAPTER 6
AGILE METHODOLOGIES COMPARISON
Different types of methodologies are followed in agile. All the methodologies are similar but with its own differences. Considering different scenarios different agile methodologies can be used. Choosing a right method is one of the most intimidating and difficult tasks. As the product future is based on this decision. Agile methods belong to some of the traditional practices like, Risk management, inspections, configuration management, Object oriented design, Prototyping and retrospectives.
Programmer like to combine various agile practices from different agile practices from any agile method. The complexity project length and the resources give variation to project. Changing the agile practice in middle of development can cause confusing atmosphere in team. Hence choosing the right practice at beginning is most important. The comparison of different agile methodologies based on team effort is explained in following table.
Figure 6: Comparison of various Agile Methods(David F. et al, 2010) It’s quite important to understand the methodology that will be implemented at first as it can get quite difficult for team to change it later. The migration to different method is
34 time consuming and complicated process where team must change the workflows of various tasks and the initial project workflow.
Agile methodology is based on some old traditional practice such as risk management, inspections, configurations management etc. It is also important for programmers to get best the best of all the practices in order to implement in project. If there is need of adopting new strategy in middle of the software, it is quite confusing for other team members as they might need some training for the same.
The complexity, project length, resources and vulnerability to risk gives variation to projects. Hence it is quite necessary for the team to decide the perfect agile method or combine various agile method before starting the project.
The advantages and disadvantages of each method is explained in following chart.
Every method has its advantages and disadvantages whereas different methods can be combined to make sure team come up with the best combination tailored to their project.
Figure 7:Comparsion of Advantages and Disadvantages(David F. et al, 2010)
35
6.1 Comparison based on flexibility.
Agile methods have varying degrees of flexibility. Part of this has to do with the sheer number of practices. Scrum has the fewest number, followed by Feature Driven
Development, Dynamic Systems Development, and Crystal Methods. Extreme
Programming has twice as many practices as Dynamic Systems Development. Among agile methods, Extreme Programming’s release planning is one of the most flexible and adaptable management frameworks, and Scrum and Extreme Programming have the fewest number of work products.
Thus, from a size, planning, and work product perspective, Scrum and Extreme
Programming are among the most flexible and adaptable agile methods. Although the roles and work products of Feature Driven Development, Crystal Methods, and Dynamic
Systems Development tend to favor traditional methods, Crystal Methods is supposed to be scalable, so it is considered the most flexible and adaptable agile method.
6.2 Comparison based on risk.
Agile methods have varying degrees of risk, often measured through the lens of traditional methods. That is, the less an agile method is like traditional methods, the more risk it is perceived to have. And, vice versa, the more an agile method is like a traditional method, the less risk it is perceived to have. For instance, because Dynamic Systems
Development has many traditional practices, such as project management, configuration management, and documentation, it is perceived to have low risk. Feature Driven
Development is also perceived to have low risk, because it has a high number of traditional practices, roles, and documents.
36
More importantly, it uses software inspections, which are commonly believed to substantially increase software quality. Therefore, Feature Driven Development is perceived to have low risk. Because Crystal Methods also has a high number of practices, roles, and traditional documents, it is perceived to have low risk. Furthermore, Crystal
Methods scalability is reportedly useful for safety-critical software.
6.3 Comparison based on usage.
Figure 8: Usage of various agile methodologies.(David F. et al, 2010)
Comparison of various agile methodologies based on usage from 2003-2008.Which shows that the scrum was quite popular back in 2003-2008 when the agile was introduced.
After scrum the next popular methodology was extreme programming
37
CHAPTER 7
IMPLEMENTATION OF SCRUM.
Scrum have always stood as a popular framework where the complex products are been developed. It is quite a lightweight framework and quite easy to understand. The scrum definition can be understood in way where people can fix and address the problems while maintain the productivity and creativity delivering the products with highest possible value.
Scrum framework allows to integrate and employ various techniques and
Processes. Scrum ensures the relative efficiency of product management and development practices of developers to give chance for developers to improve. Within scrum framework each component servs particular purpose and they are very important to scrum usage and success.
To get started with scrum we must follow the following steps :
7.1 Define scrum team.
Usually the scrum team comprises of 5-9 members. The members will have various skills specific to their job. The team will have developers, testers, support, designers, business analysis etc. The team is responsible for delivering shippable product at end of each sprint.
38
7.2 Defining sprint length.
On average the sprint time box lasts between 7-30 days and remains the same for most of the duration of the project. Planning meeting proceeds as the team moves forward in development and new sprint is planned. At end of each sprint the Review/meeting is held where the demo or presentation is given, and the progress is monitored. Once the progress in monitored then it can plan next sprint to move forward.
7.3 Appoint a scrum master.
Scrum master is also known as a catalyst of scrum group. They are the one who are responsible for ensuring the scrum group work effectively and progressively. In any conflicting event scrum master follows and resolve s the issue for the group. Scrum master is like a project manager except he doesn’t dictate what team do and shouldn’t try to manage or micromanage team. He is the one who assist team if they are stuck somewhere and assist in planning the coming work for coming sprints.
7.4 Appoint a product owner.
The product owner is a person who oversees making sure the team is producing the value form the project to businesses, client or whoever the product will be delivered to.
The product owner usually writes the stories and client centric requirements in form of stories prioritizes them and provides them the backlog.
39
7.5 Create the Initial Product Backlog.
Product backlog is Wishlist of all the user stories that will be completed in project.
The most important story should be on the top of list so that the entire backlog is ranked continuously in order of story importance. Usually the backlog has two type of work items namely the epic and the stories. Epics are the high-level stories which are rough in nature and not much detailed. Stories are more detailed for what should be done. Epic is broken fragments of stories.
The big stories are broken down into discrete tasks that team can work and report.
A story can have many cases and types such as bug defects modifications. New stories can be written and added to product backlog at any time by anyone in team.
7.6 Planning and starting your first sprint.
After going through the backlog prioritization team starts picking items form the list to brainstorm what to do and how much they can complete the upcoming sprint. This process is called sprint plan meeting.
7.7 Closing the current and starting the new/next sprint.
When end of timeframe/time block is reached the current sprint ends and the works gets done. If some part of work is remaining, it’s up to the team to either put the work in next sprint or to put the work in backlog.
The team now retrospect the whole work and discusses what went well and what could be improved before starting the next sprint and working on backlog. This process is continuously repeated before each sprint.
40
There is no limit for amount of sprint except if they are set by the deadline or entire backlog is solved/completed. If none of the criteria are met the sprint just keeps going.
41
CHAPTER 8
AGILE SURVEYS.
This chapter presents us with the survey which was conducted by VersionOne which comprises of various reasons, usage, demographics of user and popularity of agile methodologies.
This chapter of thesis is all about the survey which is conducted by version one known as 12th annual state of the agile report. This report found that the organizations are finally realizing the benefits of that they are set to achieve by adopting agile. “Survey respondents also report that their organizations are recognizing agile success at the project level. Of those with knowledge of success at that level, 61% reported that” most” or “all” of their agile projects have been successful.”, VersionOne (2018).
8.1 Reasons for adopting agile.
Figure 9:Reasons why agile methodology is adopted[VersionOne (2018)]
42
The survey provided us with the various reason why the companies are preferring to migrate to agile methodologies. As nowadays the clients want the software to be delivered as quickly the agile method indeed accelerates the software delivery time. Agile methods have various ways to accept changes as after every iteration it can be changed, which enhances the ability to manage the changing priorities/requirements. More than
55% said that agile increase their productivity, VersionOne (2018).
8.2 The respondents and participants of survey demographics.
Most of the participants comprised of scrum master or internal coach who comprised of 34% while the 14% were either program or project manager, while the other 14% were either development leader or director/manager and the rest 115 comprised of developers/QA/UX Designers or dev team members.
Figure 10:Demographics of survey participants[VersionOne (2018)]
8.3 Statistics of companies who have adopted agile.
More than 52 % of respondents have stated that more than half of their organizations are using agile practices. While 25% stated all their team are using agile.27% stated that more than half of their team are using agile. Most of the teams
43 which comprises of 35% are using agile for 35% which was 32% previous year. Only 2% teams responded they are not using agile at all. In total 97 % of respondents stated the they use agile development methods.
Figure 11: Statistics of how many are adopting agile [VersionOne (2018)]
8.4 Usage of agile methods for year 2018.
Figure 12: Usage of agile methods for year 2018[VersionOne (2018)]
44
The most popular agile methodology turns out to be the scrum as 56% of users prefers it while the 14% of users prefer to use the Hybrid methodology which comprises of mix of different methodologies. The third popular methodology is the Scrum-ban the scrum-ban is combination of scrum and Kanban. But form year 2016-2017 the use of
Kanban grew from 50 % to 65 % which is significant growth. The top 5 agile techniques include the 1. daily standups (90 %), 2. sprint iteration (88 %), 3. retrospectives (85 %), 4.
Sprint/iteration review (80 %), 5. Short iterations (69 %), VersionOne (2018).
Figure 13: Top agile technics[VersionOne (2018)]
45
8.5 Agile Initiatives.
Business value, on-time delivery of projects and customer/user satisfaction have remained the top three measures of agile initiative’s success as they have in the past few years with customer/user satisfaction moving into the top spot increasing from 44% last year to 57% this year. Product scope saw a decline from 40% to 20% from 2016 to 2017.
Business value increased as a cited measure of agile project success from 23% in 2016 to
43% in 2017. Customer/user satisfaction increased from 28% in 2016 to 46% in 2017 while velocity had been the number one measure of an agile project’s success decreased from 67% in 2016 to 42% in 2017. Iteration burndown also went down from 2016 (51%) to 2017 (27%), VersionOne (2018).
Figure 14: Success Measurement using agile[VersionOne (2018)]
8.6 Challenges Experienced Adopting & Scaling Agile.
From last year to this year we saw a decrease in respondents citing “organizational culture at odds with agile values” and “lack of business/customer/product owner availability” as challenges for adopting and scaling agile. Barriers that were cited more this year include “fragmented tooling”, “inconsistent processes across teams” and “general resistance to change”, VersionOne (2018).
46
Figure 15:Challenges Experienced Adopting & Scaling Agile[VersionOne (2018)] 8.7 Use of agile tools.
Figure 16:Popular agile tools of industry[VersionOne (2018)] The survey concluded that the most popular tool used was Atlassian as it is quite user-friendly and scalable. Microsoft excel which is contender is also popular because of its availability.
47
CONCLUSION
The thesis gives us great and detailed explanation about the important aspects of the agile and provides good explanation about its contents. The most important and popular agile methodologies are explained with its applications and detail information. The survey part of thesis explains us about the current practices in real world. It also explains us about how the traditional methods are getting voided and no longer effective and it is more practical to use agile methods. It also explains and gives us example about the current applications and usage. Moreover, the survey presents us with deep insights about how the trend is shifting towards the agile and how popular it is among software developers and engineers. Thesis presents us with the guidelines about the scrum which is quite effective way of developing the software it also presents us with the usage of scrum.
Various agile methods and practices are available for the software development.
Which are not same in terms of strength, flexibility, weakness, risk and usage. Scrum provides the most and is lightweight development method with longer sprints and whose popularity is steadily growing. Extreme programming provides low risk, robust methodology for release planning. Many developers combing Scrum and XP or Scrum and pair for software development.
FDD provides some flexibility and is based on traditional Object-Oriented design providing good quality control. Crystal methods gives good blend of agile with some risk.
It was designed for scaling. Adaptive software development is used especially for complex and large software development. In this development method the project execution is done in cycles.
48
Agile methodologies are defined, disciplined systematic and quantifiable approach for building software products and it relies heavily on customer involvement. It is quite adaptable to changes and welcomes new features and provide great scope for continuous improvement. A very important take away is agile methods should not be judged based on their size and how they are like traditional methods. Rather they should be judged based on quality metrics which they offer and individual established practices. Though agile promise the faster delivery, sometimes quality is also impacted due to short timelines.
Existing system analysis, design decision, Code Review are more often compromised as on time delivery is the focus.
49
REFERENCES
[1] K. Schwaber, Agile project management with Scrum. Redmond, WA: Microsoft
Press, 2004.
[2] J. Shore and S. Warden, The art of agile development. Beijing: OReilly, 2008.
[3] J. Garbajosa, X. Wang, and A. Aguiar, Agile Processes in Software Engineering
and Extreme Programming: 19th International Conference, XP 2018, Porto,
Portugal, May 21–25, 2018, Proceedings. Cham: Springer International
Publishing, 2018.
[4] M. Huo, J. Verner, L. Zhu, and M. Babar, “Software quality and agile methods,”
Proceedings of the 28th Annual International Computer Software and
Applications Conference, 2004. COMPSAC 2004
[5] Á. Medinilla, “Epilogue: Implementing the Framework for Agile Agile Kaizen,”
Agile Kaizen, pp. 155–157, 2014.
[6] “VersionOne 12th Annual State of Agile Report,” DevOps and Agile Solutions
for the Enterprise. [Online]. Available: https://explore.versionone.com/state-of-
agile/versionone-12th-annual-state-of-agile-report.
[7] David Rico, Hasan Sayani, Saya Sone :The Business Value of Agile Software
Methods: Maximizing ROI with Just-in-Time Processes and
Documentation. J. Ross, 2010.
[8] Tutorialspoint.com. “SDLC Iterative Model.” Www.tutorialspoint.com,
www.tutorialspoint.com/sdlc/sdlc_iterative_model.htm. [ Accessed: 09-Feb-2019]
50
[9] Larman, Graig 2004. Agile & Iterative Development. A Manager ‘s Guide.
Boston: Pearson Education, Inc.
[10] Schuh, Peter 2005. Integrating Agile Development in the Real World.
Massachusetts: Charles River Media, Inc.
[11] Pekka Abrahamsson, Outi Salo, Jussi Ronkainen, Juhani Warsta “Agile Software
Development Methods: A Comparative Review1.” Agile Software
Development, 2010, pp. 31–59., doi:10.1007/978-3-642-12575-1_3.
[12] Bendix, L. “Software Configuration Management in Agile Development.” Agile
Software Development Quality Assurance, doi:10.4018/9781599042169.
[13] J. Kile, “Agile Software Development Quality Assurance,” Agile Software
Development Quality Assurance.
[14] Obstacles to Agile Software Development, Agile Software Construction, pp.
239–246.
[15] T. Stober and U. Hansmann, “Overview of Agile Software Development,” Agile
Software Development, pp. 35–59, 2009.
[16] D. Parsons, “The Agile Manifesto and Agile Methods,” Rapid and Agile Software
Development, pp. 5096–6124.
[17] “Introducing Agile Methods into Your Organisation,” Agile Software
Construction, pp. 211–216.
[18] E. Mnkandla and B. Dwolatzky, “Agile Software Methods,” Agile Software
Development Quality Assurance.
51
[19] M. Jørgensen, “Do Agile Methods Work for Large Software Projects?” Lecture
Notes in Business Information Processing Agile Processes in Software
Engineering and Extreme Programming, pp. 179–190, 2018.
[20] S. R. Palmer and J. M. Felsing, “A Practical Guide to Feature-Driven Development
(the Coad Series),” Prentice Hall PTR, So Paulo, 2002.
[21] K. Schwaber and J. V. Sutherland, Software in 30 days: how Agile managers beat
the odds, delight their customers, and leave competitors in the dust. Hoboken, NJ:
Wiley, 2012.
[22] C. Larman, Agile and iterative development: A Managers guide. Boston: Addison-
Wesley, 2012.
[23] S. Ambler, Agile modeling: effective practices for eXtreme programming and the
unified process. New York, NY: J. Wiley & Sons, 2009.
[24] S. Mark, “Test-Driven Development,” Agile Software Development Quality
Assurance.
[25] A. Firdaus, I. Ghani, and N. I. M. Yasin, “Developing Secure Websites Using
Feature Driven Development (FDD): A Case Study,” Journal of Clean Energy
Technologies, pp. 322–326, 2013.
[26] https://project-management.com/xp-fdd-dsdm-and-crystal-methods-of-agile-
development/ [ Accessed: 03-Jan-2019]
[27] Image : https://en.wikiversity.org/wiki/File:Crystal_Family_example.jpg
[ Accessed: 09-Feb-2019]
[28] Figure4:https://www.visual-paradigm.com/scrum/extreme-programming-vsscrum/
[ Accessed: 05-Apr-2019]
52