Agile development with Scrum and XP

Agile development with Scrum and XP

Raul Lopez Peredo
raul.lp@gmail.com

Abstract. In this paper I talk about the use of most expanded agile methodologies Scrum and extreme programming putting together their compatible practices, encouraging the use of Scrum practices for management tasks, Extreme Programming practices for development and other bit of agile practices such as KISS or DRY looking for project success. Furthermore some useful tools are suggested.
Keywords: agile, scrum, extreme programming, planning poker, continuous integration, TDD, user story, KISS, YAGNI 

Introduction

In contrast with other branches of engineering such as construction or manufacturing, when you could follow a predefined plan by a pert chart and met the project goals, software development has high level of uncertainty and risk ; everything changes in software development, requirements, people and technologies.

Agile methodologies provide some practices that reduce the risk in software projects, practices and principles from different agile methodologies could be combined to get better results and improve the process. Scrum and Extreme Programming are the most expanded agile methodologies, and they can be combined easily without any problems. In the rest of this document you will find a description of a bit of practices from scrum and extreme programming that could be used together to successful the software projects.
Content

Why should we use agile methodologies?
Due to feedback and changes in requirements are often given in the latest phases in waterfall (testing and user acceptance testing), introduce them in the project increases the cost and time of software projects, which entails the customer unhappiness and feels cheated.

Therefore the change is a constant variable in software development, as software developers we have to be capable to respond to changes, agile methodologies encourage the adaptability to changes.

In 2001 seventeen critics of formal software development process met to discuss the need for lighter alternatives to the traditional heavyweight methodologies, they coined the term agile methodologies, in a document called “The agile manifest ”.
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals 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 in the items on the right, we value the items on the left more.
Common mistakes in some teams in the name of agile confuse the word “over” by “instead” of the agile manifest, avoiding to successful the items in the right. Both left and right items are important in software projects; you cannot develop quality software without any processes, tools, or documentation.

Agile methodologies provide some practices that reduce the risk in software projects. There are a lot of methodologies that meet agile approach such as Extreme Programming, Scrum, Feature Driven Development, Lean Driven Development, Unified Process, and so on. They share the iterative development that consists in short iterations that contains all phases of software development planning, analysis, design, implementation and testing.
Is a reality that agile methodologies are the current fad in the software industry, recognized people such as Steve McConnell, Kent Beck and Mike Cohn among others and companies such as Google, Yahoo and Symantec are on board of agile train. “The below table shows the numbers from effectiveness on various parameters validated the effectiveness of Agile software development compared to traditional approaches ”.

Factor Improved No Change Worsened
Productivity 82% 13% 5%
Quality 77% 14% 9%
Stakeholder Satisfaction 78% 15% 7%
Cost 37% 40% 23%







It is important remind that the agile methodologies do not are recipes to meet software project goals. They could be applied by teams in a different way, software projects are different from each other, practices and principles from different methodologies could be combined by the teams to improve their processes.

Combining Scrum and XP
Scrum practices could be used for project management product backlog, iteration planning, and demos among others and extreme programming for development pair programming, test driven development, continuous integration. I think that those practices are funny, interesting and effective way to introduce in agile software development.

In the past I worked in a project with extreme programming we fell in the mistake of introduce all extreme programming practices at the start of the project instead of introduce them one by one to meet better results.

Tools
Before start talking about how to introduce agile in new projects, I consider important spend some time knowing some useful tracking tools.

• Xplanner is a project planning and tracking tool for eXtreme Programming (XP) teams, is an open source tool. Provides:
o Tracking for projects, iterations, user stories and tasks,
o Multilanguage support, ,
o Reporting charts i.e. burn down chart and metrics for individuals and teams i.e. team velocity, individual hours.
• Bugzilla is a Bug tracking systems allow track information about Product Requirements and issues.
• In a Wiki the team could publish the project status, in which iteration is the project, what are the iteration objectives, important dates such as demo, or planning meeting. Furthermore is useful to share knowledge among developers and others.

Teams
Let’s start with the team formation, team formation is a key for the successfully in any project, for agile projects the team has to be multidisciplinary and team members have to meet some skills such as communication, collaboration, teamwork, and do not forget the technical excellence. Bring activities such as movie films, go out to lunch, play team a game improve the communication and increases the level of trust among teammates.

Is suggestible but not a requirement seat all team together in a common work space that able team members listen and participate in any informal meetings of the project, such as a design discussion. I do not recommend organize and assign responsibilities to the team members; let them know their weakness and strengths to auto organize to achieve better results.

It is important provide a space to communicate the status of the project to team members and external people is a way to reminder the vision of the iteration. Blackboards are a common medium, but now we can use more sophistically things such as wikis to provide all information of the project.

Iterations
Now we have the team conformed, the next question is How long is ideal for the iteration? I used to think that very short iterations are too bureaucratic; people have a lot of meetings and short development and testing cycles. In the other hand long iterations appear to be more productive avoiding frequently planning meetings, but they lose the customer feedback. Anyway the team decides how long does the iteration take.

In my experience working with scrum and extreme programming 2 or 3 weeks is good size for iterations, it provides both enough time to team develop and test features, and planning and post iteration meetings. Furthermore provides the team the psychological satisfaction to achieve goals that entails in the good mood and motivation of all members of the team.

For a new team is important remind that the iterations are time boxed, and the result of the iteration has to be a valuable to customer and tested piece of working software.

First Iteration
The team use the first iteration to set the work environment, choose the technology to use, try tools for development and testing, test and choose useful frameworks, starts coding with the system architecture and initializes tracking and information share tools.

Product Backlog and User Stories
The Product Backlog is the master list of all functionality desired in the product those functionality can be listed using user stories. User stories are adopted in Extreme Programming because they are a simple way to gather requirements. The user story is a brief description in natural language of a valuable software feature; composed by description that is used in the planning and as a reminder, notes result of meetings between developers and customer, and finally a set of tests that contains the information to know when the user story was successfully completed.

Mike Cohn suggest that the good user story meets with INVEST characteristics,
• Independent, avoid user stories dependence each other,
• Negotiable, negotiable unit between customer and developers,
• Valuable, has to give value to user or customer,
• Estimable, is possible know the effort necessary to complete the story.
• Small, the small enough to develop several stories in the iteration, if the user story is too short analyze if it can be switched to a task from other user story. If the user story is too long try to split it in more little and independent user stories.
• Testable, is possible know if the user story has been completed.

At the beginning some team members cannot understand what does the user story means? Is important first define scenarios that provides a bit information about the project, them they could write use cases that reflects the scenario to have a better picture of the structure and dependence between classes and methods, finally they can split the use cases into user stories and then developers could implement the user stories in parallel.

Planning
There are several ways to drive the iteration planning such as planning game or feeling good method, they consist in essence in take the most valuable user stories, break down in tasks and estimate their effort.

Estimation is a very difficult task for beginner developers, through the experience gained with the platforms and tools the estimations skills are more precise, a useful technique to estimate is the yesterday If yesterday we had a warm and cloudy weather, is probable that today we will have a warn and cloudy weather. In software development is very important have tools to track the software development, you can see how long taken you or another developer or quality engineer implement a seemed story or task.

Sometimes the estimation of all user stories and their tasks in detail could take too long hours due to discussions about the estimation time effectiveness. There is an interesting technique called planning poker, to improve the estimation process.

In planning poker each team member gets a deck of 13 cards as shown above. Whenever a story is to be estimated, each team member selects a card that represents his time estimate in story points and places it face-down on the table. When all team members are done the cards on the table are revealed simultaneously. That way each team member is forced to think for himself rather than lean on somebody else’s estimate. If there is a large discrepancy between two estimates, the team discusses the differences and tries to build a common picture of what work is involved in the story. They might do some kind of task breakdown. Afterwards, the team estimates again. This loop is repeated until the time estimates converge, i.e. all estimates are approximately the same for that story.

Daily Stand up meeting
In difference of the daily scrum where team members report their status using the three questions:
What did you have done yesterday?
What do you plan to do today?
Do you have any blockages?

To track the team member status you could use the management tools such as Xplanner. A stand up meeting is more efficient, is used to communicate problems, solutions, and promote team focus. Everyone stands up in a circle to avoid long discussions.

Test driven development TDD
“Test-driven development means that you write an automated test, then you write just enough code to make that one test pass, then you refactor the code primarily to improve readability and remove duplication. Rinse and repeat.”



I know write unit test is a tedious and costly activity, but this price is justifiable this entails in big list of benefits to the project:
• Increases quality of source code,
• Developers focus in a little problem avoiding write some other pieces of code that they do not need.
• The test code was wrote once could be run thousands of times.
• Mocks could be used to represent the external world.

Code conventions
Use code conventions and commentaries able all team members to maintain pieces the code of other developers, increase the code quality and entails in the maintenance of project. Avoid code conventions and commentaries entails in waste trying to understand code and make code writers immovable from the project.

Sustainable pace
Work just as many hours as you are productive, do not over run team all time, is suggested work hard the last days of the iteration, this is called sprint the last acceleration of the race. Work over run all time implies to wear on self out team members, the team velocity will fall down, and the project is destined to fail.

Continuous integration and a build machine
Continuous Integration is the practice where team members integrate their work frequently; usually each developer integrates daily their work. To success with this practice is useful have a source repository. Is important remind to team members that they have to integrate their pieces of code to the all system project, if the team do not integrate they will waste a lot trying to integrate the system, it will entail in broken features.
Is suggested have a build machine that verifies if the build has been broken, a build machine that checkout the source code, compiles all sources, finally run all unit tests. This machine notifies to team members by email or SMS if something was wrong; compiling error or unit test failing.

Other agile principles
KISS is originally an acronym for "Keep it Short and Simple", some also use the more popular term "Keep it Simple, Stupid". KISS states that design simplicity should be a key goal and that unnecessary complexity should be avoided .

YAGNI (You are not going to need it) refers to avoid write code that is not necessary in the moment, you might not spend time working in things that are not necessary for the project in this moment, it could entail in new bugs, and does not provide customer valuable software.

DRY (Do not repeat yourself), is a process philosophy aimed at reducing duplication. Duplication increases the difficulty of change, may decrease clarity, and leads to opportunities for inconsistency. When the DRY principle is applied successfully, a modification of any single element of a system does not change other logically-unrelated elements .

Conclusion
The practices presented in this document are a bit core of practices that could be introduced into teams to board on agile development, but they have to be accomplished by agile principles and the most important thing is that all team members have to be involved with the project to meet it successfully.

“Process is only a second-order effect. The unique people, their feelings and qualities are more influential ”. Is vital that all team members think in agile to maintain the synergy of all team, people who does not think agile might be a stone in the shoe and could delay and push team in the wrong way.

I did not talk about geographical distributed teams; it does not mean that it could not be realized, the most important thing to manage offshore team members is to encourage the communication between all team and assign the same risk or difficult tasks to offshore team members.
References
Agile Manifest http://agilemanifesto.org/
http://www.infoq.com/news/2008/05/agile-adoption-survey-2008
User Stories Applied: For Agile Development. COHN, Mike. Ed. Adison Wesley 2004
Scrum and XP from the Trenches. KNIBERG, Henrik. Ed. InfoQ 2007. ISBN: 978-1-4303-2264-1.
KISS principle, From Wikipedia, the free encyclopedia
Don't repeat yourself. From Wikipedia, the free encyclopedia
Agile & Iterative Development, A manager’s guide. LARMAN, Craig.