Agile Software Development Bottleneck

Published Date: 02 Nov 2017

Abstract

Agile software development method became a common and successful software development method. Accordingly identify the weak link in agile software development methodologies will help organization to implement agile methods successfully. In this regard four agile methodologies (Extreme Programming, Lean software development, Scrum, and Feature Driven Development) selected and analyzed. Principle of each of these methods and principle of general agile compared to find the possible bottlenecks in agile through finding the mismatch between them. The results could be useful for companies that implement agile methods as development method.

Keywords

Agile Software Development, Bottleneck, TOC, Agile methodologies, FDD, Lean software development, XP, Scrum

Table of Content

Table of Figure

List of table

1. Introduction

These days, speed and change in business are increasing day by day thus faster and cheaper development software with higher quality is required to adapt easily to perpetual changes. Software development methods that used in this regard are agile. Agile has deferent methods each of which has its own approach but same goal (Misra, et al., 2007). Many case studies look into when agile works (Rasmusson, 2006; Augusitine, et al., 2005; Pool, 2006) and other researchers are about finding a way to fit the agile for large companies or how to manage needs and requirements in agile process (Lindvall, et al., 2004; Cao & Ramesh, 2008).

Since every development method has limitation in process, identifying such weaknesses enable organizations or developers particularly to gain more benefit from development methods. Certainly agile is not an exception and has bottlenecks which reduce its productivity (Zultner, 2002). In this paper Scrum, XP, FDD, and Lean software methodologies are chosen to be investigated and find the weak line in each method to achieve an overall model. Theory of Constraints (TOC) used as an analytical tool to find possible weakest line in agile software development projects.

2. Background

Kent Beck and 16 other software developers, writers and consultants signed the manifesto for agile software development in 2001. Agile software development is a combination of philosophy and development guidelines to simplify the process, fast delivery, increase the motivation of teams, and finally satisfy customers XP, Scrum, Feature Driven Development (FDD), Lean, and DSDM are examples of agile methodologies (Pressman, 2010).

Moreover most agile methods attempt to minimize risk by developing software in short time boxes, called iterations. Each iteration includes planning, requirements analysis, design, coding, and documentation that provide new software at the end (Rizwan Jameel Qureshi, 2012). Overall agile methodology is significantly important in software development with regard to geographical scope and development process to achieve cost efficiency and improve customer satisfaction (Sriram & Mathew, 2012).

In agile, the size of projects is comparatively small with high level of customer involvement and documentation. Oral communication among team members is required by agile activities which are flexible to changes in requirements by customers (Keramati & Mirian, 2008).

3. Problem Statement

According to (Zultner, 2002) every process has a limitation which prevents organizations to increase its product manufacturing which is the main goal of any organization. The research (Sriram & Mathew, 2012) has shown that among all development methods agile is used more in organizations. Accordingly this paper concentrated on creating a model to identify weakest link in agile methodologies.

4. Scope

Explain the reasons of choosing TOC as a tool to identify bottlenecks.

General definition of agile software development and its methodologies to get wide overview of different agile methods.

Present the principle of agile method to compare them and achieve objectives

5. Objective(s)

Identifying the bottlenecks in agile software development method.

Identify the possible bottlenecks in four selected agile methodologies

Literature Review

6. Theory of Constraints

Theory of Constraint (TOC) is a management tool developed by Dr. Eliyahu M. Goldratt in 1980s based on the resource limitation in the organization which was applied for production and manufacturing operations management. He considered any enterprise and organizations as a limited system. To increase efficiency this weakest link should be eliminated (Zongxiang, 2008).

Goldratt’s introduced concept of TOC in the book "The Goal" (Goldratt & Cox, 2004), and extended the application of TOC to marketing (Goldratt, 1994), project management (Goldratt, 1997) and supply chain management (Goldratt, et al., 2000; Xu & Xu, 2010). The TOC principle focused on five steps (Ray, et al., 2007):

Identify weakest link in a system

Decide how to deal with them

Add all other limitation to the decision

Enhance identified constraint

If constraint has been eliminated during previous steps go to the first step.

Removing or breaking down the identified bottlenecks will surely influence internal activities or decrease their efficiency but on the other hand the manufacturing of a system will be totally increased.

As Goldratt (1997) said: TOC process is based on answering these three questions: what to change?, what to change to?, and how to cause the change?

6.1. TOC Principals

The principals of TOC were defined by Dettmer, (1997) to identify the weakest link in any organization. These principals are as follow:

TOC considers every system as a chain for example all that has to be carried out in sequence in a project. Every chain has bottlenecks or further has just one bottleneck in a particular period of time.

There is a cause and effect relation in any systems presented as trees. TOC apply cause-effect relation to illustrate complex environment. An example of cause-effect tree has shown in figure 1.

Figure : cause- effect tree

This tree means, every educated person should have practical experience and theoretical knowledge as well as essential tools to be a right person for coding. In other word, all the lower branches of trees should be achieved before higher branch.

Through cause-effect tree, core problems and undesirable effects will be identified. For example in figure 1 lack of enough education is an undesirable effect but lacks of enough experience or theoretical knowledge are core problems. Undesirable effects never cause to core problems and removing them cannot be considered as solving a problem. While removing the core problem lead to remove undesirable effect as well.

TOC divided the bottlenecks in two categories, Physical bottlenecks and policy bottlenecks. Those are proportionally easy to find and solve are physical bottlenecks. However most of the bottlenecks that exist in the system are policy ones. In fact policies and rules in organization will lead to physical bottleneck.

6.2. The Five Focusing Steps

TOC used five-step process to eliminate or break down system constraint. Plus TOC usually focus on using framework as a guideline for team members to find their organization more responsive to fulfill customer requirements to compete with their rivals in competitive market (Goldratt, 1992). Chou, et al., (2010) holds that these steps enable management to concentrate on factors that are essential for successful system performance in purpose of achieving organizational goals. Chou listed these five steps in a table as shoen in table 1.

Table -The five focusing step in TOC

TOC Five Focusing Steps

Explanation

Meaning in managerial practice

Step 1:Identify the constraint

Determine the system activity whose capacity is less than the demand place on it.

System constraint may be rise from internal (organization’s resource, capability, or policy) or external (business cycle, customer preference).

Step 2: Exploit the constraint

Maximize the efficiency of the constraint activity in its existing system configuration.

Eliminate all waste or nonproductive time or activities at the constraint.

Step 3: Subordinate all else

Synchronize the operation of all other system components with the constraint activity.

Use new process to manage the resource which is not be used efficiently.

Step 4: Elevate the constraint

Increase the capacity of the constraint activity to eliminate it as the constraint.

Acquire additional resources to increase constraint capacity.

Step 5: Return to step 1 but prevent inertia.

Revise all changes to ensure that they still support current system configuration.

Preventing inertia means examining the new system configuration to ensure that the changes implemented in managing the prior constraint remain appropriate.

6.3. Why TOC?

According to table 1, there is four reasons to choose TOC as a tool to identify weakest link in agile methods. First, Base on TOC principles look at agile software development as a system. Second, TOC principals provide modeling agile software development into cause- effect trees. Third, importantly these principals lead to find main bottleneck. Finally, TOC identify the core problems vs. undesirable effects and policy bottlenecks vs. physical bottlenecks.

7. Agile Software Development

7.1. The Agile Software Development Process

Despite of plan-based methods such as waterfall that focuses on plan phase in it the process, agile methods focus on customer. Agile processes help developers to change requirements during development cycle and consist on collaborate with customers and continuously product delivery (Cohn & Ford, 2003).

Figure : Agile Software Development Process

According to Pressman (2010) the manifesto for Agile Software Development signed and introduced in 2001involved main value of agile:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

As it can be clearly seen in figure 2, agile software development process is and iterative process where all of the phases are interconnected and each of them will provide feedback for others and all phases keep evolving (Bohem, 2002).

The Agile manifesto comprises twelve principles (Lehman & Sharma, 2011):

The highest priority is to satisfy the customer through and continuous delivery of valuable software.

Welcome changing requirements, even late in development process. Agile processes harness change for the customer’s competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Working software is the primary measure of progress.

Continuous attention to technical excellence and good design enhances agility.

Simplicity – the art of maximizing the amount of work not done – is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

These principles are used to identify core problems (bottlenecks) of agile software development methods in this paper.

7.2. Agile Software Development Methodologies

Below is a list of some of the agile methodologies:

Extreme Programming (XP)

Industrial Extreme Programming (IXP)

Scrum

Agile Modeling Adaptive Software Development (ASD)

Crystal Clear and Other Crystal Methodologies

Dynamic Systems Development Method (DSDM)

Feature Driven Development (FDD)

Lean software development

Agile Unified Process (AUP)

Dialogue-Driven Development (aka d3)

Some of these methodologies follow the principles of agile. In this paper based on the sixth annual survey of VERSIONONE ,(2011) that brought in appendix four of these methodologies have chosen for further analysis. They are XP, Scrum, Lean software development, and FDD. More over they have different proceed toward agile goals. For example FDD encourages an upfront architectural modeling (Highsmith, 2002) or Lean development reduces the development timeline (Tomaszewski, et al., 2008). The four chosen methods are explained in the following parts and principles are presented in cause- effect tree.

7.2.1 Scrum

Based on VERSIONONE (2011) Scrum (52%) or Scrum/XP Hybrid (14%) has the largest percentage in being used compare with other agile methods that provides a management framework. Highsmith, (2002) thought that Scrum is a complex process in which software, stakeholders, and organization interact with each other. Scrum needs minimum one daily integration and regression test of the code.

Scrum has four main phases in the process planning, Staging, release. Vision and expectations of a project and assigning the budget set in planning phase. In addition, the project is divided into sprints each of them are 30 days. Requirement will be identified and sprints will be prioritized in staging phase. System will be implementing in sprints and will be prepared for release in development phase. Moreover in this phase team members choose the task during 15 minutes standup meeting. The system should be put into action to provide feedback after each sprint to set the future directions (Laman, 2004).

Scrum principle are exactly same as with the agile manifesto and focuses on using a set of software patterns each of which defines a set of development actions such as Backlog, Sprint, Scrum meetings, and Demas (Pressman, 2010).

Backlog: It is a prioritized list of project features and requirements that lead to deliver value to customer. This list is changeable items can be added or remove at any time therefore priorities will be updated as required.

Sprints: All needed activities to achieve requirement determined in backlog within predefined time-box. No changes will be made here therefore team members can work in a stable environment.

Scrum meetings: These are short every day meetings that enable members to know how much project is progressed?, what obstacles faced with?, and what do you plan to carry out before next meeting.?

Demos: in this phase software has delivered to customer to be evaluated. However all predefined functionality may not exist in Demos.

scrumbig.jpg

Figure : Scrum Process (The TEAM INTERNATIONAL, 2012)

Other principle of scrum that is needed to achieve successful scrum project are as followed (Sommerville, 2007):

The product backlog is set; product owner is assigned to make the future communication easy in pre-planning.

Product backlog should be priorities, task list should be set, and team members and product owners must plan how to achieve iteration results (Sprint planning).

Working environment is needed for working closely and preferably in a working environment (Common room).

Blocks gone in one day are those tasks that finished from one scrum to another in one day.

Scrum manager activity to ensure that there is no undesirable activities (Scrum master firewall).

Priorities chosen in sprint planning phase thus if extra work added some other low priority work should be removed (Lock priorities within sprint).

There is sprint meeting particularly for review and present the demo of product as well as providing feedback and set the future directions within the meeting (Sprint review).

Decision making process is just one hour and decision can be avoided (High level decision).

Team members have authority and required tools and resources to find the best way to achieve sprint goals, identify the problems and solve those (Self-directed and self-organizing teams).

No more than seven people to reach efficiency and peaceful or politic communication (Team of seven).

Below cause-effect tree based on all principle that explained before to have successful Scrum project is presented.

scrum tree.png

Figure : Scrum Principles

7.2.2 Extreme Programming (XP)

Extreme Programming is one of the most known agile software development methods developed by Beck in 1996 (Li-li, et al., 2011). Moreover according to VERSIONONE (2011) 14% of organizations use Scrum/XP hybrid as a system development in their project which is in second place after Scrum.

Same as spiral development methods, XP can be divided into small and simple cycles, further positive communication, and feedback are the strong link of XP that help developers and customers control changes, problems and difficulties (Zhou, 2010).

Communication between clients and developers in one side and communication between customers and developers on the other side are noticed and considered as important factors in XP. Effective communication would help developers to resolve issues for both sides. Simplifying the tasks also allow developers to finish the task without wasting too much time on unreal tasks. Iterative feedback from customers enable developers to know about the customers’ need when the face with problems (Krishna, et al., 2012).

XP activities has illustrated in figure 5. In XP development methods, the commencement of process is planning phase. The technical team assesses the feasibility of the project, required effort and schedule for fist release; all should be done in this phase. Then most precious features which need to be developed will be defined by customers and presented as storied (Cao, 2006).

Simple design will be supported in XP, to do so; XP focuses on applying refactoring techniques (removing repeated code). Design, implementation, and testing of the system (unit testing) should be performed by a Pair of Programmers sharing one computer in XP process. As a result programmers have more time to find solutions for problems and also avoid debugging (Han & Zhou, 2009). Moreover the story functionality will be verified by automated test and the correctness of the story will be tested by unit testing. The work on story will continue to find it defect free. Integration tests will be done to verify that the overall behavior of system is defect free. This testing process will be finished with acceptance test which means current system would satisfy customer (Tian, 2005).A coding Standard is also used to ensure that same design and coding convention is used by development team (Qasaimeh, et al., 2008).

XP.png

Figure : Extreme Programming Principles (Qasaimeh, et al., 2008)

Cause-effect tree for XP has depicted in figure 6.

XP cause-effect.png

Figure : Cause-effect tree for XP

7.2.3 Feature Driven Development (FDD)

Feature Driven Development introduced in 1997 by Jeff De Luca and Peter Coad to work in a project at United Overseas bank in Singapore. They published a brief outline of FDD in 1999 in a book named "Java Modeling in Color with UML". FDD is an agile development method with two concentrated stages. In first stage, the list of features that will be used in next stages is critical stage of FDD. The exactness of project tracking, maintainability, and extensibility of code is depending on the level of quality of activities done in first stage. Customer involvement is one of the characteristic of this stage (Chowdhury & Huda, 2011) .

The FDD approach focuses on design and building stages and no specific process is required. Though FDD evolves five processes and provides the methods, techniques, guideline, roles, artifacts, goals, and timeline that are needed for a successful project (Palmer & Felsing, 2002). Figure 7 has illustrated process of FDD.

FDD process.png

Figure : Feature Driven Development Process (Palmer & Felsing, 2002)

Every stage of FDD process explains briefly according to (Abrahamsson, et al., 2002):

Develop an Overall Mode:

Domain experts are aware of the scope, context and requirements of the system when this phase starts. Use cases, functional specifications, walkthrough documented and the overall domain divided into different domain areas in develop an overall model, too. Then development team deliberates to choose the appropriate object models for each domain areas.

Build a Features List:

Feature list will be built based on the walkthroughs, object models and documentation provided in first phase. Major feature (functions for each of the domain area) sets in feature list. Validity and completeness of the list will be reviewed by users and sponsors of the system.

Plan by Feature:

Planning by feature comprises the creation of a high-level plan, the classes identified in the first phase are assigned to developers, and schedule and main milestones may be set.

Design by Feature and Built by Feature

These last two phases are iterative procedures during which a small patch of features selected and developed. Each iteration will take maximum two weeks and include tasks such as design inspection, promote the completed features to the main build.

FDD.png

Figure : The Design by Feature and Build by Feature Process of FDD (Palmer & Felsing, 2002)

FDD entail the following practices (Abrahamsson, et al., 2002):

Domain object Modeling: Investigation of the domain of the problem.

Developing by feature: Developing and tracking a process by a list of small functionality.

Individual Class Ownership: Consistency, performance and conceptual integrity of the class will be controlled by a single responsible person in each class.

Feature Teams: A process encouraging doing something before one chosen to carry out the task.

Inspection: Using the best defect detection techniques to identify the core problems and defects.

Regular Builds: A process to ensure that system is always running and also remove the problems in early phases in the process.

Configuration Management: A process to find an easy way to identify and change the latest version of each finished source code files and other artifacts of the project.

Progress reporting: A process of report completed works in any organizational level or any achieved progress.

FDD Practices.png

Figure : FDD Principle

7.2.4 Lean Software Development

Lean Software Development is an iterative process includes preparation, planning, implementation, and assessment. In preparation phase, backlog of prioritized features will be assembled. In planning phase, estimate how long development, test, documentation and deployment will take. Test techniques, features, that selected and picked in planning phase will be implement in this phase and team members hold 10-15 minutes meetings to know what is accomplished by each member since the last meeting and what should be done till next meeting. These meetings are in purpose of informed customers about added value to the product and take feedback from customer to make required changes (Palmer & Felsing, 2002).

Same as other agile methodologies Lean software development also has its own principle. These principles can be considered as a guideline to achieve and deliver software faster, better, and less cost (Poppendieck, 2007):

Eliminate waste: Remove every function that is not required by the customers or it is not the goal of the project.

Build Quality In: Detecting the defect in early phase in development process and increase the product quality.

Create Knowledge: Implementing the systematic learning within development process to be sure about knowledge sharing.

Defect Commitment: Making the decision in last moment before become too late.

Deliver As Fast As Possible: Fast delivering the software to customer don’t allow them to change their minds.

Empower the Team: Give authority to each person to take responsibility and find solutions.

Optimize the Whole: optimize the whole value to address the customer need.

Lean Principle.png

Figure : Lean Software Development Principle

8. Research Method

In this part the methods that used to collect the data and find the answer to the main research question will be explain (What are the weak links of the agile software development?). To achieve the answer of main question, two more question should be answered first (What is weak links of agile software development methodologies?/ what is the core problems in Lean software development?)

Secondary resource is used in this paper to collect adequate data relate to selected agile methodologies. Plus case studies of companies such as Ericsson Company, Mexican Airline, Toyota, BBC Worlwide that implement agile and use TOC to find the problems. Moreover some surveys which done by VERSIONONE in 2011 and The Economic Times in 2012 is also used (lack of time to do it by ourselves).

9. Results and Analysis

This section contains the comparison between principles of analyzed agile development methods and general agile software development principles. It enables us to find the possible high level bottlenecks in each analyzed software development methodologies.

9.1 Weak links might exist in agile software development

Creators of different software methods had a meeting and agreed on agile Manifesto in 2001. It is considered as core value of agile software development (Pressman, 2010). All the principles of agile development are accepted as is in this paper and all should be addressed in order to have successful agile software development. The comparison of principles and practices of each method which describe in previous sections; accordingly it can be identified that how each principle is addressed in different methods. Through this comparison it can be understood that there are gaps where there is no connection between principle or practice of agile method and general agile principles. Such gaps considered as a high level bottlenecks of agile development method that can be addressed indirectly by other principles.

Base on this comparison and identified gaps we can also find high level bottlenecks in each agile development methods. Possible high level bottlenecks of each method are summarized in table 2.

9.2. Possible Weak links of Lean Software Development

Lean software development method does not have principle to address lack of individual motivation. Despite it is an important principle to implement success Lean method thus individual should be motivated and motivation system should be created. Among Lean principle "Empower the team" may proportionally cover the lack of motivation system. Nevertheless leaders should not ignore this possible bottleneck.

Moreover, way of interacting with stakeholders is not defined in Lean. This will be done as a group, it means a team decides how to interact with stakeholders. However, "Create knowledge" principle in Lean needs fast and continuous feedback for continuous learning. Therefore close and frequent communication with stakeholders should be carried out by teams. Even though, poor communication process itself can consider as a potential bottleneck.

Against "face- to- face communication" principle in general agile, Lean just has daily short meetings each of which is 10-15 minutes. It can also be considered as a kind of good face-to-face communication. No pay attention to this principle or selecting time consuming methods will increase the impact of Lack of face-to-face communication.

The main objective of agile development is simplicity. Thus lack of simplicity might be the most difficult bottleneck to break. The reason is Lean focuses on improving different process parallel and it has managerial view rather than technical view. Therefore all team members should understand the process and goals of Lean and follow the responsively.

9.3. Possible Weak links of Extreme Programming (XP)

General agile development method focuses on frequent interaction with stakeholders, means customers, product manager, sponsors, and others involved, but XP just focuses on interaction with customers ("On site customer" principle). This definitely is a possible bottleneck for XP method. In addition, XP does not have any principal regard to how team should improve the process. This bottleneck is hard to break because XP concentrate on technical development activities.

9.4. Possible Weak links of Scrum

In Scrum there is no "ON site customer" principle because it is not required, customer is just prioritize the Sprint backlog. Nevertheless there is no communication with other stakeholders in Scrum software development. Accordingly it is absolutely high level bottleneck for Scrum.

In Scrum measures exist to show that tasks are already finished but no measure exist to know if it is accepted by customer. Therefore lack of project progress measurement can be a possible bottleneck for Scrum.

9.5. Possible Weak links of Feature Driven Development (FDD)

FDD principles are not about customer satisfaction against general agile principle. FDD focuses more on implementing requirements and success means accomplished ones not those accepted by customers. This is a possible bottleneck.

Moreover team motivation is an important principle for project success. In FDD for each iteration, different feature teams are formed therefore people have to switch between these groups frequently. In such environment motivate team member can be an big issue. As a result developers face lack of team member motivation in FDD.

There is mismatch between progress measurement in general agile software development and FDD progress measurement. FDD measures project progress by implemented features not accepted features by customers. There is no review and making change due to customer requirements. Plus "Individual class ownership" principle in FDD decreases face-to-face communication because each of team members responsible for his class consequently no needs to communicate. Therefore lack of progress measurement by working software and lack of face-to-face communication are the possible bottlenecks for FDD.

"Maintain constant pace" principle in general agile development method provide sustainable development and it is the responsible of all stakeholders. However this point is not considered in FDD there is no way to know how the knowledge should be shared. Implementing continuity process helps developers to decrease the impact of lack of continuity. Further FDD is designed for large project thus it has complex process while agile development extremely focused on simplicity. Moreover a reflection and improvement system should be initiated in FDD as well to decrease the impact of lack of reflection and adjustment to improve.

To be in short to implement a success agile software development, managers should keep in mind the identified bottlenecks in each method. Some bottlenecks such as lack of team motivation, lack of customer satisfaction were common in different methods.

Table : Identified Possible High Level Bottlenecks in Agile Software Development Methods

Agile Software Development Method

High Level Bottlenecks

Relate Principle

In General Agile Development

Cover Principle in Specific Method

Type of Bottleneck

Lean Software Development Bottlenecks

Lack of motivation for individuals.

Motivate individuals

Empower the team

possible

Lack of frequent interaction with stakeholders

Interact frequently with stakeholders

potential

Lack of face-to-face

communication

Face-to-face communication

Short stand up meetings

possible

Lack of continuity

Maintain constant pace

Create knowledge

possible

Lack of simplicity

Simplicity

Hardest possible bottleneck to break

Extreme Programming (XP)

Lack of frequent interaction with stakeholders

Interact frequently with stakeholders

On site customer

definitely

possible

Lack of reflection and adjustments to improve

Reflect and adjust continuously

No principle to address this principle directly.

Indirectly: Simple design and pair programming

Hardest possible to break

Scrum

Lack of frequent interaction with stakeholders

Interact frequently with stakeholders

Sprint planning

Definitely possible

No project progress measurement by working software

Measure by working software

No principle

possible

Feature Driven Development

Lack of customer satisfaction

Satisfy the customer

Setting features and implementing them successfully

possible

Lack of motivation for individuals.

Motivate individuals

Feature team

possible

No project progress measurement by working software

Measure by working software

Implemented features may not accept by customer

Mismatch with general agile principle.

(possible)

Lack of face-to-face

Communication

Face-to-face communication

possible

Lack of continuity

Maintain constant pace

Lack of simplicity

Simplicity

Possible and should not be ignored

Lack of reflection and adjustments to improve

Reflect and adjust continuously

Reflection and improvement system should be created

Without related principle, breaking this bottleneck is impossible

10. Conclusion

Agile software development enables organizations to respond changing market so fast. According to VERSIONONE, (2011) in appendix, agile software development are using successfully by the organizations. The knowledge of people involved in agile methodologies has been also increasing. Despite all different between agile methodologies there are common values such as user involvement is vital to success, build and release software in small increments, attention to quality and excellence, and conformance to standard.

In this paper principle of Theory of Constraint (TOC) is used to find the bottlenecks. All identified bottlenecks in different agile software development methods should be noticed during implementing the method. To find these bottlenecks first the principle of general agile method and then principles of four selected agile methodologies is presented. Second, bottlenecks of general agile development method are identified by comparing the general agile principles and principles of agile methodologies. Gaps or mismatch between these two is considered as possible bottlenecks which was the purpose of this paper.

References

Abrahamsson, P., Salo, O. & Ronkainen, J., 2002. Agile Software Development Methods Review and Analysis. Oulu: VTT Publications 478.

Anon., 2012. TEAM INTERNATIONAL. [Online]

Available at: http://www.teaminternational.com/scrum_development_methodology.html

[Accessed 20 January 2013].

Augusitine, S., Scencindiver, F. & Woodcock, S., 2005. Agile Project Management: Steering From The Edges. Communications of the ACM, 48(12), pp. 85-89.

Bohem, B., 2002. Get Ready for Agile Methods, With Care. IEEE Comuter Society, Volume 35, pp. 64-69.

Cao, D.-B., 2006. An Empirical Investigation of Critical Success Factors in Agile Development Projects. USA: Phd thesis Capella university.

Cao, L. & Ramesh, B., 2008. Agile Requirements Engineering Practices: An Empirical Study. IEEE Software, 25(1), pp. 60-67.

Chou, Y.-C., Lu, C.-h. & Chang, P.-L., 2010. Using Theory of Constraints to Find the Problem about High level Inventory in the Aerospace Industry. IEEE Conference Publications, pp. 1-10.

Chowdhury, A. F. & Huda, M. N., 2011. Comparison between Adaptive Software Development and Feature Driven Development. International Conference on Computer Science and Network Technology, Volume 1, pp. 363-367.

Cohn, M. & Ford, D., 2003. Introducing an Agile Process to an Organization [software development]. IEEE Computer Society, 36(6), pp. 74-78.

Dettmer, H. W., 1997. Goldratt's Theory of Constraints A System Approach to Continuous Improvement. s.l.:ASQC Quality Press.

Fowler, M., Beck, K. & Brant, J., 1999. Refactoring: Improving the Design of Existing Code. s.l.:Addison-Wesley.

Goldratt, E. M., 1992. The Goal. 2nd revised ed. s.l.:The North River Press.

Goldratt, E. M., 1994. It's Not Luck. Aldershot: The North River Press.

Goldratt, E. M., 1997. Critical Chain. forth ed. US: The North River Press.

Goldratt, E. M., Schragenheim, E. & Ptak, C., 2000. Necessary but Not Sufficient. s.l.:the North River Press.

Han, Y. & Zhou, Y., 2009. Agile Software Development Methods and Extreme Programming. Science & Technology Information, Volume 14, pp. 199-200.

Highsmith, J., 2002. Agile Software Development Ecosystems. s.l.:Addison-Wesley.

Keramati, H. & Mirian, S. H., 2008. Integration Software Development Security Activities with Agile Methodologies. IEEE/ACS International Confrenece, pp. 749-754.

Krishna, T., Babu, R., Kanth, C. & Krishna, C., 2012. Quality Assurance Analysis in Extreme Programming. International Journal of Engineering Science & Advanced Technology, 2(1), pp. 76-80.

Laman, C., 2004. Agile and Iterative Development: A Management Guide. s.l.:Addison-Wesley.

Lehman, T. J. & Sharma, A., 2011. Software Development as Service: Agile Experiences. IEEE Computer Society, pp. 749-758.

Li-li, Z., Lian-feng, H. & Qin-Ying, S., 2011. Research on Requirement for High-quality Model of Extreme Programming. IEEE Computer Society, Volume 1, pp. 518-522.

Lindvall, M. et al., 2004. Agile Software Development in Larg Organizations. IEEE Computer Society, 37(12), pp. 26-34.

Misra, S. C., Kumar, U., Kumar, V. & Grant, G., 2007. The Organizational Changes Required and the Challenges Involved in Adopting Agile Methodologies in Traditional Software Development Organizations. Digital Information Management, 2006 1st International Conference, pp. 25-28.

Palmer, S. & Felsing, J., 2002. A Practical Guide to Feature-Driven Development.. s.l.:Prentice-Hall.

Perera, G. & Fernando, M., 2007. Enhanced Agile Software Development – Hybrid Paradigm with Lean Practice. Second International Conference on Industrial and Information Systems, pp. 239-243.

Pool, D., 2006. Breaking the Major Release Habit. ACM Queue.

Poppendieck, M., 2007. Lean Software Development. IEEE Computer Society, pp. 165-166.

Pressman, R. S., 2010. the software process. s.l.:Mc Grow Hill.

Qasaimeh, M., Mehrfard, H. & Hamou-Lhadj, A., 2008. Comparing Agile Software Processes Based on the Software Development Project Requirements. IEEE Computer Society, pp. 49-54.

Rasmusson, J., 2006. Agile Project Initiation Techniques – The Inception Deck &Boot Camp. s.l., IEEE Coputer Society.

Ray, A., Sarkar, B. & Sanyal, S., 2007. An Integrated Theory of Constraints. Industrial Engineering and Engineering Management, pp. 25-29.

Rizwan Jameel Qureshi, M., 2012. Agile Software Development Methodology for Medium and Larg Projects. IET Journals & Magazines, 6(4), pp. 358-363.

Sommerville, I., 2007. Software Engineering. eighth ed. England: Addison-Wesley.

Sriram, R. & Mathew, S., 2012. Global Software Development Using Agile Methodology: A Review of Literature. s.l., IEEE International Conference, pp. 389-393.

The ECONOMIC TIMES, 2012, Need for Speed: More IT Companies Switch to Agile Code Development, [online] available at: http://articles.economictimes.indiatimes.com/2012-08-06/news/33065621_1_thoughtworks-software-development-iterative, [Accessed: 10/1/2013].

Tian, J., 2005. Software Quality Engineering. Dallas: Department of Computer Science and Engineering.

Tomaszewski, P., Berander, P. & Damm, L.-O., 2008. From Traditional to Streamline Development Opportunities and Challenges. Software Process Improvement and Practice, Volume 13, pp. 195-212.

Xu, J. & Xu, X., 2010. Theory of Constraints: A Review of Its Application in Supply Chain Management. ICEE, pp. 4977-4980.

Zhou, L., 2010. Quality Assurance Analysis for Extreme Programming. Computer Applications and Software, Volume 27, pp. 167-168.

Zongxiang, H., 2008. research For Based on the Theory of ConstraintsProduction Sceduling of Discrete Manufacturing Enterprise. IEEE Computer Society, Volume 2, pp. 167-171.

Zultner, R. E., 2002. Critical Chain Project Management: A Third Generation Paradigm Shift for Shorter Projects. SATM Innovation & Technology Management news, 6(1), pp. 1-8.