This is the introductory chapter of the dissertation. It discusses the central ideas and the core processes that the research will go through. This section will develop the background of the study, define the research problem and research questions. This will culminate in the formal aims and objectives that will be used for the study.
The Agile Software Development represents a major exit from the traditional method to software engineering. Agile methods are group of system development methodologies that share common value and goal. It involves adapting to changes continuously and delivering of software product (Strode et al., 2009).
Agile software process is iterative and incremental with high communication level and customer involvement (Schwaber and Beedle, 2001). “The Agile software methodology involves modification and improving requirements through collaboration with cross functional teams to encourage organisation teams in the process of developing the software” Schwaber and Beedle, 2002).
In an early paper that laid down the foundations for the Agile approach, the proposition by (Takeuchi and Nonaka 1986) concerning Agile Software Development involved encouraging the proximity of team members and verbal communication to create a robust quality framework. The proposition of Takeuchi and Nonaka in promoting Agile software development were based on:
Flexibility: A system where different software development processes can be modified to meet the new changes in the software development process.
Unity of Purpose: All the parties in the software development process had to be committed to a single vision and mission. And they had to get updates on a regular basis.
Coordination: All the different units had to work with each other to attain results at every point in the software development process.
These are the main components and elements of Agile Software Development. This approach to software development is in contrast with the traditional systems where software development was in stages (Schwaber and Beedle, 2002).
Business organisations are changing dynamically, hence software developers, team leaders, software developers, stake holders etc. are aware of the need to quickly adapt to the change in order to compete. Constant communication and constant interaction is a central feature of Agile Software Development approaches and systems (Fowler, 2012). This is because the need to maintain unity of purpose and enhance the holistic nature of the software development process requires the exchange of information and constant interaction between the team members. Daily stand-up meetings are a major practice organisations used by agile teams to facilitate the regular exchange of information.
Stand-up meetings are daily meetings that are held to provide status updates to team members in Agile Software Development projects (Fowler, 2012). This involves quick updates and a summary of activities that were conducted in the previous day (Fowler, 2012). They are conducted on a daily basis and they last for between 5 and 15 minutes (Fowler, 2012). According to Schwaber and Sutherland (2001), daily stand up meetings are held at the same location and time daily by the development team in order to synchronize their activities and create a plan for the next day. The meetings are meant particularly for inspecting the work of the last 24 hours and forecasting what needs to be done in the next day. They acquire their name through the fact that they are done whilst standing and participants share views and information on several issues including:
What was accomplished the previous day.
What will be accomplished in the current day.
The obstacles faced and how the obstacles will affect the day’s work (Fowler, 2012).
It is a daily routine that is held at a specific time and same place. Stand-up meetings are therefore an essential part of some agile software development methodologies including Scrum and XP and will promote the development of software through those approaches Stray et.al (2012).
Although stand-up meetings are a commonly used practice in Agile Software development, it is not quite clear what their benefits and drawbacks are. Should teams accept the practice without knowing its actual importance and the limits of its effectiveness? This is a question that leads to the next stage of the research.
1.2 Research Problem
The research problem in this case is to investigate the actual practice, perceptions and the contribution that stand-up meetings make to the agile software development approach. There are several reasons for looking at this research problem. The primary reason is that there is very little academic literature about stand-up meetings (see Chapter 2). Consequently, there is a need for more empirical investigations into stand-up meetings, to confirm whether they are used by teams to ensure constant communication and coordination, staying up to date, and sharing ideas between the team members of the software development group.
The lack of empirical studies into stand-up meetings provides a motivation for the research undertaken for this dissertation.
1.3 Research Questions
Kothari (2005) identifies that “research is a structured enquiry into a given topic or manner to formulate logical conclusions”. From the discussions above, it is clear that there is need to investigate the actual practice and impact of stand- up meetings in agile software development.
The aim of the research is to examine the role of stand-up meetings in agile software development. In order to attain this end, the following questions will be explored:
What is the actual role of stand-up meetings in agile software development?
What are the merits and demerits of stand-up meetings
What are practitioners’ views of stand-up meetings?
1.4 Motivation for Research
The research is an enquiry into a real-life phenomenon which tests and examines the actual importance and the centrality of stand-up meeting in promoting coordination, communication and interactions between the members of a software development team. This will seek to add up to existing knowledge on this aspect of agile software development. To this end, the research provides an independent scientific study of stand-up meetings in agile software development to provide an objective conclusion on its position in the software development process.
Stand–up meetings according to literatures contribute to many benefits associated with project success. This motivated the researcher to perform the study to explore the actual role of stand-up meetings in agile software development.
5 Organisation of Study
The research will view the position of stand-up meetings. This study will be divided into different phases.
Firstly, the literature review to find out what the role of stand-up meetings has in agile methods and what empirical research had been done about their use in practice.
Secondly, the design and distribution of questionnaires to practitioners who uses the agile method with the aim of finding out the actual practice and views about the usefulness of stand-up meetings.
Thirdly, the result will be analysed and will be related back to literatures.
1.6 Chapter Outline
This research will be conducted in six chapters. This chapter provides the introduction and identification of the purpose of the research and the sequence of conducting the study. Chapter 2 will be a critical literature review about stand up meetings and agile software methodologies. This will help to define the key components and elements of stand- up meetings. Factors for analysis will be deduced from the literature review.
Chapter 3 is a research methodology whilst Chapter 4 will provide the results or findings of the field work that will be conducted according to the research methodology. Chapter 5 will be an analysis of the findings and Chapter 6 will present conclusions and dominant trends and theories as they were presented in the research work. References and Appendices are provided after the conclusion chapter.
2.1 LITERATURE REVIEW
Software development methodologies have been in existence for some time now. These methods were created as a means of enhancing the software development process. Robinson (1992) identifies that the main basis for the creation of better software development methodologies is to minimize the materials and resources that are used by the companies in software development.
The traditional approach to software development involves the “definition of requirements which leads to the design of the development process and implementation” (Dean and Gravel, 2009). This is known as the waterfall process (Royce 1970) and is a sequential approach to software development.
2.2 WATERFALL APPROACH
The Waterfall Approach to software development has a sequential process where activities follow each other downwards, like a waterfall; hence the name (Royce 1970). The sequence applied in this methodology involves requirements gathering, analysis, design, coding, system integration, system test and acceptance ( Snyder 2002). Projects that follow the Waterfall Approach are normally segmented according to the different phases, although some of these phases might overlap during the process.
Figure 1: The Waterfall Approach (Source: Snyder, 2002)
Figure 1 shows the main stages of the Waterfall Approach to software development. The diagram above represents the waterfall method as a traditional approach. It depicts the sequential phases that a software developer goes through. Clearly, the sequence depicts that the developer will gather the requirement at the commencement of the project. This means that the requirements gathered at that level are considered complete and it is difficult to change requirements during the project. These requirements form the basis for analysis, designing, coding, system integration and system testing. The requirements are the standard which the design follows.
Waterfall model is the oldest software development process. It is simple to use, the requirement are carefully gathered, the design are clearly specified and the method is greatly applied in both large and small software intensive projects ( Huo et al., 2004).
The setback of the method is that it is difficult to respond to changing requirements, all the process must follow the same sequence, the progress of the work is not visible and there is minimal feedback as result can only been seen at the completion of the work (Huo et al., 2004). This method usually lacks the flexibility that can help in the adjustment of the processes (Segal, 2010). Thus, if the assumption of a given process is not appropriate, the project is prone to failures as it proceeds.
There is a general delay in error detection because it is usually noticed during the testing phase then; developers cannot do much about it (Muller-Schloer C, 2010). Hence, this has the propensity of delaying a project especially if the problem is a major one, the software developers will have to start the process again.
The inherent problems with the waterfall methodology led to the development of alternative approaches. In the 1980s and 1990s prototyping and spiral models were attempted. In the later 1990’s agile methodologies started to emerge. This culminated in the creation of more dynamic and flexible approaches to software development like the Agile Software Development methodology.
For complex software designs, which address issues like the dynamically changing technologies, users changing specification, complexity and global competition the Waterfall approach can prove to be ineffective and inefficient ( Huo et al., 2004).
This development approach involves the creation of incomplete software versions, which are subjected to testing for validation before a final model is chosen and designed, coded and tested for final approval (Jalote, 2007). The utilisation of this method attempts to reduce the inherent risk in the waterfall approach of relying purely on early verbal requirements descriptions for specifying a software, which may become invalid (Kamrani and Nasr, 2006). Following the testing of various prototypes, the essential changes can be introduced into the product to ensure conformity to user requirements.
When utilising this approach, understanding of the underlying problem remains essential in providing sufficient solutions, and avoiding solving non-existent problems. The prototypes remain a simulation of some aspects of the final product and could become totally different from the final product.. Through prototyping, released software could be able to perform desired functions because of the pre-release information gathered, which
can allow changes to be made to the final product. There are basically two types of prototyping approaches namely:
The Evolutionary approach: The main aim when using Evolutionary Prototyping is to build a very robust prototype in an organised manner and continuously refine it. The reason for this is that the Evolutionary prototype, when created, forms the heart of the new system, and the improvements and further requirements will be built.
When developing a system using Evolutionary Prototyping, the system is continually refined and rebuilt.
The Throw-away approach: This refers to the design of a model that will eventually be discarded rather than becoming part of the final delivered software. After initial requirements gathering is accomplished, a simple working model of the system is constructed to visually show the users what their requirements may look like when they are implemented into a finished system.
With the rapid growth and development in businesses, processes are more complex, interconnected, interrelated than ever before. The approach of prototyping appears to be a dynamic approach to software development than the Waterfall Approach.
The use of prototype is advantageous because the use of a prototype during the analysis and design of a project can be an efficient method for project design and also for fact- finding. This is true for systems where the requirements are difficult to create, for example designing for inexperienced users, or one involving a changing situation and environment.
Another advantage of building a prototype is that it enable analyst to learn not only what the user really wants, but also about how to design and develop a system meeting specified requirement. It allows the proposed solutions to any technical problems to be put into practice (Dearnley and Mayhew, 1983).
The most obvious disadvantage of using prototypes is that it wastes a lot of time and resources. Another problem is persuading people to use the method. To the person controlling the funds for the project, the idea of creating a prototype, which may be altered and replaced several times, and which may be thrown away after the production system is implemented is unlikely to be appealing (Dearnley and Mayhew, 1983).
2.2. AGILE METHODOLOGY
Agile methods grew out of the prototyping and RAD (Rapid Application Development) approaches of the 1980s and 1990s. The agile approach is highly iterative and incremental thereby providing a suitable platform for both stakeholders and developers to communicate and work together with a broader understanding of concepts and processes (Segal, 2010)
Although agile method such as DSDM has been in existence for a period of time, the Agile Manifesto was officially published online in 2001 (Brown, 2012). Thereafter, some group created the agile alliance, a non-profit organisation that promotes the agile development (Highsmith, 2001). Being agile is basically not following a set of fixed practices but based on a set of values which support more flexible and adaptable software development, effective response to change, effective communication among stakeholders, customer contribution in a team, team organisation performance control (Beck and Andres 2004). The agile manifesto goes thus;
“We are uncovering better ways of developing software by doing it well and helping others do it. Through this work we have come to value:
Individual and interactions over processes and tools
Working Software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value on the item on the right, agile method place higher value on the item on the left (Highsmith, 2001). The value gained from the agile manifesto serve to manage change and reduces cost.
The Agile manifesto served to involve active communication and interaction between stakeholders to produce an acceptable approach on how to improve the agile method. The manifesto was a rallying point for different groups to integrate their views and opinions on the new system. It was published to integrate the views of more stakeholders and enhance its usage and improve the software development procedures. Communication is an integral part of agile method. System can be built without processes and tools but cannot be built without people; the better the people in the team communicate, the better the team. Communication should take place orderly in an appropriate way between the management, team and the stakeholders. Since change is constant in agile project, communicating constantly is the means where the participants can connect (Alleman, 2005).
The agile methodology has numerous advantages and benefits over other traditional approaches to software development. The first and most obvious advantage is that it involves a higher degree of communication and stakeholder interaction which is not found in other methods and approaches. Another element is the promotion of co-location which means unifying or bringing together team members in the software development process (Moreira, 2009). Writers like Watkins in 2011 identify that co-location brings together developers, testers and other stakeholders and they get to understand, respect and cooperate with each other better to attain better results.
Another element is that agile methods encourage team members to ask and answer questions. This aids self organisation amongst the team members (Layton, 2012). This is because all team members get to communicate with each other and this compels them to prepare in order to remain up to date. Without such meetings, there might be little or no motivation for self organisation.
As identified above, the agile methodologies offer large solutions to software development challenges. This is mainly immersed in collaboration and proper coordination between the various stakeholders in the software development process.
Agile methodology seeks to ensure active participation of various individuals involved in the process of software development (Cohen, et al., 2004). Contrary to the existing, highly rigorous traditional software development methodologies, agile methodology encourages flexibility in response to change. Inflexibility of traditional methodologies continues to become a limiting factor towards successful completion of various projects designed utilising those approaches. While changing a project mid-way could have adverse effects, external circumstances make change inevitable, within projects. In software development, therefore, development methodologies incorporating change should become adopted in enhancing successful project completion.
The agile methodology remains the sole framework appearing to incorporate unforeseen changes, occurring during project lifetime. The changes applied upon products, however, must become analysed and defined as essential for successful project completion. The agile methodology developed from combination of various aspects of existing methods, seeking to establish an efficient methodology which could be utilised in delivering quality software products (Cohen, et al., 2004). The numerous agile methods utilised, seek to promote teamwork, process adaptability, collaboration and development throughout project lifecycle. The method normally breaks down the project into small increments, involving minimal planning, and independent of long-term planning. This breakdown normally allows the methodology to provide users with quick solutions to existing problems. With numerous individuals working on a small section of the project, the duration taken to complete projects becomes immensely reduced. Reduction of time taken to complete projects through work division consequently improves the solution delivery capacity of the agile method.
Within agile development method, team organisation relies heavily on cross-functionality and self-organisation. This organisation ensures there are no hierarchal roles played by team leaders or any member within the team. Teams function as single units having constant consultation between team members. Through this consultation, all members become actively involved within the project processes, and their input becomes essential towards the development process. The iterations allocated to different individuals normally require personal input towards completion of the task. With independence to undertake functions in methods deemed appropriate, team members are expected to complete their iterations in a method they feel best suited for them. The individuals have the liberty to utilise any methods to deliver final product. Agile development method, therefore, encourages creativity in delivering different products.
Agile methods are also characterised by emphasis of face-to-face communication over written communication methods. The settings for working areas always support this communications; hence the utilisation of open offices. Open offices normally allow face-to-face communication between members based in the office. This system, however, works best in teams located within the same setting. Teams having members stationed in different locations can utilise videoconferencing, voice-chats, among other methods which facilitate face-to face communication. For efficiency, in face-to-face communication, teams remain limited to less than ten individuals for most development projects. Larger projects requiring larger teams necessitate distribution of members to different locations to ensure a relatively small number of individuals, within a single location.
The agile methodology presents a platform for increasing agility through application of specific techniques and tools aimed at improving agility of the process. The application of different development techniques plays a fundamental role of improving the quality of developed software, through these methods. The core values presented by agile methods remain sensitivity, flexibility and capacity to focus on delivering quality products (Cockburn, 2007). A combination of different methodologies become essential in ensuring the adopted agile practices suit the development teams, and situations under which development occurs. The agile method offers numerous solutions to the various limitations existing in the traditional sequential methods.
Most agile development methods utilise routine meetings, conducted daily with all team members present. These routine meetings might include other interested individuals, like stakeholders to the project who are not part of the product development team. During these meetings, members normally inform the teams about progress of their allocated iteration. Each individual also identifies the challenges faced during delivery of required product. These meetings ensure problems become detected as they arise, with solutions being provided instantly.
The efficiency of agile methods becomes enhanced through early problem identification, and immediate solution provision. This ensures continuity of the project with minimal technical problems as they become addressed as they arise. The quick response to problems remains the major advantage of agile methods over traditional development methods.
2.4 AGILE METHODS
Numerous agile methods have been developed and utilised in software development. The individuals involved within the production normally apply a specified routine agile method, determined by organisation or the team itself. While various methods exist, production teams must choose methods fitting their requirements, and which could ensure smooth development process. For best system approach method for a specific situation, the development team makes the decision. Some of the commonly applied agile methods include the following.
This method remains focused on flexibility of the development process, with development teams working as a single unit with a common goal. Scrum is a very simple approach and it does not contain complicated techniques and frameworks for software development (Rubin, 2012). A scrum team typically consists of four to seven developers. The team member shares a common view and attitude towards work. If there is testing to be done and there is no dedicated tester available, then someone else can do the testing. It consists of the scrum master, product owner, product backlog, and the various meetings held during the process which includes: planning meeting, daily scrum, sprint review, and sprint retrospective. The method includes a series of meetings, normally held daily, to enable emergent issues to be dealt with and allow a review of previous activities.
The scrum master and the product owner are responsible for the product development. The scrum master is more of a facilitator to the team as the team is self-organising. The product owner is the voice of the customer on site. The method divides entire project into sprints – time boxed efforts for delivering specified software requirements. During each sprint a finished portion of the product must be delivered (Schwaber, 2004). The scrum method encourages, face-to-face communication, while ensuring self-organisation within various teams. The importance of scrums, within the development process remains the capability to address unpredictable challenges as they arise during project development.
Figure 2: Scrum Process ( Schwaber K, 2004)
Scrum remains characterised by numerous products including, product backlog, sprint backlog, increment, and burn down chart. These products provide essential information to team members regarding delivery of the product. Product backlog indicates all product requirements, while sprint backlog indicates the various requirements selected for the current sprint. The increment show completed product backlog items, while burn down shows remaining work according to the sprint backlog.
Firstly, the team chooses the product backlog items for the sprint.
It specifies the user stories, uses cases or tasks with the highest priority to be implemented in the next sprint.
Secondly, the sprint backlog
Product owner must prepare backlog prior to the meeting
Secondly, product owner must be available.
Daily Scrum /Stand-up
Establish and maintain.
Presentation of the deliverable of product owner.
Not more than one hour for the team to prepare
Improvement of the development process
Questions to be answered.
What went well during the last sprint?
What could be improved in the next sprint.
Table 1 (Schwaber K, 2004).
The table above compare the various type of scrum meeting and their purpose (Schwaber K,
2004). The concept Scrum was developed by Jeff Sutherland, John Scumniotales and Jeff McKenna in 1993 who took inspiration from a 1986 article of Takeuchi and Nonaka about a holistic approach to innovation where all team members took part in the whole process.
Denning (2012) also identifies that Scrum practices is widely used in business and industry. In the business world, scrum is used through a mechanism where business organizes work in short cycles, management does not interrupt the team during the work cycle and the team reports directly to the client and not the manager. The team defines their goals, work and effort through iteration (Denning S, 2012).
Scrum is advantageous in improving productivity by delivering incrementally. It enhances continuous improvement and team communication. It improves visibility for team members and allow customers to receive regular feedback on hoe the product functions (Denning S, 2012).
There are some limitations in Scrum too. It requires constant monitoring of project progress; management must be willing to make changes to help Scrum teams succeed and
Scrum is new and quite a different approach, adapting to it is sometime difficult because people often resist change (Denning S, 2012).
DYNAMIC SYSTEM DEVELOPMENT METHOD
This method embraces the principle of continuous user involvement in project development process. The dynamic system development method is an improvement and extension of the application of the methods used in traditional methods to enhance software development platform (Zeff M, 2009). The principles of DSDM revolve around making the individuals adopt proper attitudes and mind-sets to enable delivery of consistent results in software development (Zeff M, 2009).
The DSDM method remains focused on delivering software satisfying customer requirements, through understanding the priorities of the business. Communication between team members remains essential as it enables individuals to become informed of various requirements. DSDM is a holistic approach to projects and the scope of it ranges from the whole lifecycle which commences from the business plan through to the deployment and maintenance phases
It started in 1994; it was developed in the United Kingdom by a Consortium of vendors and expert in the field of information system. It was originally based upon the Rapid Application Development (RAD) methodology (Stapleton, 2003). It is an iterative and incremental approach that emphasis on continuous user involvement. The aim is to deliver software systems early while adjusting for changing along the development process. DSDM is one of the agile methods for software development and it forms a part of the agile alliance (Agile Alliance, 2013)
The important features that distinguished it from other approaches is that it fixes resource and time first and then make modifications on the amount of functionality accordingly (Abrahamsson et al, 2003). DSDM has some good advantages such as early and frequent release of projects, smooth transition from stage to stage, it carefully worked-out process and based on priority of requirement it categorised requirement into specific types (Stapleton, 2003). DSDM consists of five stages which are feasibility study, foundations, exploration, engineering and implementation (Agile Alliance, 2013).
The first two phases, which are feasibility stages are performed once (Robinson, 2012). The actual development work is iterative and incremental and is performed in the last three stages. The method iterations are time boxes. The time box lasts for a predefined period of time and the iteration ends within the time box.
The feasibility study phase accessed the suitability of the DSDM method with regards to the project types. The project team and the users communicate to decide the efficiency of the method. This stage outlines the feasibility report and the development plan. Optionally, a prototype can be produce if the business or technology lacks some decisive ability. The feasibility study stage is usually very short, normally few weeks.
The foundations stage: In this stage, the business and technology involved is analysed. A workshop is organised where all the stakeholders are gathered to discuss the relevant aspects of the system. The system architecture definition and an outline prototyping plan are carried out in this phase. The functional model iteration is usually the first iterative and incremental phase. The approach used for each iteration is well structured and the result are analysed for subsequent iterations. A prototype system is usually built which can be further improved on.
The exploration and engineering phase: The working system is developed here. The output conforms to the requirement. Design and build are iterative; the prototype system is reviewed and further developed based on the user’s requirement. The final implementation phase is where the system is transform from the development environment into the actual production stage. The users are usually trained before the system can be delivered.
The feasibility study phase involves the examination of business appropriateness and technical requirements whilst the business study examines important components that involves the definition of primary goals and elements (Robinson, 2012). The functional model iteration is a prototyping to determine the user requirements and a demonstration of the functionality (Robinson, 2012). A system design or build iteration is for refining and detailing the functional prototype with the goal of delivering a prototype design that meets the functional and non-functional requirements (Robinson, 2012). The implementation phase involves the delivery of the final deliverable to the end user for evaluation and project audit.
Figure 3: DSDM Life Cycle (Caine, 2012)
The core techniques in the implementation of DSDM which include facilitated workshop, Time boxing, MoSCoW, and Prototyping (Smith, 2010).
TIME BOXING is a traditional project management system which includes breaking down work to different positions and this must be completed on regular periods of time. Timeboxing is an important part of DSDM. The goal of this technique is to support the realization of keeping the project within a fixed timeline and budget. Timeboxing is an attempt to split the project up as much as possible, with each part of the project having a fixed deadline and costs
MoSCoW is a method that ensures efforts are focused on the highest priorities (Smith, 2010). This enables the software developers to prioritise their actions and get a much more efficient method of programming and developing the software.
“It involves the identifications of the essentials; the Musts have, Should have, Could have, and Want but won’t have this time” (Smith, 2010).
Must have: Essential requirement on which the project success relies
Should have: Important requirement but not essential to the project success
Could have: Requirements that can be excluded from the system functionality without having any serious effect on the project.
Won’t have: Requirements that will not be part of the system functionality in the current project.
PROTOTYPE are iteratively refined and gradually evolved into working software subsystem ready to be deployed as an increment into the operational environment and integrated into the system built so far (Smith, 2010).
FACILITATED WORKSHOP support team working together and enhance high quality team-based decisions to be made within a short time (Smith, 2010).
With the DSDM method, there is early and frequent releases of project, the processes are carefully worked-out, transitions from stage to stage are carried out smoothly and the requirement is based on prioritization (Stapleton J, 2003).
DSDM has some limitation. It lacks formalism and constraint of time and resources.
It is not ideal for large and complex projects (Stapleton J, 2003).
For more on this paper, click here
To get a custom written paper in this or any other topic, click here
Expert consultations to help you with studies
We have competent advisors in majority of main subjects
We are available around the clock and all over the world
We promise to meet your expectations or your money back
Place your order now
Our Service Charter
Excellent Quality / 100% Plagiarism-FreeWe employ a number of measures to ensure top quality essays. The papers go through a system of quality control prior to delivery. We run plagiarism checks on each paper to ensure that they will be 100% plagiarism-free. So, only clean copies hit customers’ emails. We also never resell the papers completed by our writers. So, once it is checked using a plagiarism checker, the paper will be unique. Speaking of the academic writing standards, we will stick to the assignment brief given by the customer and assign the perfect writer. By saying “the perfect writer” we mean the one having an academic degree in the customer’s study field and positive feedback from other customers.
Free RevisionsWe keep the quality bar of all papers high. But in case you need some extra brilliance to the paper, here’s what to do. First of all, you can choose a top writer. It means that we will assign an expert with a degree in your subject. And secondly, you can rely on our editing services. Our editors will revise your papers, checking whether or not they comply with high standards of academic writing. In addition, editing entails adjusting content if it’s off the topic, adding more sources, refining the language style, and making sure the referencing style is followed.
Confidentiality / 100% No DisclosureWe make sure that clients’ personal data remains confidential and is not exploited for any purposes beyond those related to our services. We only ask you to provide us with the information that is required to produce the paper according to your writing needs. Please note that the payment info is protected as well. Feel free to refer to the support team for more information about our payment methods. The fact that you used our service is kept secret due to the advanced security standards. So, you can be sure that no one will find out that you got a paper from our writing service.
Money Back GuaranteeIf the writer doesn’t address all the questions on your assignment brief or the delivered paper appears to be off the topic, you can ask for a refund. Or, if it is applicable, you can opt in for free revision within 14-30 days, depending on your paper’s length. The revision or refund request should be sent within 14 days after delivery. The customer gets 100% money-back in case they haven't downloaded the paper. All approved refunds will be returned to the customer’s credit card or Bonus Balance in a form of store credit. Take a note that we will send an extra compensation if the customers goes with a store credit.
24/7 Customer SupportWe have a support team working 24/7 ready to give your issue concerning the order their immediate attention. If you have any questions about the ordering process, communication with the writer, payment options, feel free to join live chat. Be sure to get a fast response. They can also give you the exact price quote, taking into account the timing, desired academic level of the paper, and the number of pages.