Two of the most well known agile methodologies are XP (extreme programming) and scrum. Both of these practices have similarities and differences. As agile software development techniques, they have same characteristics which are relatively short development time and consist of several iterations. In this blog, the explanation of both practices will be discussed as well as the strengths and weaknesses of each method.
XP which is also known as extreme programming is an agile software development approach which consists of several practices and values. Many articles stressed the values of communication, simplicity, feedback, and courage in XP. Communication value is where team member uses verbal communication to other team member over formal written document. The team members in XP project includes developers and customer representatives who should understand the domain and know what is needed. XP also emphasize simple design and solution to fulfill customer requirements. In development process, feedback from customer, system testing, and other team members are important. XP also encourage the developers to write code only for current requirements in pair and do code refactoring if needed in the future.
People often think that scrum is same with XP. Scrum is a subset of agile software development techniques. It is an iterative process to develop or manage certain project and it will produce shippable product which can be presented to the customer at the end of iteration. Unlike XP, scrum emphasizes the management side of a project and does not define a detail engineering practice. Iteration in scrum is called sprint which will deal with certain features defined by customer in a backlog. After the team chooses the most risky feature in backlog they will develop it. A sprint usually takes thirty days and can be decreased to one week if the system is simple and easy to develop. During a sprint, team will have a meeting each day to discuss what has been done, what the obstacles are, and what will be done.
XP specify the software engineering practices such as test-driven development, refactoring, pair programming, simple design, etc. On the other hand, scrum focuses on the management side which quite general so that it can be implemented on other project beyond software development project. For example, scrum does not specify pair programming or test driven development, but it specify how we manage the requirements or requested features. Scrum can be seen as a wrapper for existing engineering practices. Scrum requires self organizing team which cannot be disturbed by requirement changes once they started the sprint. If the customer wants to change the feature, they have to wait until the iteration finished and then introduce the change. In contrast, extreme programming is more acceptable to change during iteration which usually only last for two weeks.
XP and scrum has subtle different. They emphasize on different side of a software development project. It will be great if we can combine both of them to manage our agile software project.
Pair programming has become popular word among software developers recently. As the name suggests, pair programming is a software development activity (writing code) which is done by two programmers. There will be only one of them writes the code and the other programmer thinks whether the code written satisfy their goals. The idea is similar with rallying where in one car there are two people. They are the driver and co-driver. The driver will drive the car and the co-driver will guide the driver to drive accurately.
Pair programming is a programming technique adopted by extreme programming or any agile software development methodologies. Some people argue that this method is a good practice. On the other hand, there are many people say that it is sorrowful. In this blog, the benefits and drawbacks of pair programming will be analyzed, to understand whether pair programming is painful or not.
Some benefits of pair programming are efficiency and increase in performance. In term of efficiency, we can cut the number of workstations as well as software licenses since we need only one workstation every two developers. However, the main advantage that people looking for in this programming approach is an improvement in developer performance. This includes an increase on the number of line of codes and reduced number of bugs or defects in the written code. This can be achieved, because one of the programmers can concentrate to write the code and another one analyzes the code which is written on the screen. If there is something wrong with the code, there is a big chance that it will be spotted during the development phase.
Although pair programming promises wonderful benefits for developers, it has some drawbacks. I believe most people will feel awkward, if they are watched by someone else when they are working. That is why we can find cubicles in many working places. Some people find that it is hard to work under tight supervision. The other problem is every human has their own style and way of thinking. This is also applied in coding style and logical flow within our source code. In my opinion, it is difficult to understand other programmer’s code or adopt their styles, especially if there is a big different in the experience and programming skills.
All of the drawbacks of pair programming are most likely caused by unmatched programmer being paired. I believe this can be solved if both programmer can get a long together and have the same level of programming skills. It will be better if both programmers come from the same programming language background since there is a big probability they will have same programming styles. It is not an easy task to pair up developers in a project.
Is pair programming painful? This issue is debatable since there are advantages and disadvantages. However personally, I would say that pair programming is not painful. There are some precautions that we can do to minimize or eliminate the pains in this programming approach.
User story is one of the ways to communicate software requirements from user to the developers. User story is used for requirement gathering in agile software development project such as extreme programming. In general user story is a short goal oriented story on how a user will perform certain tasks with the system. Commonly, a user story contains the context of certain task, condition which triggers this user story, and script which illustrate how user do the tasks on step by step basis. User story should be flexible and free from any decision making such as user interface design choice. This user story will act as an agreement between the user and developers on the software being developed.
User story is a simple way to express the behavior or characteristics that user needs. It hides all of the complexity and focus on how a certain task can be performed. User story looks fit into agile software development practices. That is why it is used to specify requirements in extreme programming. However, user story is not a perfect tool. It has some limitations. This blog will discuss what the limitations are and show any solution to minimize the constraints.
One of the main limitations of user story is that it opens for many interpretations. User story is simple and contains scripts which focused on a functional goal. It does not state the detail of the user interaction with the system. Our customer may have different understanding with the team. As a result, it is hard to use user story to act as an agreement between the user and developers. That is why it is suggested that the customer or end user is part of the team, so that we can communicate and clear any doubts through face to face communication.
For example, if we have user story on a manager who want to send out a survey to his staff. The first story or first action in the script will be the manager would select the option to survey staff. One developer might implement this user story with a button to choose the survey staff, and other developers might use drop down list. As we can see that user story is straightforward, plain and free from any design (decision making). It will focus on capturing user requirements and try to be free from any user interface design, so that it can be implemented in many ways. We can solve this problem by discussing the design with other developers and sketching user interface design before we implement a user story.
The simplicity of a user story also causes another limitation. It lost the performance requirement detail. Often, user story which becomes the basis of user acceptance test will only test the business logic of our application. It will not test the performance or our database layer such as database response time. To overcome this limitation, developers or testers need to pay attention to other documents such as product attributes and system constraints when building the test case. Therefore, developers and users have to develop these documents carefully as it will accompany the user stories.
Agile software development project is a conceptual framework in software engineering where software is built within a relatively short period of time and has several iterations which yield stable release of software. Iteration usually takes one to four weeks and it depends on the type of the project. At the end of the iteration, we will have fully tested and working product. One of the key concepts in agile development is face to face communication to speed up the software development. Unlike communication over written documents which take ages to write and most of the time no one will read most of these documents.
As we know, agile project is done in relatively short period of time compared to other software development methodologies. To achieve the agility in a project, many articles, books, and agile practitioners suggest small team with consists of around seven people. There are also many recommendations on the mixture of skills within an agile team. Many people always try to tweak their agile team configuration, so that they can get the best outcome. This blog will discuss the optimal team size and composition in agile projects.
Generally, most of us will agree that more people equals to more productivity. Similarly, business people or our customers often ask us to add more people to increase the velocity of our software development project. Increasing the number of people in a software development will increase our performance, but at some point it will degrades our team because we need more coordination and communication to integrate many people. In agile projects, we always emphasize face to face communication and we often do standup meetings. In my opinion, small team which consists of seven people will perfectly match these concepts. Several developers might argue that we can still do agile project with big number of people, by dividing them into smaller self-managed team. However, I do not agree with this statement, as you are still required to integrate the work between teams and it is still difficult to communicate between small teams.
In term of team composition, a mixture of people with different set of software development skills is the best option. The reason behind this is an agile team should be self contained and self managed. The team also needs to do the entire software development iteration. The team should not ask for help from external resources or get any intervention from outside. Therefore it is good to have mixture of skills (analysts, developers, management, testers) within a team. Another issue in this area is the developer’s level of skill. Can we combine beginner with expert and experienced developers? Personally I prefer agile team which consists of expert or experienced developers only, because we do not need to educate other team member. In addition, agile team needs to take decisions fast which are possible if the team members have already had experiences in software development before.