Comparison Of Scrum And XP Methodologies For System Development: A Case Study For OJL

An Overview of Scrum Methodology

The required system needed for the OJL can be developed using a variety of different methods and approaches. However, each of the methods may or may not be the most optimum method and the resulting output may as well differ based on the methods and approaches that were followed. Also, the approach that is followed also plays an important role in deciding the behaviour of the system and also, it’s attributes. One of the choices of system development methodologies is known as adaptive methods for development system. Each of these methods have their own set of guidelines and approaches, however in the case fo adaptive methods, the defined approaches are not static and it changes from project to project. This is because, each of the project have their own unique requirements and differ in types. Methodologies like the one suggested here help the developers in developing robust and scalable system by making use of ad-hoc process. The most famous class of development methodologies under these methods are the Agile frameworks. These methods are meant to provide projects as well as their respective team members with the abilities and benefits of producing scalable products which are in according with the expectation of customers. The project in this case is about developing a system that will run on mobile devices for an organization known as Odd Jobs Limited or OJL. The main users of this system would be the contracting staff that have been employed by the company. The report would further address the right choice of development methodology while comparing SCRUM as well as XP methodology for system development.

SCRUM is a type of adaptive software development methodology and is primarily based on the previously mentioned Agile Frameworks. SCRUM does not have any fixed steps or sequences that has been defined as per it’s methodology and the overall development process that has to be followed is based on ad-hoc process. The requirements for the project are also mainly analysed and stored as user stories. The project work and development is executed on the basis of variety of sprints that are completed one after the other. Also, a sub-set of user stories are extracted from the backlog of the product and are then placed in sprint backlog in order to execute them. One cycle of such runs for over a period of 14 days and it goes to a maximum of 4 weeks. Typically SCRUM based project has small team size that varies from 5 to 9 members (Sachdeva, 2016). Customers are in the end provided with a product that works and they are supposed to test and give their feedbacks.

An Overview of XP Methodology

SCRUM methodology has certain key advantages over other methodology and can prove to be quite valuable in similar cases.

• The customers would get the product delivery in very short intervals and they would also be able to receive hands-on experience for working on the product towards the end of each of the sprint. Furthermore, customers will be able to interact with the system even before the final release of the product.
• The customers would also be able to provide their feedback and their responses after working on the product and these feedbacks and comments are then incorporated in sprint which enhances the quality and overall abilities of the final product.
• The project under SCRUM is also highly scalable and any changes requested for the system can be easily scaled up and down during the development of the project (Mahnic, 2012).
• There are many risks associated with an IT Project. For the same, risk analysis and identification shall be handled in the initial sprints itself. Further head, the dynamic risks would be executed.

• SCRUM requires lot of attention and devotion from the developers and project managers. In efficient team or team with no SCRUM experience may hinder the complete benefits that SCRUM provides (Rajasekaran, 2015).
• SCRUM does not require an END date and as a result, certain activities such as go-live, training and support becomes vague and ambiguous in the case of SCRUM base  projects. There’s also an issue that the project may fall into limbo and continue indefinitely.
• If any member of the project team leaves the team, then the new member who will be added to replace him would face certain difficulties in catching it up.

XP or Extreme programming is a software development methodology which is also based on the Agile frameworks. The main standout feature of XP is it’s ability to incorporate frequent changes within the project at ease. The initial phases in XP requires the team members to work on analysing the project outcomes as well as results. After that, the development-oriented tasks are executed and simultaneously, parallel testing is also carried out. The methodology is famous for it’s shorter development lifecycles as well as enhanced team productivity (Wood, Michaelides & Thomson, 2013). XP incorporates the use of checkpoints in order to manage project needs as well as modifications done on those requirements.

• The intensive tests within the project would ensure that identified risks and gaps are resolved as and when they occur.
• The code being produced under the XP methodology would follow principles of simplicity and ensure that the developers could easily make the changes and when needed.
• Software development cycles within the XP are quite short in XP and it allows customers to be able to test out the product in development rapidly (Fotjik, 2011).

• There could be certain cases in which the team member working on the project are not working from a common location. As a result, remote access as well as telecommunication facilities are required. Now, in the case of XP methodology, remote working sessions and teleconferencing abilities do not work well with it.
• The quality assurance for the code being developed is not managed (Erickson, Lyytinen & Siau, 2005).
• System design is primarily considered as secondary here and the development code is offered main preference. This results in issues when the product is launched in terms of user experience levels.

The 2 methodologies mentioned earlier XP (Extreme Programming) and SCUM have been detailed earlier. They both have certain pros and cons. However, it has to be analysed that which one of them are more suitable for the OJL’s system development needs. The drawbacks of SCRUM do not much affect the OJL case. On top of this, the advantages provided by SCRUM does affect the OJL’s case in a positive way. Whereas on the other hand, the drawbacks of XP does affect significantly to the OJL’s case. This is because, for such a complex project, there would be various teams working remotely on the project. At the same time, there would be off-shore developers and contractual workers who may not visit the premises for working on the project. Given the drawbacks of XP in case of remote employees, it becomes difficult to recommend this methodology. On top of this, the project requires a simplified user interface and design logic to contribute towards a good user experience. XP also lacks in this area and this would negatively affect the outcome of the project (Sobiech, Eilerman & Rausch, 2016). SCRUM also provides the principles of adaptability which would be quite helpful in this case.

Event	Type of the event	Event Trigger	Origin	Use Case	Output	Destination
Adding a customer	Internal	Renting a skilled labour or vehicle	By customer	Registration of customer	Details of customer added	OJL and customer
Adding contracting staff	Internal	Adding contracting staff	The staff itself	Addition of the said contracting staff	The staff is added	OJL and Skilled labour
Adding a new vehicle	Internal	A new vehicle	Vehicle	Vehicle addition	The vehicle is added	OJL and vehicle
Renting by customer	Internal	Renting of a vehicle	Customer	Placing of a job	New job created	OJL and Customer
Hiring a skilled labour by customer	Internal	Hiring of a labourer	Customer	Placing of a job	New job created	Job, Customer and OJL
Allocating tasks to workers	Internal	Creation of job	OJL	Assigning of either vehicle or labour	Either a vehicle or labour being assigned	OJL and Job
Creation of an invoice	Internal	Job invoice upon completion	OJL	Creation of invoice	Creation of invoice	Invoice and OJL

 Use Case

	Creation of job
Scenario	Creation of a new job
Triggering Event	Hiring of a new vehicle or a labour
Description	Customer can create a new job in OJL system
Actors	Customer
Related Use Case	“Assigning of either a vehicle or a laborer”
Stakeholders	1. Customer
Pre-Condition	Successful registration and log-in
Post-Condition	Job creation by the customer.
Flow of activities
Actor	System
1) ‘Add Job’ button clicked by customer. 3) Details entered by the customer 6) Staff opens ‘Pending task list’ 7) Staff selects an appropriate resource and assigns to it.	2) System returns with the following details: Job end date, number of jobs available, fields of job etc. 4) Displaying of the reference identification for the respective order 5) Automated notification sent to the staff 8) Automated notification sent to the customer
Alternate Course of Action	3.1 Incorrect data submission results in an error.

References

Adi, P. (2015). Scrum Method Implementation in a Software Development Project Management. International Journal Of Advanced Computer Science And Applications, 6(9). doi: 10.14569/ijacsa.2015.060927

Carvalho, B., & Mello, C. (2011). Scrum agile product development method – literature review, analysis and classification. Product Management & Development, 9(1), 39-49. doi: 10.4322/pmd.2011.005

Erickson, J., Lyytinen, K., & Siau, K. (2005). Agile Modeling, Agile Software Development, and Extreme Programming. Journal Of Database Management, 16(4), 88-100. doi: 10.4018/jdm.2005100105 

Mahnic, V. (2012). A Capstone Course on Agile Software Development Using Scrum. IEEE Transactions On Education, 55(1), 99-106. doi: 10.1109/te.2011.2142311

Rajasekaran, V. (2015). Issues in Scrum Agile Development Principles and Practices in software development. Indian Journal Of Science And Technology, 8(35). doi: 10.17485/ijst/2015/v8i35/79037