Get certified - Transform your world of work today


Is Agile Project Management Fit for Small Tech Start-Ups?

Agile approaches to project management

17 February 2017


Agile approaches to project management have become popular in information systems (IS) today. Agile methods are an alternative to the old-style software development approaches such as the Waterfall model. The wide adoption of Agile approaches to software development is attributable to their recognition of the interaction of people and the development team as the main factor influencing project success, combined with an intense emphasis on efficiency and maneuverability (Cockburn & Highsmith, 2001).

Central to the Agile framework is the use of incremental and iterative development processes (Yau & Murphy, 2013).

Figure 1: Iterative incremental software development life cycle. Retrieved from Satzinger, Jackson, and Burd (2016).

The aim of Agile is to plan out and deliver small portions of the project at a time, rather than defining and documenting the whole project during the planning phase as in the waterfall SDLC. However, Agile will follow phases similar to those in Waterfall, but with loops between the phases. According to Yau and Murphy (2013), the Agile development process begins with the basic set of deliverables, followed by planning, implementation, and testing of other components in the subsequent iterations, as illustrated in Figure 2.
Figure 2: Iterations in agile project management life cycle. Retrieved from Wysocki (2009).

Figure 2 shows the iterations of the project. Each phase in Figure 1 is characterized by the iterations illustrated in Figure 2. As such, the focus in Agile software development is on short deliverables that are tested before proceeding to the next step, rather than testing the products at the end of the project. This practice helps to keep bugs and code errors minimal throughout the project life cycle. Agile has proven to be very useful in complex projects surrounded by significantly high levels of uncertainties, and it has been widely adopted in big organizations. The current paper discusses Agile approaches, mainly Scrum and extreme programming, and critically assesses the possibility of effective applicability of the Agile framework in small enterprises.

Principles of Agile project management approaches

Agile approaches to software development are built on 12 principles. These include:
  1. Satisfaction of client through early and incremental delivery of high-quality software. This is achieved through proper contractual relationship between the development team and the client, and incremental iterations, where client can use some deliverables of the project at the end of early iterations (Stare, 2013). As such, successive iterations are considered to add value to the software, which encourages clients to prolong the project. However, this is possible in certain projects, especially those involving a high level of uncertainties.
  2. Harness change, even in late development, to increase the customer’s competitiveness. Agile allows changes to the project scope at any stage of the project life cycle. This feature is beneficial especially when the project is complex, making identifying and defining all project risks impractical before its initiation.
  3. Incremental development of the software. This principle requires that the project team deliver working software at short intervals.
  4. Collaboration of the project team and the client throughout the project life cycle. Engagement of customers in the software development is to ensure that the developers clearly understand the requirements of the product while allowing clear communication of changes during the software development.
  5. Offer support and provide a conducive environment for the developers. This principle relates to the motivational theory.
  6. The most effective method of communicating within a development team is face-to-face communication. This principle requires project team members to have strong interpersonal verbal communication skills.
  7. Functional software is the main measure of progress. Based on this principle, Agile approaches focus on deliverables of the iteration. This helps the developers avoid delivering a nonfunctional product at the end, which is the greatest risk in software development.
  8. Agile promotes sustainable development.
  9. Continuous focus on technical excellence and excellent software design enhances agility. This means that agility demands developers with high technical know-how to allow Agile thinking (Stare, 2013).
  10. Simplicity in planning the iterations. This principle is made to ensure efficient achievement of the iteration goals.
  11. The best system architectures and designs develop from self-organizing teams. This principle suggests that development team is able to organize their work without the intervention of the project manager. In other words, autonomy of the development team may lead to an excellent job.
  12. Regular review of the software improves the effectiveness of the team. This principle requires the developers to review the software at intervals so as to adjust its work accordingly.

Agile project management approaches

Several frameworks exist to meet the needs of Agile project management. Some Agile software development approaches include Scrum, extreme programming, DSDM, Crystal, feature-driven development, adaptive software development, and pragmatic programming (Stare, 2013). This paper will focus on Scrum and extreme programming approaches.


Since Scrum began to emerge in the 1990s (based on earlier ideas put forth in 1986), it has become one of the most widely used Agile approaches to software development. Scrum is inspired by empirical inspect-and-adapt feedback loops to address project complexity and unforeseeable risks. To achieve this, Scrum follows iterative and incremental product development framework. In this approach, the software development process is divided into short iterations called sprints.

The development process involves three stages: pre-sprint planning, sprint, and post-sprint meeting (Yau & Murphy, 2013). During the pre-sprint planning, the project team identifies and selects features and functionalities from a backlog. Also, planning and prioritization of the collection features is done at this stage. In the sprint stage, the development team selects the features it wishes to work on and starts the development process. The project team holds a meeting every morning to ensure effective communication between the development team and the product manager. A sprint lasts one to six weeks (Yau & Murphy, 2013). Importantly, the product is maintained in a shippable state throughout the project life cycle. In other words, the product is properly integrated and tested throughout the project life cycle. The product is reviewed after every sprint during the post-sprint meetings.

Scrum roles
Scrum has three roles: ScrumMaster, product owner, and development team. The ScrumMaster serves as the process owner and process manager. He or she ensures that all project activities are understood and supports the team through facilitation and coaching. Therefore, the core responsibility of the ScrumMaster is to remove any obstacle that may hinder the project team from achieving its sprint goals (James, n.d). This makes achieving each sprint’s deliverables realistic and visible to the product owner.

The product owner is the custodian of the project functionalities. He or she gives the requirements of the product in line with the organization’s needs (James, n.d). As such, the product owner is engaged with the development team to continuously communicate the needs of the product. Interestingly, it is sometimes difficult to strike the right balance of product owner involvement, because this model encourages team self-organization, while also demanding the presence of the product owner to respond to arising questions from the team.

The development team is the third role of Scrum. Its responsibility is to transform product requirements into deliverables that build a potentially releasable product. Usually, the development team is a small (3 to 9 members), self-organized, and cross-functional unit that jointly accounts for its work. For software development projects, a typical team will include software engineers, architects, a systems analyst, programmers, a quality assurance expert, and testers (James, n.d).

Applicability of Scrum in small enterprises
The roles and processes of Scrum may have several benefits to small enterprises. First, the daily meetings can improve communication between the project manager and the development team members (Yau & Murphy, 2013). Effective communication between the project team members and project manager may decrease time and cost due to possible communications. Additionally, effective communication can result in a high-quality product, since excellent software can be designed only when each member of the development team understands the overall scope of the project and how other members are implementing certain aspects (Yau & Murphy, 2013). Given that project scope in small start-ups tends to change more than in large enterprises (Yau & Murphy, 2013), changes to the software structure should be well communicated to achieve high-quality software.

The pre-sprint planning, on the other hand, helps the project team narrow down their activity list and concentrate on the immediate goals. This feature is essential to small enterprises because the end product is often not completely defined; thus, it is very easy for the development team to get trapped in the development of too many features, rather than focusing on the critical features (Yau & Murphy, 2013). By dividing the tasks into sprints, the development team can focus on iteration goals and deliver main features in a wise progression.

Extreme programming

Extreme programming is the other widely used Agile software development approach. It is based on dynamism of project requirements, short development cycles (Yau & Murphy, 2013), virtual teams, changing technologies, and collaborative participation of all stakeholders in project development (Thomsett, 2002). According to Thomsett, the relationship between the product owner and the project team is critical to project success when using this approach.

Extreme programming follows a test-driven development process and emphasizes that the programmers write acceptance test for the code before implementing the features, with benefits in software development that cannot be overstated. Writing the test cases before implementing features helps to determine whether the features fulfill the specifications as defined, before project initiation (Yau & Murphy, 2013). Again, test-driven development helps reduce bugs and code errors. Further, writing test cases before implementing the features helps to easily determine whether changing parts of the code will affect other sections by simply running the test suite. Overall, extreme programming increases the quality of the product and decreases the time and cost associated with debugging at the end of the project.

Applicability of extreme programming in small enterprises
Despite extreme programming promising to yield high-quality product, it has limited applicability in small enterprises, for several reasons. First, small-scale enterprises have a limited number of software developers. Notably, developers in small enterprises and small start-ups are constantly changing (Yau & Murphy, 2013). Therefore it is not worth spending much time in writing comprehensive test cases for all features before implementation. It is possible that the client may change their requirements before writing the test cases is complete, rendering such tests useless.

Second, it is common for small start-ups to ask for a few features as prototypes, to test some ideas so as to make their final decisions. In this scenario, it is not reasonable to write all the test cases. It is more meaningful to implement such prototypes quickly so as to speed up the decision-making process (Yau & Murphy, 2013). As such, the use of extreme programming in small start-ups is limited.

Third, extreme programming is limiting for small start-ups due to shortage of funds. Most small-scale enterprises will focus on the minimum viable product rather than the quality of the product (Yau & Murphy, 2013). All they may need is simply a functional product to present to investors. If an enterprise decided to fund extreme programming and a close competitor released a similar product first, much of its product may not retain monetary value (Yau & Murphy, 2013).

Another aspect that limits the applicability of extreme programming is its focus on pair programming, which requires two programmers to write code together on the same computer (Yau & Murphy, 2013). Pair programming is used to write better code. The idea is that when two developers are combined, they are likely to share knowledge and produce high-quality code, in addition to setting up collective ownership of the code. However, small start-ups may not reap the benefits of pair programming. First, they have a limited number of developers; second, they are significantly challenged by constraints of time and cost; thus, improving the quality by doubling the cost (hiring of a second developer) could be impossible for small enterprises. Again, the small number of programmers dictates that each developer is assigned to a particular area, making it extremely difficult to enjoy the benefits of pair programming.


Agile approaches to project management offer alternatives to traditional software development approaches such as the Waterfall model. Agile approaches divide project activities into iterations, with a primary focus on incremental delivery of the product. Scrum and extreme programming are typical examples of Agile approaches to project management. While such approaches have become highly popular in the IS field, their applicability in small start-ups varies. Small start-ups are faced with cost and time constraints that can make some Agile practices challenging to manage. In particular, extreme programming can be difficult because constantly changing requirements may render early test cases useless, and small company size may make it impractical to implement pair programming.

  • Cockburn, A. and Highsmith, J. (2001). Agile software development joins the “would-be” crowd. Cutter IT Journal, 34(9), 122.
  • James, M. An empirical framework for learning (not a methodology). Scrum Methodology,
  • Satzinger, J., Jackson, R., Burd, S. (2016). Systems Analysis and Design in a Changing World. Cengage Learning.
  • Stare, A. (2013). Agile project management — a future approach to the management of projects? Dynamic Relationships Management Journal, 2(1), 43–53.
  • Thomsett, R. (2002). Radical Project Management. Prentice Hall PTR.
  • Wysocki, R. (2009). Effective Project Management: Traditional, Agile, Extreme (5th ed.). Wiley Publishing.
  • Yau, A., and Murphy, C. (2013). Is a Rigorous Agile Methodology the Best Development Strategy for Small Scale Tech Startups?

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 5 (1 ratings)


Be the first to add a comment...

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up