School of Information Technology ESSAY COVER SHEET

Unit Name: ICT353Advanced Business Analysis and Design

Name: Anuar
FAMILY NAME (Capital Letters)

Mohammad Farihin 31384842

Given Names Student Number

Due Date:

Date Submitted:
Your assignment should meet the following requirements. Please confirm this by ticking the boxes before submitting.

Above details are fully complete. Submitted files do not contain any viruses. You have retained a copy of submitted files. Declaration below is completed.

All forms of plagiarism, cheating and unauthorized collusion are regarded seriously by the university and could result in penalties including failure in the course and possible exclusion from the University. If you are in doubt, please contact your Unit Coordinator.

D ECLARATION Except where I have indicated, the work I am submitting in this assignment is my own work and has not been submitted for assessment in another unit. I also acknowledge and agree that the assessor of this assignment may, for the purpose of assessing this assignment: reproduce this assignment and provide a copy to another member of faculty; and/or communicate a copy of this assignment to a plagiarism-checking service. This web-based service will retain a copy of this work for subsequent plagiarism checking of documents submitted from Murdoch, but does not claim any rights on the information submitted and has provided assurances that information submitted will not be used for any purposes other than providing plagiarism detection services to Murdoch.

YOUR NAME HERE: Mohammad Farihin Bin Anuar

(Where you are submitting this declaration electronically, you do not need to sign it. The fact that you have included it with your assignment to the LMS is evidence of your agreement.)

Page 1 of 17

A C ASE S TUDY O F O RGANIZATIONS U SE O F A GILE M ETHODOLOGIES A GAINST T HOSE T HAT U SE T RADITIONAL M ETHODOLOGIES I N B IG P ROJECTS

PROJECTS?

CAN AGILE METHODOLOGY BE USED IN BIG

Author: Mohammad Farihin Bin Anuar Supervisor: Mr. Ronald Shiflet

Page 2 of 17

DEDICATION
in my life

I dedicate this thesis to God because without him, I wouldnt be able to be able to make a change

Page 3 of 17

ACKNOWLEDGEMENTS

I would like to extend my gratitude to my supervisor, Mr. Ronald Shiflet, for his support and essay. You raise me up to more than what I can be and youre the best mum any son could ever his teaching period. I had gained so much knowledge from what I thought I already know.

encouragement for me to be able to write this thesis and guiding me throughout the course of have. Thanks to my dad who has been working and supporting my family all this while and my to undertake this course. My irreplaceable mum who supported my studies and been the inspiration for me to write this

two sisters who are currently studying. I pray to God to protect you guys forever.

My special thanks to Murdoch University Bachelors Program also for giving me an opportunity

Page 4 of 17

ABSTRACT

In recent times, there has been lots of talk on agile methodologies. Some sources even indicate that agile methodologies supersede the traditional waterfall. The purpose of this thesis is to do used to develop huge IT projects and its success in implementing it.

case studies specifically aimed at big projects to uncover if agile methodologies can really be the different types of agile methodologies and case studies on their success in huge IT projects the issues that the traditional methodology could not address. It will then progress to explore

Extreme Programming (XP) methodology that is specifically tailored for small IT projects could be adopted for huge IT projects. Three case studies have been identified for this purpose. researched companies have adopted. Other limitations include the lack of case studies that

In this research, it is proven that agile methodologies can be applied to a big-scale project i.e.

resource of at least 20 developers and analysts and distributed environments.

specifically requires heavy funding amounting to millions of dollars, exhausting a minimum

implementations. The definitions of huge IT projects in this thesis refers to projects that

The study begins by looking at the birth of the agile methodology, the reasons for its birth and

is specially tailored for small-scaled IT projects. The scope of this research only focuses on Keywords: certain popular agile methodologies specifically SCRUM and XP.

The limitation of this research is the lack of steps and methods in the agile methodology that the

support the use of agile methodologies especially for XP given the fact it is relatively new and it

History of Methodologies, Traditional Methodologies, Agile Methodologies, Extreme Programming, Case Study, Large Project,

Page 5 of 17

TABLE OF CONTENTS
Acknowledgements................................................................................................................................. 4 Abstract ................................................................................................................................................... 5 Table of Contents .................................................................................................................................... 6 1 1.1 1.2 1.3 1.4 2. 2.1 2.2 3. 3.1 3.2 3.3 4. 4.1 4.2 5. 5.1 5.2 6. Introduction .................................................................................................................................... 7 Background ................................................................................................................................. 7 The Fall OF The Waterfall Model ................................................................................................ 7 The Reason of Birth For The Agile Methodologies ..................................................................... 8 The Formation Of The Agile Alliance .......................................................................................... 8 The Agile Methodologies Explored ................................................................................................. 9 Extreme Programming (XP)......................................................................................................... 9 SCRUM ...................................................................................................................................... 11 The Case Study of Dutch Railways (ProRail) ................................................................................. 12 Background ............................................................................................................................... 12 Distributed Teams ..................................................................................................................... 12 Conclusion and Analysis ............................................................................................................ 13 The Case Study of The Atlas Project ............................................................................................. 13 Background ............................................................................................................................... 13 Conclusion and Analysis ............................................................................................................ 14 The Case Study of Henrik Kniberg Experiment ............................................................................. 14 Background ............................................................................................................................... 14 Conclusion and Analysis ............................................................................................................ 15 Final Verdict .................................................................................................................................. 15

References ............................................................................................................................................ 17

Page 6 of 17

1 INTRODUCTION 1.1 BACKGROUND

pass waterfall. They overlooked the specifics that stated that If the computer program in question is being developed for the first time, arrange matters so that the version finally delivered to the customer for operational deployment is actually the second version insofar as critical design/operations areas are concerned (Craig & Victor, 2003). This in its entirety meant the waterfall was supposed to be perceived as an iterative process in a way as it repeats

waterfall. However, the interpretation of many experts had perceived his concept to be a single

author for the famous article entitled Managing the Development of Large Software Systems during the 1970s, invented a sequence of steps which was later known as the traditional

Traditional approaches to project management have always been useful for projects when the user requirements are rigid or can be known early (Steward, 2002). Winston Royce, the

the lifecycle over the same project twice should the project be a new development with alien requirements.

IT projects (Bomarius, Oivo, & Jaring, 2009). Furthermore, some customers are not clear and precise about their requirements (Cadle & Yeates, 2008) leading to vague specifications and that documentations can only convey up to 30% of communication while the other 70% is exact same problem when experts perceived his waterfall model as a single pass waterfall. possible solutions that are nearly impossible to manage using traditional project management approaches. Other reasons include heavy documentations that is intensely relied on and no real output until the end (Steward, 2002). In Managing Agile Projects, the author mentioned

1.2 THE FALL OF THE WATERFALL MODEL

It has already been made known that the main reason why the traditional methodology is

unpopular is because of the inability to manage the user requirements well especially for huge

conveyed through non verbal means (Kevin, 2005). The irony of it all was that Royce had the

The purpose of heavy reliance on documentations in the traditional methodology was to put Commander commented that in my opinion a battle never works according to plan. The plan is only a common base for changes. (Scott, 2005) This contradicts the waterfall theory of every Page 7 of 17 that the plan can be set to motion and carried out smoothly. An Israeli Defense Forces

requirements in black and white so as to minimize changes in the later parts of the project so

requirement and specification could be planned out in advanced.

Another factor for waterfalls popularity status was that the traditional method transverses by towards the end of each phase when it might be tedious to undo and accommodate the changes.

phases which mean customer is unable to feedback or provide any inputs on the project until

properly. Due to this blame culture itself, the technical community decided to develop their own on the management side of agile project management as compared to the principles or discipline of the development side (Kevin, 2005). methodology while the manager perfected the art of their traditional methodology (Kevin,

The managers will blame the developer for not having certain functionalities built and the

developer will blame the manager for not gathering and documenting the requirements

circumstances discovered from the start and the lack of input from the customer, it started a frenzy of blame culture amongst managers and developers for the failure of these IT projects.

1.3 THE REASON OF BIRTH FOR THE AGILE METHODOLOGIES

As a result of these communication breakdowns, the mindset of having all unforeseen

2005). The methodology that has given birth by the technical community which was later

named as Agile. The evidence can be easily justified by simply reviewing the scarce information

Development, Pragmatic Programming, and others met and formed the Agile Alliance (Jim, 2001). Their basic principles and goals are (Principles behind the Agile Manifesto): 3. "Welcome changing requirements, even late in development." 4. "Deliver working software frequently." 5. "Working software is the primary measure of progress." their need, and trust them to get the job done." valuable software." 2. "Business people and developers must work together daily throughout the project."

1.4 THE FORMATION OF THE AGILE ALLIANCE

In the year 2001, representatives from the agile umbrella such as those from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven 1. "Our highest priority is to satisfy the customer through early and continuous delivery of

6. "Build projects around motivated individuals. Give them the environment and support 7. "The best architectures, requirements, and designs emerge from self-organizing teams." 9. "Agile processes promote sustainable development." Page 8 of 17 development team is face-to-face conversation."

8. "The most efficient and effective method of conveying information to and within a

implementations?

methodologies and its impact on huge IT projects. Are these principles enough to sustain a huge development? Are all the agile methodologies able to achieve success in huge IT project

scale IT project? If so, what are some of the agile methodologies that can sustain this heavy

With these principles in motion, it hopes to resolve the issues which the traditional model could

12. "Project teams evaluate their effectiveness at regular intervals and adjust their behavior accordingly."

10. "Continuous attention to technical excellence and good design enhances agility." 11. "Simplicity is essential."

not address especially to new IT project implementation. But little is known about agile

2. THE AGILE METHODOLOGIES EXPLORED

The two most famous and widely used agile methodologies are XP and Scrum (Agile Methodologies Executive Overview). Numerous case studies and documentations have revolved weight and deal with small development teams. Besides this, both of them cater to highly to be modified in order to tailor to those needs. Because XP and Scrum are both popular and handle distributed environments and multiple customers or stakeholders while XP would need volatile requirements as well. The differences when it come to practicality is that, Scrum can around these two agile methodologies on the web. Both methodologies are said to be light

2.1 EXTREME PROGRAMMING (XP)

challenge to defy and stretch the capabilities of these two agile methodologies for big project implementation.

said to be light weight and only meant for small development teams, I personally took up the

Extreme Programming (XP) was mainly created by Kent Beck and Ron Jeffries (co-authors of the Agile Manifesto). The term extreme programming was first used in 1997 (Steward, 2002) values are Communication, Feedback, Simplicity, Courage, and Respect in order to effectively (Steward, 2002). XP has always been known to aid small projects in development. develop high quality programming code which in turn will provide improved flexibility The XP practices include the whole team working together in one room, regular refactoring, Page 9 of 17

though the concept originated back in the 1980s (Pekka, Michele, & Frank, 2009). Its basic

method is team-and communication-oriented with customers, developers, managers working

strong emphasis on testing and pair programming as means to improve quality of code. The

together in the same area/room as a team with a focus on producing high quality code for software of high business value.

In XP, the customer is treated as part of the team and should be on-site with the rest of the evolve their requirements based on the working software that the customer tests on a regular basis to confirm it works accordingly. XPs life cycle consists of six phases (Carsten & Timo, 2004):development team. The customer also writes user stories and discusses each requirement including prioritizing user story development. The 2-3 week iterations allow the customer to

directly with the development team for which he is responsible for all business decisions

Exploration a few weeks to a few months; the phase where the team becomes familiar with the technology and practices at hand, and the customer gathers/provides requirements for the first release. Story card writing (features), estimating, and prototyping. release schedule. Story card writing and estimating. with functional tests. Task writing and estimating. Training, marketing and documentation. Planning several days, work with the customer to plan and prioritize for the first release, developers estimate the need for resources on their part, and team management plan a first

Iterations to release Each iteration takes one to four weeks and there are several iterations preparing for the first release and the next phase. Each iteration of programming is finalized Productionising further performance testing to meet the customer requirements. New changes may be added here or be recorded as changes to be added during the next phase. new iterations alongside further testing and building of major releases. There should customer is planned. This phase occurs when there are no further incentives for additional investment value.

descending customer requests at the end of this phase. Otherwise return to the Iterations to release phase for the next iteration. Death Completion of all necessary documentation and the release of the product to the changes. The reason for this could also be because it is too expensive to change and has low

Maintenance Corrective, perfective and adaptive changes and feature requests produced in

Page 10 of 17

2.2 SCRUM

The project management methods of Scrum are sometimes combined with the more practical engineering techniques and practices of XP which can work as a compliment to each other. Examples on key practices in Scrum are: Self-organizing teams No external addition of work to an iteration once chosen 30-calender day iterations called sprints Client-driven adaptive planning in each iteration (Carsten & Timo, 2004); Pre-game phase

estimations on remaining time in the project are practices to aid in this goal-oriented method.

software development. Daily meetings, short iterations, self organizing teams and constant

Scrum is mostly developed by Ken Schwaber, Jeff Sutherland, and Mike Beedle in the 1980s and

modeled based on the game of rugby. Scrum has always been known to be handy in small scale

1990s (Szalvay, 2008). Scrum is considered a light weight project management method

Demo to external stakeholders at the end of each iteration

Daily (15-30 minutes) stand-up meetings with special questions

The life-cycle in Scrum consists of three phases with the first phase divided into two sub-phases Planning establish the vision writing it down, set the expectations, secure funding in and modifications including all known requirements - all which are prioritized and resource/effort estimated), exploratory design and prototypes. The product backlog is Owner. design and prototypes are elaborated based on the Product Backlog. controlled by one person only, regardless of how many contribute to it; the Product

a budget, define the system in a Product Backlog (which is often updated with features

Staging, Architecture/High level design more requirements are identified and the

executed in a development process before completion of the product/system. Page 11 of 17

Development Phase Iterative development cycles; sprints, which span from one week to 30 days. Each sprint includes requirements, analysis, design, evolution and delivery, with daily sprint meetings and defining of the sprint backlog and sprint reviews. Three to eight sprints are

3.1 BACKGROUND

3. THE CASE STUDY OF DUTCH RAILWAYS (PRORAIL)

Release, Post-game Phase Documentation, training, marketing & sales, delivers the system in one release with no additional modifications which concludes the project and effort.

In Netherland, the consumption of passenger utilizing the Dutch railways could easily fetch 1.2 travelers and passengers alike with precise details on travel information had to be built which in the process free up manual labor with automation. In this initiative, Xebia, a development controlled. Before Xebias proposition, an IT vendor adopting a waterfall approach was assigned to the company primarily based in Netherland, France and India, had invented the PUB system where information displays and audio broadcasting systems in all stations are centralized and project. Detailed requirements specifications were given to the vendor to scrutinize and develop the system without much user interaction. However despite the detailed requirement ground zero.

million passengers daily. A need for a new information system with the purpose of providing

specifications and the instance of 3 years, not only was the project cancelled, there was no working system. Hence Xebia was nominated next to accomplish the projects completion. Xebias adopted a scrum approach with XPs discipline to the development of the project from sprint. The early team consisted of a project manager, an architect and a Scrum master. For

first sprint.

Xebia initiated the project by first laying down the prerequisites before the kick-off of the first

Initial problems were encountered when Xebia could not attain anyone fitting to be the product iterations.

three week they laid down the specifics and prerequisites required before the kick-off of the

owner due to time constraints, poor domain knowledge and the extra tasks of prioritizing requirements. In the end, two business analysts were selected due to their involvement with the previous vendor and their availability. Project velocity was estimated after a couple of

3.2 DISTRIBUTED TEAMS

The commencement of the first sprint had seven people working in two-week iterations. It was Page 12 of 17

already determined that scaling up the strength of the team would require the Indians

familiarized with the application domain, key customer representatives and the rest of the developers went back to India to join the Indian development team there. The size of the team development team after 6 weeks of being on-site at the customers premises. eventually scaled to four different development teams of five developers and one tester each. A settlement on the teams collaboration was agreed upon. After some iterations, the Indian

involvement. From the first sprint, two Indian developers had joined the project. They got

project peak; half in the Netherlands half in India (Xebia)

The customer was astounded by the end product. To top it off, the functional requirements of successfully delivered. The customer articulated a sense of satisfaction and based on an external 2008)

performance etc. In the end, the project had utilized 40+ man years, 20 people in 4 teams at

Amongst the four, three of the teams were focused on the development while the remaining team was assigned to focus on the architecture such as security, logging, availability and

the project had changed overtime to keep up with the business trends but yet the project was audit the report it, was just as astounding. In the report, it commented that the maintainability

of the system is very good and the quality of the source code is very high. (Marco & Martin,

3.3 CONCLUSION AND ANALYSIS

This case has clearly shown that agile methodologies such as Scrum and XP have found success client. The contributing factor to their success would be their strategic planning and their developers who were already accustomed to their collaboration methods back to India to communication amongst one another. In strategic planning, they have sent the two Indian in a large scale project implementation. It has also indicated that the waterfall methodology had failed primarily due to lack of involvement and communication between the vendor and the

spread this culture. This led to effective communication despite the geographical boundaries. previous vendor that based primarily on the requirement specification documentation.

Communication was perfected in the form of daily scrum meetings and user feedback unlike the

4.1 BACKGROUND

4. THE CASE STUDY OF THE ATLAS PROJECT

Page 13 of 17

ThoughtWorks, Inc is a SI company operating in Chicago. This case study yet again shows that

agile methodology can be used in big project. The Atlas Project was a leasing applications

system. The methodology that was adopted by ThoughtWorks, Inc is a hybrid of XP and waterfall approach. The development phase was based on the XP methodology. At the start, ThoughtWorks went with the waterfall approach to gather comprehensive and communication had to be detailed and precise for ThoughtWorks to spend 18 months in the team handling the project, were 35 developers, 15 analysts and 10 QA staffs (Steward, 2002). extensive requirements and design probably to get the requirements right. Most definite

analysis and design phase alone. They changed to XP afterwards. The breakdown of the project requirements, writing user stories, and setting priorities (Amr). This of course would require The critical points of determining the success of the project was XPs discipline of paired programming and constant integration. The analysts acted in the role of customer, filtering developers, good communication between developers and iteration planning meetings keep everyone in the big picture about who is doing what. (Amr)

strong and precise communication between the analyst and the customer. Amongst the

known to do wonders for small projects. They are on their way of delivering a very large and growth as developers giving them confidence in undertaking huge IT projects. importance of the iteration planning meeting in small teams was just about that as well.

4.2 CONCLUSION AND ANALYSIS

complex application on time (Amr) and during this process, it has facilitated their learning Strategic planning was also present in this case study as they switched their methodology from with different strengths and weaknesses in order to make pair programming a success. Again communication was the key to solving differences amongst developers and the

The author mentioned in his article that XP, or our evolved version of it, has done wonders for

us as a team. (Amr) They were doing something that was unthinkable for XP which has been

a waterfall approach to a modified XP approach. They also addressed the issues of developers

5. THE CASE STUDY OF HENRIK KNIBERG EXPERIMENT 5.1 BACKGROUND

consultant who was assigned the task to fix the problems faced in the company. The company had severe overtime issues, frequent firefighting and missed datelines (Henrik, 2007). Page 14 of 17

Henrick Kniberg in his book titled Scrum and XP from the Trenches: How we do scrum did an

experiment on an IT project with 40 developers (Henrik, 2007). In this, the author was a

Every aspects of the project were proven to be a success and hence he decided to share his knowledge of Scrum to the community. Henrik Kniberg also stated that we should not follow It is up to the strategic planning of the project manager or Scrum Master to orchestrate the the problems as they come. harmony and communication between people and to devise a strategy to be initiated to counter exactly they do Scrum and XP as situations especially targeting at people and culture may differ.

Henrick fixed the problem in one year and applied Scrum throughout all area of the company. He came out with a formula defining more developers = more complications (Henrik, 2007).

communication that needs to be fluent and present for the project to succeed. He also

mentioned that there is no way for you to copy and paste a plan. Strategic planning needs to

tightly collaborating team members that pair program and meet face to face every day. (Henrik, 2007) It really isnt that hard to understand that what he was referring to was actually take place depending on the situation and not on a plan. That is the agile way of doing things.

5.2 CONCLUSION AND ANALYSIS

In his book, he has also mentioned that Much of scrum and XPs magic is based on co-located

6. FINAL VERDICT

Based on my analysis of these three case studies, I can only conclude that agile methodologies can and should be implemented in huge IT implementations.

One reason is that agile methodologies such as XP and Scrum if implemented properly

significantly help in communication between people. Communication is crucial and pivotal users understanding of the system and how it will work to someone based on an individuals standpoint. But even so, as mentioned by Kevin Aguano, only 30% of the communication is

users such as the UML and BPMN modeling. All these are to facilitate and communicate the being relayed as demonstrated in Winston Royces case. So hence XP and Scrum if used correctly been mentioned that the techs and the business people need to work together with the communication and heavy documentation. Other factors such as the customer do not know what they want simply gives us all the more reasons to use Agile approaches. In the Atlas Page 15 of 17 is going to give 100% or close of that communication. As with the agile manifesto, it has already

which concludes why society came out with different methods of communicating with different

customer or stakeholders. Big projects with little communication will result in a project failure as demonstrated in the ProRail project where the previous IT vendor did little face-to-face

project, good communication between developers and iteration planning meetings keep

everyone in the big picture about who is doing what. (Amr) And, with the experiment done by team members that pair program and meet face to face every day. (Henrik, 2007) In my main essentials in contributing to the success of the project.

Henrick Kniberg, Much of scrum and XPs magic is based on co-located tightly collaborating Personally, I believe waterfall model would contribute to small projects that have similar this rule; as time change, people change, technology change and so business rules will also analysis and opinion, I can safely conclude without a doubt that communication is one of the

requirements as a previous project. The waterfall model should never be used on requirements

specifications that are alien to you. Agile is the way to go even for big projects simply because of waterfall model? For that reason, I believe that the waterfall methodology could be may take years to develop, agile methodologies should be the way to go as it welcomes new requirements knowing and embracing this rule. The three case studies are all proof of that requirements because the business rules may not change as much. But if the project is huge and

change. This was clearly understood by the members in Agile Alliance. And so, if everything

changes shouldnt your plan also change? But how would that change come by with a strict implemented in a similar small scale project of a project that was done recently with similar

or in other word, agile, to keep up with the current trends and situations.

theory. So, strategic planning is a must in an agile environment to counter these complex and

Finally, you may have the best strategist to plan but if two way face to face communications is devastating. As the Israeli commander said a battle never works according to plan. The plan is communication are addressed.

emerging rules. Strategic planning should never be stringent. In fact it has always been versatile

not present to discuss this plan to seek understanding and approval, the result will still be only a common base for changes. (Scott, 2005) With that, I have concluded that agile methodologies can and should be used for big project provided strategic planning and two way

Page 16 of 17

REFERENCES

Agile Methodologies Executive Overview. (n.d.). Retrieved Febuary 19, 2011, from http://www.wintrac.com/courses/ameo.asp Amr, E. (n.d.). XP On A Large Project A Developers View. Retrieved Febuary 18, 2011, from http://www.uml.org.cn/softwareprocess/pdf/XP%20On%20A%20Large%20Project%20%20A%20Developer%27s%20View.pdf Bomarius, F., Oivo, M., & Jaring, P. (2009). Product-Focused Software Process Improvement: 10th International. Germany: Springer-Verlag Berlin Heidelberg 2009. Cadle, J., & Yeates, D. (2008). Project Management for Information Systems. Prentice Hall. Carsten, D., & Timo, K. (2004, June). An Evaluation of the Usage of Agile Core Practices. Retrieved Febuary 18, 2011, from How they are used in industry and what we can learn from their usage: http://www.bth.se/fou/cuppsats.nsf/all/807abbdae15662afc1256eb500403a8f/$file/Master%20The sis.pdf Craig, L., & Victor, B. R. (2003, June 18). Iterative and Incremental Development: A Brief History. Retrieved Febuary 6, 2010, from http://www.craiglarman.com/wiki/downloads/misc/history-ofiterative-larman-and-basili-ieee-computer.pdf Henrik, K. (2007). Scrum and XP from the Trenches - How We Do Scrum. USA: C4Media. Jim, H. (2001). History: The Agile Manifesto. Retrieved February 19, 2011, from Manifesto for Agile Software Development: http://agilemanifesto.org/history.html Kevin, A. (2005). Managing Agile Projects. Canada: Multi-Media Publications Inc. Marco, M., & Martin, V. v. (2008, August 12). InfoQ. Retrieved Febuary 18, 2011, from Case study: Distributed Scrum Project for Dutch Railways: http://www.infoq.com/articles/dutch-railway-scrum Pekka, A., Michele, M., & Frank, M. (2009). Agile Processes in Software Engineering and Extreme Programming. Springer. Principles behind the Agile Manifesto. (n.d.). Retrieved from http://agilemanifesto.org/principles.html Scott, B. (2005). The Art of Project Management. USA: O'Reilly Media, Inc.,. Steward, B. (2002). Sams Teach Yourself Extreme Programming in 24 Hours. Sams Publishing. Szalvay, L. (2008, September 25). Scrum: Where Did It Come From? Retrieved Febuary 18, 2011, from Projects@Work: http://danube.com/news/Scrum_Where_Did_It_Come_From Xebia. (n.d.). Mind te Gap! The Agile Approach to offshoring. Retrieved Febuary 18, 2011, from http://www.xebia.com/distributed-agile Page 17 of 17