INTRODUCTION:

The reason of approaches to management of system development is the improvement of the productivity of the company and the people working in that company, as system development got larger there was a need to systemize the process of system development and introduce a set of steps that are need to be taken for any system development.

The SDLC (System Development Life Cycle) is a common approach used in all most every organization, as the system development projects got larger and the discipline of software engineering begun to set some standards of its own a lot of approaches have seen introduced and were put together by organizations looking for success according to their own degree of success.

Before I explain further details about some system development approaches, I would like to mention a basic definition of a system development approach. That is “a standard process followed by an organization to conduct all the steps necessary to analyze, design, implement, and maintain information systems” [1]

The above definition does not bring up the cause why the organizations want to follow these steps in system development, but it looks very clear that one of the targets is to facilitate tracking problems whenever that problem occur, and develop a better and successful system.

There are number of commonly used approaches to management of system development in Software engineering world. Some of them are PRINCE2, SSADM, XP, SCRUM and Crystal Clear etc. In this report we are aiming to take an in depth look at SCRUM and XP. And also tried to discuss it with project management perspective by discussing Risks, Integration, Scope, cost, time, quality etc.

SCRUM:

The term scrum originally derives from a strategy in the game of rugby where it denotes “getting an out of play ball back into the game” with teamwork [5]

SRCUM is an agile approach for software system development. This is not a full methodology or process, it is just a framework which does not provide the detailed and complete description of the steps how everything is going to be done and who is going to do what but most of the things are left on the team. This is done because the team will know how the their problems will be solved.

 

Pre-game phase:

It include two sub phases: planning and Architecture. Planning includes the definition of the system being developed. Take the requirements from customer and put it in Backlog List. Now the requirements are prioritized and estimate the effort need to implement it.  Backlog is reviewed by scrum team.

Planning also includes tools and resource allocation, risk assessment and controlling issues and training needs.

On the basis of product Backlog the high level design including the architecture of the system is planned.

 

Development Phase:

The system is developed in sprint, sprints are iterative cycles for functionality development which produces new increments. In each sprint we go through the traditional development life cycle i.e. requirement gathering, analysis, design, development and testing. The duration of one sprint vary from one week to one month.

 

Post game phase:

This phase include integration of increments, system testing and documentation.

 

 

 

Roles and responsibilities in Scrum

The roles in scrum are given below:

1-      Scrum Master

It is a management role introduced by scrum and is responsible for ensuring that the project is going according to the practices and rules of scrum. Also tries to improve productivity and performance of team. During project it interact with customer, scrum team and management of the project.

 

2-      Product Owner

It is selected by scrum master with the help of customer and management. He is responsible for project management and control. Also makes the decisions on product Backlog and this is usually considered as final decision.

3-      Scrum Team

This is the development team work to achieve the goals of each sprint.

4-      Customer

It participates in making of product backlog.

5-      Management

Management makes the final decision for the project. Decides standards and conventions to be followed in the project and sets the goal. It also involve in chosing the product owner, review the progress and helps the scrum master to manage the Backlog.

 

Adaptation and experiences

It can be adopt in any organization as it does not follow any specific engineering practice. It also changes the role of the manager and make it a coach as the project manager which is called Scrum Master here, cannot organize the team but the team makes decision by themselves. This can be Called a self organizing tam [5]. Scrum master also helps the management to make decision in scrum meetings

 

It can be adopted in existing projects where team is struggling with problems related to changing requirements.

It can also be adopted in new projects. First we need to work with customer and team to develop initial Backlog which consists of functionality and technology requirements. Here the goal of sprint is to demonstrate a key functionality of selected technology.

 

As we know that scrum is not for large and complex projects but the small and isolated teams in large projects can use some elements of scrum. This is true process diversity. [6]

 

Scope

It can be used as a project management approach, in a so called “Scrum of Scrum” [3]

Theoretically scrum is always suitable for smaller projects but for large projects team can be divided into sub teams to adopt scrum.

 

Advantages

 

• Scrum can be adopted to manage whatever engineering practices are used in an organization as it does not require any specific engineering practice.
• Scrum can improve the communication across all the teams.
• Problems can be transparent.
• During scrum sprint there is no interference from management or anybody outside, this keeps the scrum team focused and creative. Which is also very good for productivity.
• A flag management structure.
• In each meeting team member respond to few basic questions. What did you do since last meeting? Do you have any problem? What’s next task. Also at the end of each scrum sprint, what has been done so far and what should be done in the next scrum sprint, can be evaluated. This keeps the process flexible and focused.

 

Disadvantages

 

• To develop whole project is discouraged in Scrum methodology as it helps to break the project  into smaller manageable tasks.
• During a scrum sprint, scrum team is  responsible for itself therefore it is important that the management does not interfere with how the work is being done. Therefore the management needs a fully trusted team to do the right things which is hard to find.
• In scrum the project stakeholder (who is paying for project) can see the progress being made every day. They are able to build a relationship with the scrum team and get regular feedback.
• Decision making is entirely in the hands of the teams.
• There has to be constant, hands on management.
• The integration and acceptance test are not detailed.

 

Though it is not perfect methodology but it helps to improve communication between team, maximize efficiency and provide an open approach to tackle with the project.

 

Coupling with other Methodologies

Scrum itself does not tell how to develop a product but it is up to the team. This allows scrum to be couples with other methodologies. It can be coupled with extreme programming and also combination of scrum and crystal clear can also be interesting.

 

XP (EXTREME PROGRAMMING)

This methodology has been formulated by Kent Beck in 1996 and it receive fair media attention. It is mostly renowned for its practices that are sometimes regarded as controversial such as pair programming and test driven development. It presents the approaches, methods and advices you need to plan and track a successful project. It is a agile methodology and the developers can respond to the changing customer requirements even late in the development life cycle. It emphasizes on the customer satisfaction, as it deliver the software as the customer need it.

 

Extreme Programming turns the conventional software process sideways. Rather than planning, analyzing, and designing for the far-flung future, XP programmers do all of these activities a little at a time throughout development. [IEEE Computer October 1999]

 

XP also emphasizes on team work where in which manager, customer and developer collaborate equally. Extreme Programmers constantly communicate with their customers and  fellow programmers. Keep the design simple, get feedback from testing the software at initial development level and try to deliver the system to customer to get feedback on it and implement changes as suggested.

XP is aiming to reduce the risk involved in project e.g. it try to reduce the cost of delaying design decisions.

Traditionally a change in a requirement is very costly because implementing them later on is too costly and possibly cost more than the allocated budget. XP reduces these cost of making modification later on during development.

 

Extreme Programming (XP) is rapidly becoming recognized as an approach particularly well-suited to small teams facing vague or rapidly changing requirements  [2]

 

Planning and working of XP

The purpose of planning is to implement most valuable set of stories to make a first release of the product. This contains the minimum workable functionality. The subsequent releases add more functionality to this release, make changes and fix bugs. XP project normally lasts the entire lifetime of the application by making further changes and updates but it can be end if customer wants to finish this. Typically it takes 2 to 3 months between releases. Each release is further divided into iterations of 1-3 weeks.

In XP the requirements are not fixed in advance. Customer write down the required functionality detail in user story and make sure that he do not miss any functionality in the application. Now the release plan of the project is drawn up. Now the development team will assign a cost for each story written by customer. Cost is the time required to complete the functionality by a single programmer. So if cost is greater we can split up the story but if its small we can merge multiple stories together. And each programmer will deliver the story within the estimated time.

 

Process

Extreme programming is consist of following phases:

1-      Exploration phase

Here customer writes the story cards and each of these describes a specific feature that he wants to include in his program. On the other hand the project team explores the architecture possibilities by developing a prototype. Decides tools, technology and practices to be used in the project.

2-      Planning phase

It sets the priority for each story. The programmer estimate the time and effort need to develop and suggest the schedule for each story. This phase also agreed upon the content of first small release and its schedule, first release doesn’t exceed more than two months normally.

3-      Iterations to release Phase

The schedule set in planning phase is broken down into number of iterations and each of them will take one to four weeks to implement. The customer will decide the story for next iteration of development and he will test the functionality after every iteration. After last iteration the project is ready for production.

4-      Productionizing phase

Before releasing the final product to the customer this phase require extra testing and checks the performance of the system. Any change found in this phase can also be implemented before the release. Suggestion and ideas can be documented for future.

After the first release is handed over to customer the development team moves on to the next iteration.

5-      Maintenance Phase

This phase provide support for customer.

6-      Death Phase

It is near when customer doesn’t have any stories to be implemented. This phase tries to satisfy customer in every aspect.

Here some necessary documentation is also written as there are no more changes left in the system.

It also finds any difficulty in the system or it becomes too expensive for further development or its not delivering on time.

 

Roles and responsibilities in XP

XP has different roles for different tasks and these are:

1. 1.      Programmer

Programmer is the heart of xp and it writes the test and implement the tasks.

XP programmer need to learn pair programming skills

1. 2.      Customer

Customer is the source of requirements. They write the stories and tests and also prioritize the stories

1. 3.      Tester

They help the customer to develop functional test. They also runs test and identify its results.

1. 4.      Tracker

Tracker give feedback on estimates made by team to improve it for future. Also evaluates its feasibility.

1. 5.      Coach

As coach, you are more responsible for the process as a whole. They are more concerned with the technical execution of the process.

Though everyone in xp team is responsible for understanding the application of xp to some extent but the coach is responsible for understanding it much more deeply. So that he can suggest any alternative  practice for any problem.

1. 6.      Consultant

This is an external person who guides team in solving specific problems.

1. 7.      Manager

Manager must have courage and confidence.

Manager communicate with project team, determine their current situation and difficulties in the process and makes the decision.

 

 

 

Adaptation and experiences

If you want to try XP, for goodness sake don’t try to swallow it all at once. Pick the worst problem in your current process and try solving it the XP way[8].

The idea of extreme programming is that there is no process that fits every project as such but you can alter the practices to make it suitable to your project.

XP is a good choice when customer does not know what exactly he wants or he is unclear about his requirement. Because in xp product development is divided into small cycles and each of them is planned separately.

Adopting xp with an existing team and code base is harder than adopting it with the new team. Because in existing project you need to learn about the practice, skills, coaching and complexity.

XP is for small to medium teams therefore the size of team is very important.

 

Cost

Here are some factors that can affect not only the cost of the project but also the time and scope:

1-      Human resource, one of the most powerful factor.

2-      Communication, if you double your team it does not make your performance twice but it increase the communication overhead.

3-      Tools,  If you spent money on new tools than people need time to learn these tools which slow down the process again. But sometimes it is good to spend on tools as faster computers, biggest monitors etc. This will keep the staff motivation up and they can work more effectively.

4-      Overtime, even if the programmer wants to work overtime it is not good because long hour make them tired and tired people make mistakes and mistakes take time to fix.

 

 

Quality

 

There are two levels of quality, internal and external quality. External quality is related to customer in which he suggest the GUI looks and speed etc.

But in internal quality reflects the internal system quality and XP emphasize very much it. If you allow this to drop may be for a while your development speed may increase but this poor quality will kill the speed very soon. That is why XP puts so much attention on practices like testing and refactoring.

 

Scope

XP is aimed for small to medium sized team with a size limit of three to twenty members. And the communication and coordination between team member should be enabled all the time.

The technology that doesn’t support graceful change or demand long feedback time is not suitable in XP projects.

 

Advantages

• XP aims to reduce the risks involved in the project
• XP is able to flexibly schedule the implementation of functionality and can respond to changing business needs.
• XP can get early, concrete and continues feedback from short cycles.
• It eliminates in creating lengthy requirements definition
• It deliver code more quickly to user with few bugs.
• Constant communication with the client.
• A usable product can be released very quickly. Customer can use it to take business advantages. Get feedback from the customer on the product, these feedback are very valuable as they get by live use.  This process will definitely help to improve the product but it also helps the customer to explore more ideas.
• Additionally, the process is very transparent. Progress, position and direction of the project are very transparent, which will make management happy as well.

 

Disadvantages

 

• Management practices are given less attention in XP.
• Almost every project starts from small efforts and then grow beyond their original scope. But once it becomes a large project XP is not more suitable for projects.
• Lack of documentation especially design document which limit it to the small projects only and reusability becomes difficult.
• It doesn’t explicitly plan, measure or manage project quality.
• Not everyone out there is a process expert but XP expect so.
• There may be some personality conflicts while doing pair programming.
• Customer must be an integral part of the development team which is biggest roadblock to implementing XP in any given environment. Means availability of customer on site it very necessary through the project development life cycle. Sometimes it is not feasible for customers. In these circumstances XP will not work properly.
• Lack of transition support.

 

 

 

Comparing it with other methodologies

 

Beck is very liberal about adapting XP. He suggests experimenting with the practices prescribed by XP, then keeping the ones that work, and adjusting or even ditching the ones that don’t.[7]

Beck says that the full value of XP will not come until all the practices are in place. He further explain this by going on theorizing that the maximum benefit of XP can only be achieved by putting all practices into effect. He calls this the 20 –  80 rule: if you do 80% of the work, you will see 20% of the benefit

This suggests that coupling XP with other should be limited to only adding practices to XP, without removing any practice from XP.

 

 

Conclusion

In this document I tried to concisely describe both project management methodologies for development, Scrum and Extreme programming. Both of them are Agile methods and they are based on iterative development. Though it is difficult to compare both of them but I manage to find differences between these two processes and some differences found during my study are:

1-      XP programmers are very friendly with changes but the scrum can’t make changes during sprint.

2-      In XP customer is involved in prioritizing the task and team has to follow it strictly but in Scrum product owner take this decision.

3-      The time required for iterative process is different in both XP and Scrum.

4-      Scrum can be adopted to manage whatever engineering practices are used in an organization but XP is not flexible.

 

 

I also found that software engineering is a young field and project management remains unpredictable discipline despite the considerable number of management methodologies which are available at the moment.