Agile project management with XP Manual

AGILE PROJECT MANAGEMEMENT WITH XP

MANUAL GESTIÓN DE PROYECTOS ÁGILES

INDEX

External P rogramming (XP) ........................................................................................................... 3 1. Where does XP come from? ................................................... .............................................. 3 2. TheXP Target ...................................................................................... ..... .............................. 5 3. Agile methodologies and XP ................................................................................................ 6 4. The values of XP ................................................................................................................... 7 5. RolesinXP ................................................................................ ....... ..................................... . 11 6. The principles of XP ............................................................................................................. . 17 7. Good technical practices in XP ........................................... ........ ......................................... 21

2

European Open Business School

MANUAL GESTIÓN DE PROYECTOS ÁGILES

Agile Project Management with External Programming (XP)

1. Where does XP come from?

Agile methodologies are used to carry out many projects, both development and other types of projects of any nature. There are many particularisations of agile principles in the form of concrete methodologies and best practices. Scrum and Kanban are the best known concrete methodologies in the world of software development and technology project management. Scrum can be considered as a set of guidelines and best practices to coordinate the work of all team members. Development based on iterations, planning for each sprint, involving the client, short but frequent meetings, etc., are aspects of project management and coordination. Experience has shown that applying these good practices favours the successful development of projects. As you may have already noticed, in the Scrum methodology there is practically no mention of software development. It talks about building a product that has to fulfil a set of properties requested by the customer. However, this product does not necessarily have to be a software product. For example, agile methodologies have been successfully applied in the collaborative development of books. In general, when the product to be developed is eminently intellectual, and cannot be precisely defined "a priori", an agile methodology such as scrum can be applied. This is because scrum puts the emphasis on coordination, decision- making, definition during the creation process, etc. Although they can be applied in certain projects, it is true that they have had their maximum expression in software development. However, agile methodologies such as Scrum or Kanban make virtually no mention of the technical issues involved in software development. And that is precisely the gap that extreme programming occupies. To understand extreme programming, you need to know the history of how it was developed. In the 1980s, programmer Kent Beck began working with SmallTalk, an object- oriented language, which was born with the aim of bringing the human reasoning process closer to the reasoning process used in software development, with the goal of making software easier to create and maintain. Kent Beck and his collaborator, Ward Cunningham, began testing various practices in software development with the SmallTalk language. Some of these, which we will discuss in detail later on were continuous integration, refactoring of European Open Business School

3

MANUAL GESTIÓN DE PROYECTOS ÁGILES

code, etc. , la refactorización del código, etc. In addition, it also started to use management practices such as keeping the customer close and developing in small increments. In 1996 he published "Smalltalk, best practices patterns", in which he described these best practices. Kent Beck started working at Chrysler in 1996 as a software project leader and refined these best practices in software development that allowed him to develop software in a continuous and quality way. In 1999 he published the book "Extreme Programming Explained" explaining these practices in detail. The name is based on the idea that if a development practice is useful, it must be taken to the extreme in order to exploit it to its full potential. Later, in 2001, Kent Beck signed the Agile Manifesto, along with other members of the newly formed agile community. Kent Beck currently works at Facebook and continues to publish and work in the world of software patterns. In 2008 he published "Implementions Patterns", a reference in the world of software development.

4

European Open Business School

MANUAL GESTIÓN DE PROYECTOS ÁGILES

2. The XP target

As mentioned before, extreme programming is an agile methodology that aims to enable a development team to create high quality software in the most productive way possible and to meet the wishes of customers. In order to meet these objectives, extreme programming proposes a series of recommendations in the form of technical best practices for the development team. But these good practices are not enough on their own, they have to be understood under a set of values and principles that allow the team to behave as a unit with a common goal.

5

European Open Business School

MANUAL GESTIÓN DE PROYECTOS ÁGILES

3. Metodologías ágiles y XP

Agile methodologies such as Scrum and Kanban, and Extreme Programming, have developed independently. Scrum and Kanban focus more on management, while Extreme Programming focuses on the development team and the technical best practices needed to create quality software. Although developed independently, there are some points where these methodologies overlap and propose the same techniques to solve the same problems. For example: • Both scrum and XP recommend development in short iterations and frequent deliveries, rather than long development processes. Scrum goes into a little more detail on how these iterations can be done from a management point of view (daily meetings, sprint planning meetings, retrospective meetings, etc.) and extreme programming proposes the software techniques to make this easy for the development team to do. • Scrum encourages the customer (represented by the product owner) to change their mind or refine the product requirements as development progresses, and extreme programming proposes the best technical practices so that this can be done without compromising the quality of the product and without jeopardising the completion of the project. • But, above all, there is one aspect in which extreme programming and methodologies such as scrum coincide and which is included in one of the values of the Agile manifesto: "Individuals and interactions over processes and tools". This is a way of saying that the importance lies in people and the way they relate to each other. Although extreme programming is a compendium of technical best practices, we will see how the team (people and their interactions) are at the heart of most of these best practices.

6

European Open Business School

MANUAL GESTIÓN DE PROYECTOS ÁGILES

4. XP values

The values underpinning Extreme Programming are:

Communication

The first value of Extreme Programming is communication. In order for developers to build a product that meets the needs or wants of a customer, there has to be communication between the customer and the developers. In non- agile methodologies, it is considered that this communication has to be done through contracts and documents. In extreme programming, it is considered that this communication has to take place in the most direct way possible, allowing for conversation and even negotiation. In addition, many of the technical best practices allow for communication within the development team itself and with clients. Everyone involved in a project needs to have a clear understanding of the project's objectives, so that all their actions are directed towards achieving those objectives. For example, frequent deliveries of working software have proven to be one of the best forms of communication between the team and the customer. Joint cost estimation by all team members, pair programming and the concept that all code belongs to everyone encourage communication between team members. Simplicity This concept is closely related to the type of software being developed. Experience has shown that sometimes software systems are implemented in such a way that they are prepared for things that never happen and that has a lot of cost and little value. It is like the lean startup methodology, but applied to software development. Try to consume the minimum resources necessary to get a functionality out, but don't think about what you will need tomorrow or in a month's time, think about the current needs and reduce the cost of carrying them out. For example, let's say we want to get started in the world of skiing. We can buy some fairly basic ski equipment, or even rent it, with the idea of trying it out. So that, if we finally like it, we can buy other, better equipment.

7

European Open Business School

MANUAL GESTIÓN DE PROYECTOS ÁGILES

In the world of software development, simplicity suggests to developers not to think of complex designs for future functionality to be implemented. This is known as over-design. Extreme programming tells you to program just for what you need today, but no more. This has the advantage that discussions with the client are much more focused, there is no future guesswork. Also the code is usually easier and quicker to implement and test. This means that the customer can have that functionality much earlier and can provide feedback. Anglo-Saxons have many acronyms related to this value. KISS is the acronym for "Keep it simple, stupid" which can be translated as "Keep it simple, stupid". They also use the acronym YAGNI, the acronym for "You aren't gonna need it", which can be translated as "You won't need it". Extreme programming believes that if you don't over-design and focus on what is immediately important, you don't run the risk of spending your efforts on doing something that you probably won't need because, although it seems very obvious to you now that you will need it, the client's needs may have changed by the time you get there. And the last one, BDUF, which stands for "Big design up front", refers to the extreme case of completely defining the software architecture before you start programming. These ideas are applied in other engineering disciplines (e.g. construction), but have proven to be very unsuitable for software development, being mainly used in waterfall development. Simpler code is easier to understand (it favours communication, the first value of extreme programming). And if a code is easy to understand, it is also easier to maintain and, therefore, to adapt to the (changing) needs of the client. There are developers who take this principle to the letter and only program what is strictly necessary for the current iteration. But there are other developers who carefully evaluate each case and decide to use more resources in the current iteration so that the incorporation of future functionalities can be done in a very simple way, even if this implies a higher initial implementation cost. As this is quite an important issue in software development, we will come back to it later.

Feedback In the context of extreme programming, feedback is associated with the ability to measure different aspects of software development. In particular, it is often applied to the following aspects:

• System feedback: thanks to automated tests, the system is able to generate an automatic report on its internal status. This is why test programming is so important for the development of quality software.

8

European Open Business School

MANUAL GESTIÓN DE PROYECTOS ÁGILES

automated .

• Customer feedback: Frequent deliveries of working software allow the customer to evaluate the software as it is being developed. This is an important tool to verify that the project is moving in the right direction. And to react if this is not the case. In addition, it is recommended that the customer actively collaborates in the creation of acceptance tests, tests that automatically validate that the desired functionality is actually implemented.

• Feedback from the team: if the client wants to incorporate functionalities not foreseen in the product, the team will be able to estimate the cost of implementing these features, providing the necessary information to the client to make the decision on whether or not to include this functionality

Obviously, feedback is closely related to communication. But feedback focuses not on the simple transmission of information, but on the measurement, the validation that the data obtained are aligned with the objectives of the project.

Courage Developers must be courageous during the development of a project at the right times and in the right situations. For example: • When problems of coordination or miscommunication are detected, any member of the team must be courageous enough to bring the problems to the table before they escalate and become more difficult to solve. • Programmers must have the courage to own up to any mistakes that are made and, if necessary, ask for help to fix them. • Developers have to stand up for their convictions and negotiate even with other team members if they disagree on something. Compromise should be sought whenever possible for the good of the team, and that takes courage. • Another example of courage and responsibility is to recognise when you are wrong and to give up. For example, discarding a technology if it is accepted by all that it no longer meets the objectives, no matter how much work was invested in it.

In addition, you also have to have the courage to take risks. The Spanish proverb is clear: "he who does not risk, does not win". If a developer believes in an idea, he has to defend it, convince the team and take risks for it.

9

European Open Business School

MANUAL GESTIÓN DE PROYECTOS ÁGILES

Respect Respect is the fifth XP value, which was incorporated in the second edition of the book "Extreme Programming Explained" (2004). The rest of the team members deserve respect. A new colleague with little experience deserves the same respect as an experienced programmer. Respect manifests itself in many ways during the development of a software product. Some examples are shown below: • Since all code belongs to everyone, you have to make an extra effort to make the best code you can make. When you code for yourself, you can take a lot of "license" and do things quickly and without thinking about future maintenance. But when your code is really everyone's code, out of respect for them, you should take the utmost care of its quality. • If your code causes several tests to stop working, out of respect for other members, you should fix the problems as soon as possible. Because tests that don't work are invalidating everyone's work. • If a team member is inexperienced, respect their desire to learn and improve and make an effort to help and teach them as much as possible. Criticism should always be constructive and focused on improvement, not destructive criticism.

10

European Open Business School

MANUAL GESTIÓN DE PROYECTOS ÁGILES

5. Roles in XP

Nowadays, many software development projects are carried out using both Scrum and extreme programming. Management issues such as meetings, deadlines, deliveries, task selection, etc., are defined within the scrum methodology and the technical practices applied by the development team to ensure that the software developed is of high quality and prepared for the adaptations requested by the client are included in extreme programming. In fact, there are many books that present both methodologies together, one of the most famous being "Scrum and XP from the Trenches", by Henrik Kniberg. It can be found for free on the web and translated into Spanish. In software development there are mainly three actors involved: • Clients/Users: they are the ones who need the application to be created. They will have to learn how to communicate with the team, to get their ideas across. The team will help you in this change of mentality to get the product on time. • Managers: are those who control the project's resources. They will learn how to measure the progress of the project, the quality of the product and how to answer important questions. It is very important that they learn to trust the development team's own self-management. • Programmers: are those within an XP project who define the architecture, design the system, write the tests and code. They will learn how to deal with changing requirements, with the customer and most importantly how to develop what is needed today without thinking about future needs.

Customers, programmers and managers will all work together to build what the system needs.

The team in XP A process can improve the productivity of a team, but only for that small part of the whole process; a team that works efficiently "as a unit" can improve productivity at every stage of software development, but this is often not the case. There are not that many teams that work together as a unit, as if they were one person. In the world of software development there are many egos (or "rock stars") who prefer to work alone and not share their knowledge.

This is one of the aspects that Extreme Programming aims to change. It is necessary for all developers to collaborate together, as a real team, in order to

11

European Open Business School

MANUAL GESTIÓN DE PROYECTOS ÁGILES

create the best product they have ever dreamed of. Motivation and shared purpose is also one of the aspects that are encouraged. XP is a simple process that puts people to work together to achieve successful applications. XP can be used in distributed teams as well as in teams working within the same company in a common office. The main characteristic they will all have is that they want to create quality software in a fast and flexible way. The customer/user As in Scrum, in XP the customer becomes a member of the team. The usual way of working, before the popularisation of agile methodologies, was to talk to the client when the project was almost at the end and check if everything was correct. Then the client could be faced with unpleasant surprises. On the other hand, if the customer works actively with the development team, he or she can narrow down the problems, offer solutions and even learn new things about the problem. It is always an expert in the problem domain who finds the best and most elegant solutions. In the Scrum methodology, the customer is represented in the team as the Product Owner. The manager Depending on the development methodology we are using in the project, the manager is called by different names and can assume different roles. In the Scrum methodology, the Scrum Master is the figure with the greatest management burden. Although in this methodology the development team is self-managed and its tasks are far from the traditional "command and control" manager, who plans tasks for his subordinates. Generally speaking, the manager does not develop the product, but rather facilitates the context in which the development team develops the product, e.g. by removing impediments. The most important task of a manager is to make sure that everyone can do the work that needs to be done. The programmer analyses, designs, tests the software and integrates it into the system. He/she also estimates the cost of implementing each story and when finally implemented, its speed can be measured. For a developer, the most important thing is to correctly understand the functionality that is described in the user story. If in doubt, the client should be accessible to engage in a conversation to understand the functionality, its motivation, and the mechanism the client will use to verify that the story has been implemented correctly. In addition, the customer should see the following as soon as possible European Open Business School The Programmer

12

MANUAL GESTIÓN DE PROYECTOS ÁGILES

the implemented functionality, so that he can give feedback to the developers if they have not understood correctly what he wanted. It may also happen that the customer wants to refine the functionality once he has started using it or even change his mind completely. So far, it may seem that extreme programming is a compendium of principles that are present in the agile methodologies we already know. But this is where the significant contribution of Extreme Programming begins. XP describes and recommends a set of best practices for the development team to "program well" and therefore produce "quality software". There are many techniques for determining the quality of a software product. Some are more quantitative (e.g. measuring the percentage of duplicate code), and others are more qualitative (e.g. reviewing the code among team members). There are some techniques that focus on more technological aspects (software architecture, design patterns...) to measure quality. Other techniques measure quality in terms of customer satisfaction, compliance with deadlines, etc. We will go into detail on these aspects later, but at this point, we can consider a software to have been developed "well", i.e. to be of quality, if it meets the following criteria: • The product is free from defects, i.e. it does not fail. • The product does what the customer expects it to do . • The product can be maintained, i.e. functionalities can be added and it can be adapted to new platforms or environments at acceptable costs. • The product is developed in a predictable timeframe. • XP is a methodology that focuses especially on describing the good practices that the development team should follow to produce quality software. Although it mentions some aspects related to project management, other methodologies such as scrum are more developed. In this sense it can be said that XP is mainly focused on software developers. • This methodology is called extreme programming because when it was proposed, its best practices were a way of taking to the extreme tasks that developers were already doing, but on a much less frequent basis. • If reviewing the code is good, then we take it to the extreme and the code will be reviewed by another partner when it is being created. In other words, the code will be programmed and reviewed all the time and in pairs. (Pair programming) . • If the tests are good because they automatically tell if the software does what it is supposed to do and without defects, then everyone involved in the project will perform tests, including the customers. (Unit, integration and acceptance tests). Also, if running tests gives me confidence that everything works, let's run tests at every code change (continuous integration). • If well-designed code is important, then let's design every day and change our code so that it always has a good design (Refactor). • If simple is best, it will always try to be developed in the simplest way possible

13

European Open Business School

MANUAL GESTIÓN DE PROYECTOS ÁGILES

possible to implement the functionality and bring value to the customer, even if that means having to redesign. (Make the current work as simple as possible). • If short iterations are good, short iterations of days or weeks will be done. (Re-planning and retrospectives).

We will elaborate much more on XP best practices later, but here are some of the most important ones in summary form:

Tests, tests and more tests Automated testing is one of the most important aspects to ensure that the code developed is of high quality, i.e. free of errors (internal quality) and behaves as the user wants it to (external quality). In addition, testing is critical when incorporating new features into a product, because it greatly reduces the risk that something will stop working when we add a new feature. In reality, a test does not prevent an error from being introduced when changing the code, but when running the test we will see that it fails when something that was working stops working. In this sense, there are also customer-oriented tests, called acceptance tests. These tests are the mechanism by which the customer is sure that the system behaves as he wants it to, and continues to do so when new functionalities are added. Automated tests are also applied in other sectors such as chair manufacturers. In this case, it is tested for resistance to use, in the software, it is tested that the system does not break down when new functionalities are added. " Deliverable" code Code should always be ready to package a product and deliver it to the customer (or at least at the end of each iteration). It has been empirically proven that, if this is done, project risk is greatly reduced and the development team and the customer are better able to adapt to change. To ensure that the team can deliver the product at virtually any time, techniques such as continuous integration and continuous deployment are used, which basically consist of automatically executing all the steps that make the software deliverable from source code. In addition, during the process of "building" the software, all the tests that exist up to that moment are executed, so that it is possible to verify that everything continues to work as before. All this will be explained in detail in the next class.

14

European Open Business School

MANUAL GESTIÓN DE PROYECTOS ÁGILES

All code belongs to everyone

One of the secrets of a successful project is that the team is united in achieving the project's objectives. When the team is a group of developers who have to produce a software product, this means that all the code belongs to everyone, regardless of who wrote each line. In other words, there is no ownership of the code. To achieve this, code reviews are usually done from one developer to another, and developers are involved in various parts of the code throughout the project. This allows all code to be considered as owned by all developers. This also encourages collaboration between team members, with the more technically skilled team members teaching the novice team members the best techniques. At the end of the day, all developers should feel comfortable with all the code, as if they wrote it themselves.

Simple design and quality code

The code should have a simple design, which is sufficient for the functionality being provided up to that point. Oversized and ultra-flexible code is discouraged, as this can make it more complex than necessary, which ultimately makes it difficult to create and maintain. In addition, it must meet quality criteria, among others: no repetitive code, simple, easy to understand once written, behaves as expected, etc. In order to achieve code quality, a technique called "refactoring" is continuously applied, which consists of actually making changes to the code in order to improve its quality, but without adding any additional functionality. In addition, continuous analysis techniques are used to measure the quality of the code. One of the most basic and widely used metrics is the one that determines if there is duplicate code.

Pair programming

Programming is a complex task that requires significant intellectual effort. When a programmer starts developing a program, his goal is that the program should behave as he wants it to and that it should do so while taking advantage of the available hardware resources. In addition, he also wants the code to be understandable so that he (or another developer) can extend or improve that code in the future. Obviously, the program has to be free of defects. But achieving a code that meets all these characteristics is not easy. It has been empirically proven that if two developers program the same code on the same PC, the result is a much higher quality code, with fewer defects and much more understandable. There are occasions where the code is quite simple, and pair programming does not add much value and could be considered as European Open Business School

15

MANUAL GESTIÓN DE PROYECTOS ÁGILES

that they are wasting a developer's time, who could be doing something else. But when the code is complex, either because of the complexity of the functionality to be developed or because the technology is unknown, pair programming is highly productive. In this sense, programming is about compromise, because there are forces pulling in opposite directions. Having the possibility of exchanging opinions with another developer greatly improves the quality of the solutions provided.

16

European Open Business School

MANUAL GESTIÓN DE PROYECTOS ÁGILES

6. The XP principles

The values are universal and very generic. Although in the explanations we have introduced specific examples related to programming, in reality we could have used examples from any other context, as communication, simplicity, feedback, courage and respect could be applied in other contexts. To bridge the gap between values and technical best practices, Kent Beck, one of the authors of the XP methodology, decided to indicate a set of Principles. According to him, principles are vital guidelines specific to a particular environment. In other words, values are too abstract to guide behaviour. Principles are a refinement of values, but made concrete for a specific environment. The following principles are defined in XP : 1. Humanity: developers are people and, as such, have personal needs and goals. Extreme programming is aware of this aspect and does not consider people as interchangeable resources. Some XP practices aim to satisfy, as far as possible, the personal needs of each team member in a way that is balanced with the team as a whole. The reasoning behind this approach is very simple, a person will be involved with the team's goals if in some way those goals are aligned with his or her own personal goals. 2. Economics: someone pays the salaries. So all technical work has to be aligned with business objectives. You always try to implement the user stories with the most value to the business as soon as possible. There are two economic issues that affect software development. On the one hand, there is the time value of money, which means that having a euro today is better than having the same euro tomorrow. That is why it is necessary to have software running as soon as possible, even if that software can go into production if the business model deems it appropriate. These kinds of ideas are very much in line with lean startup concepts, where the business model needs to be validated as soon as possible with customers. On the other hand, there is value as a future option. If the software and equipment are flexible and adaptable to change, they will have much more value than if they are fixed and rigid. The technical practices being proposed have economics at the forefront of their minds. 3. Mutual benefit: Tasks have to be of benefit to the one who performs them and to the one who benefits from them. If this is not the case, these tasks will end up being performed with less care because they do not bring direct value to the performer. The most representative case is the case of European Open Business School

17

MANUAL GESTIÓN DE PROYECTOS ÁGILES

writing extensive documentation that explains in detail the behaviour of a system. Writing the documentation does not bring any concrete value to the writer, because all the value will be obtained by the one who consults the documentation in the future. In XP, detailed documentation is replaced by a set of practices that bring a lot of value to the practitioner and offer even more value than documentation to the one who receives the results in the future. In particular, XP encourages the writing of automated tests, continuous design improvement and the selection of self-explanatory code names. All of these techniques bring a lot of value to the user, because they facilitate the understanding and maintainability of the code today.

4. Self-similarity: try to apply things that work in other contexts and at different scales, because they can work as well. This applies especially to testing. You can implement tests on a daily basis on internal application modules (unit tests). But you can also implement integration and acceptance tests once a week to verify that the integration of the module and the whole system works as expected.

5. Continuous improvement: in software development nothing is perfect, but everything is "perfectible". "Perfect is the enemy of good" suggests that something reasonable now is much better than something perfect in a week's time. But we should always aim to improve and perfect that good thing we have just done. That is why one of the practices is continuous design improvement. A system should not be over-designed, but as development proceeds, its design has to be improved so that the code remains of high quality.

6. Diversity: development teams need to have different skills, experience, approaches. Only in this way will the team be able to choose the best solutions in each case. This can be a source of conflicts that need to be resolved, which is why XP has some technical practices that favour the communication spaces necessary to resolve these conflicts.

7. Reflection: Good teams not only do the work, but they are also aware of how they do the work and continuously improve the process by which they do the work. Retrospectives in scrum are a concrete practice aimed at process improvement. Having a space for self- analysis and constructive criticism greatly enhances the functioning of a team.

18

European Open Business School

MANUAL GESTIÓN DE PROYECTOS ÁGILES

8. Flow: Historically, software development has been done discretely in large leaps. Software updates occurred every one or more years, which posed a lot of risk in the form of delays and user rejection. Today it is common for software to be developed continuously and predictably. Depending on the software this may be once or twice a year, but there are other services (such as some web applications) that are updated several times a day. Practices related to continuous integration are guided by the flow principle.

9. Opportunity: consider problems as an opportunity for improvement. If a customer complains that a feature is buggy, consider it as an opportunity to improve your test coverage. If a programmer makes a lot of mistakes while programming, encourage peer programming and code review. If we approach all problems as opportunities for improvement, it will be much more likely that the software developed will be of higher and higher quality at a reasonable cost.

10. Redundancy: Redundancy is applied in many IT contexts. One should not have a single point of failure, neither in computer systems nor in hardware. For example, testing is a form of redundancy over implemented functionality. One piece of code acts one way and another piece of code verifies that it acts as it should. Peer programming or code review is a form of redundancy. Continuous communication with the client is a way of verifying what was requested in the first place.

11. Failure: sometimes trying something and failing is much better than having endless meetings discussing the merits of each alternative. Some people call "analysis paralysis" the process of over-analysing something by thinking of dozens of variants and situations when in reality two or three proposals could have been implemented and an empirical analysis carried out, which would have been much more effective.

Failure is a way to learn and if managed properly, much better than analysis paralysis. Lean startup recommends failing fast and cheap, as a way to validate business models.

12. Quality: Quality is not an effective form of control. A project with higher quality is not more expensive than one with lower quality. In small projects, in the form of prototypes, developers can relax the quality of the code a lot and thereby gain some time to-market. But in almost any real project, quality ensures that the cost of the project will be lower

19

European Open Business School

MANUAL GESTIÓN DE PROYECTOS ÁGILES

maintenance is kept to a minimum, which in the medium term reduces the costs and risks of the project. Sometimes quality is at odds with simplicity. A more maintainable solution may be more complex and costly than a simpler but less maintainable solution. The rule of thumb would be: try to do the best you can with the time available. The next iteration will improve on the work of the first iteration as a base. This can be seen as a waste of time, but it is also a way to fight analysis-paralysis, bring value to the customer from the beginning and reduce risks. 13. Child steps: try to make the steps as small as possible, this will reduce the risk of failure of large steps. For example, run tests for every small code change you make. This will allow you to detect potential bugs more quickly. Don't wait two years to release a new version, try to offer updates as often as possible to users. A priori it may seem that small steps slow down development, but, in practice, small steps mitigate many risks and problems are solved much faster.

14. Accepted responsibility: Responsibility cannot be imposed, it can only be accepted voluntarily. XP practices reflect this principle. The team that has to do a job estimates the cost of doing that job and takes responsibility for meeting that estimate to the best of its ability. Similarly, the person responsible for implementing a user story takes responsibility for the design, implementation and testing of that story.

The principles allow a better understanding of the technical practices proposed in XP. Furthermore, by following the principles, new practices can be developed that are more suitable for certain types of projects.

20

European Open Business School

MANUAL GESTIÓN DE PROYECTOS ÁGILES

7. Good technical practices in XP

As we have seen before, one of the main differences between XP and other methodologies such as Scrum is that in XP the main weight is on the development team and the good technical practices that are recommended. Below is a list of the good technical practices that XP proposes to achieve quality software frequently and at a predictable cost:

• The team must be together • The team as a unit • Uses information radiators on project progress • Work reasonable hours to be productive • Plan using user stories • Margin in planning (Slack) • The weekly cycle and the quarterly cycle.

• Peer-to-peer programme • Test-driven programming • Construction in 10 minutes • Continuous integration • Emerging design

Some of these practices are more general project and team management issues, while others are more particular to software development, more technical (marked with in the list above). The more general practices will be described below.

The team must be together According to the XP methodology, development improves if it takes place in an open space large enough for the whole team to be together. One of the keys to the success of a project is communication between its members and the feeling of teamwork. And this is largely achieved by developing together. And it is not only about programming in pairs, as we will see later, but rather about developing in a shared space. The Spanish proverb is clear: "el roce hace el cariño" (rubbing makes love). In my personal experience, working in the same room has been very important to achieve the objectives of the project. Talking to colleagues, we all realised the importance of being together. This is not to say that working together in the same room is a prerequisite for developing quality software, but simply that it is a practice that has been proven to help achieve the project's objectives. European Open Business School

21

MANUAL GESTIÓN DE PROYECTOS ÁGILES

Obviously you also have to respect other team members, keep the room at an acceptable noise level and avoid interrupting others when they are concentrating on a task that requires concentration. Another important aspect to keep in mind is that the number of people in a team cannot be too large. Experience has shown that the ideal size for a development team is 7 people, and up to 9 in exceptional cases. In the case of larger teams, they will have to be split in two in order to strike a balance between maximising productivity and minimising the management and coordination burden among members. The team as a unit Include in the team all the profiles necessary for the achievement of the project's objectives. In a manner of speaking, it is better to divide teams by project rather than by task type. Experience has shown that it is better to have a user experience expert, several developers and a systems administrator in the same team rather than having user experience departments, development departments and systems departments that are responsible for several projects. Focusing on a project, with specific clients and with specific colleagues helps to get involved in the project, to have the feeling of a team and to better achieve the objectives. A team does not have to be constant over time; it may change members as the project progresses and certain tasks are no longer needed. For example, the UX person on a project may have less workload in the later iterations of the project. At that point, he or she can move on to another project. Although a team member may at some point be collaborating with another team on another project, we should try to avoid this as far as possible. It is very difficult for people to change tasks and objectives, we are more productive when we have a clear objective and all our actions are aimed at achieving it. Moreover, collaborating in two teams simultaneously reduces the feeling of belonging to the group, which has a negative effect on motivation and commitment. Uses information radiators on project progress. Each team member has to know what is the best task he or she can perform at any given moment for the good of the team. In addition, each team member needs to know the development status of the current iteration and of the project as a whole. This can be achieved in many ways. You can use task management software tools, you can use a "rudimentary" shared excel in which each row European Open Business School

22

MANUAL GESTIÓN DE PROYECTOS ÁGILES

represents a task and are organised in order of priority, or any other technique that allows for the prioritised list of user stories to be manually prioritised. In many development teams, the aim is to make the progress of the project visible to everyone on a wall. To do this, they use post-its that are easy to write on, discard and move. Each post-it represents a user story. Each user story is divided into tasks, and for each task a post-it is also used. These post-its are easy for anyone to write on and are easy to move from one state to another. It is common to have a board with columns. Each column represents the status of the task: Ready, In Progress, Finished, Impeded.

This way of managing the progress of projects is also known as visual management. Xavier Quesada's XQA blog shows many interesting visual management techniques. Below is a picture of a typical information radiator taken from this blog.

23

European Open Business School

MANUAL GESTIÓN DE PROYECTOS ÁGILES

The Scrum burn-down is also a very good radiator of information about the progress of the iteration:

One of the great advantages of information radiators is that the status of the project is always visible to everyone. For the developers, for the scrum master and above all for the customers, who can see at a glance and with hardly any technical knowledge whether certain functionalities are already implemented in the current sprint.

Work reasonable hours to be productive There are some good practices that should simply be considered common sense. Working reasonable hours to be productive should apply in any context. The thing is that software development is such a special kind of task that it seems like we can be programming all day long with just a cup of coffee by our side. The problem is that, at a certain point, productivity drops to the point where we start making mistakes that do more damage than the benefit we could get from working longer hours. At certain points in development it may be necessary to "make an effort" and stay a few hours longer, but this will be a bad sign and the problems that caused it should be solved as soon as possible. Intellectual work such as software development under a lot of pressure over a long period of time inevitably leads to the development of low quality products.

24

European Open Business School

MANUAL GESTIÓN DE PROYECTOS ÁGILES

Plan using user stories User stories have become the standard in agile methodologies to concisely and succinctly describe the functionality of software and guide development. The XP methodology also recommends the use of this technique.

Margin in planning (Slack Some tasks may be included in the planning that are not mandatory and can be eliminated if you are not on time. It is important to meet commitments, so it is useful to have some leeway in the planning in case estimates are not tight. In some projects, the team or the manager plans more workload than can actually be done without compromising the quality of the product. This creates too much tension in the team, which is ultimately detrimental to the development of the project. Meeting the commitments made by the team is motivating. Not meeting targets is frustrating and demoralising. In many organisations, this extra time is often used for developers to collaborate on open source projects that may be of interest to the organisation. Or to experiment with new technologies. Or simply to improve their skills as programmers or managers. Google is famous for allowing its employees to spend 20% of their time on open source projects. The Madrid-based company Kaleidos also applies a similar technique with its pi-week. The weekly and quarterly cycle Unlike the Scrum methodology, which recommends iterations of between 1 and 4 weeks, Kent Beck, in the second edition of his book Extreme Programming Explained, proposes short iterations of 1 week. He says that this allows the team to focus on the user stories they have to implement in that iteration. A week, he says, is a framework that is widely used in many other human contexts. The synchronicity between the days of the week and the tasks of the iteration makes the work more predictable. The main disadvantage of such short iterations is that, if we want to apply the scrum methodology with its planning, demo and retrospective meetings, the week may be too small for those activities not to result in wasted time.

On the other hand, XP recommends holding 3-month cycles as a general

developmental guideline covering all weeks within those three months.

25

European Open Business School

MANUAL GESTIÓN DE PROYECTOS ÁGILES

REFERENCES

• Manifiesto Agil • 1996. Smalltalk Best Practice Patterns. Prentice Hall. (ISBN 978-0134769042). • 1999. Extreme Programming Explained: Embrace Change. Addison-Wesley. • Winner of the Jolt Productivity Award. (ISBN 978-0321278654). • 2004. Extreme Programming Explained: Embrace Change (second edition). Addison- Wesley. (ISBN 978-0321278654) • 2008. Implementation Patterns. Addison-Wesley. (ISBN 978-0321413093). • 2007. Scrum and Xp from the Trenches. Lulu Pr (ISBN 978-1430322641).

26

European Open Business School

European Open Business School

www.eobs.es