BOTTLENECKS IN

AGILE STARTUPS
Finding guidelines for students to handle initial
bottlenecks in agile from-scratch projects.

Abstract
During a web development project carried out at Uppsala University, winter 2012, by
twelve students, a number of initial bottlenecks caused many tasks of the first sprint to
“lag” and cause some programmers to idly await the “freeing” of their tasks. Pairing this
case study with literature and a survey this paper reach four conclusions on that and how
this has happened. Further the author provides three logically supported suggestions on
how to provide students of future projects with sufficient guidance as to break the
bottlenecks themselves.
4.965 WORDS
Table of contents
Introduction! 3

Research questions! 3
Method! 3
Scope! 4
The case study & survey! 5
Observed bottlenecks! 5
Confirming existence of bottlenecks! 7

A database example! 7
Eliminating idle time! 8

The problem of the bottlenecks! 10

Results of case study & survey! 10

(C1) Agility in itself does not ward off initial bottlenecks! 10

(C2) Strict role division cause idle programmers at times of bottlenecks! 10

(C3) Not all developers research solutions to others problems when faced with idle time! 10
(C4) Multiple bottlenecks can be addressed simultaneously! 11

Literature review! 12
Having two roles improve both collaboration and result! 12
SCRUM will make team members more helpful! 12

Tasks must be assigned to individuals! 13

Change response is better than planning! 13

Results of literature review! 13

(L1) Willingness to help comes only with experience! 13
(L2) Every decision does not have to concern everyone! 14

Conclusion! 15
Suggestions! 16
(SG1) Shoot first, ask questions later (suggesting a principle)! 16
(SG2) Let somebody else do the job (suggesting a principle)! 16

(SG3) The Renaissance Researcher (suggesting a role)! 16

Discussion! 17
Further research! 17

References! 18
Introduction
During a web development project carried out at Uppsala University, winter 2012, by
twelve students, all fairly new to agile practices, it was noticed how a number of initial
bottlenecks caused many tasks of the first sprint to “lag”. Which consequently not only
caused frustration, but also idleness amongst programmers and members, as well as a
feeling of work being non-agile. This paper looks further into how these bottlenecks, more
efficiently, could have been eliminated.

Research questions
Consequently the questions of interest within this paper regards the idea of eliminating the
initial bottlenecks often found in startup (or: from-scratch) projects. Also, how this
elimination technique can be communicated in a pedagogical manner so students with
little or no industry-experience can “kick-start” as fast as possible.
So, the first question that must be answered is merely whether agile methods in itself is
enough to turn team members into adaptable ninjas in the sense that they can easier
discover and avoid startup bottlenecks.

(RQ1) Will agile methodologies eliminate initial bottlenecks of

a student project?

Secondy, given that the answer to the first question is no, a new way of eliminating these
initial bottlenecks must be found. The author suspect, there are still seeds of ideas within
agile practices that will support an idea of elimination of initial bottlenecks. Consequently
this will be further explored.

(RQ2) If not, can we introduce techniques or concepts that will

aid students in eliminating the initial bottlenecks of an agile
project?

Method
To answer the research questions, this paper use a three-tier method, approaching the
same issues from thee different points of view. The three legs of the method are (1) a case
study based on material gathered throughout the project, (2) a quantitative survey given to
a subset of the students, and (3) literature studies on agile subjects.
Regarding the case study, the author himself was part of the actual project. Issues that the
author has been reflecting upon in retrospect and during the project has been used as a
starting point to formulate the research questions. However, to avoid potential bias, the
further methods have been introduced as to ensure objectivity in the results.
Regarding the quantitative survey, extracts of the questions and answers are represented
inline (for a full review of the survey, please contact the author at christopher.okhravi.
8305@student.uu.se). The survey was conducted as to ensure that what the author
perceived problematic was also by fellow team members (programmers) perceived as
problematic.
Regarding the literature studies, web searches has been conducted. Much of the
reasoning around student behavior is based around another article discussing agility in
student projects, and much reasoning around the concept of agility is based on the Agile
Manifesto. Most references are articles published in IS journals.
Since the case study and the quantitative survey much handle the same topics they will be
reviewed simultaneously.

Scope
This paper will only concern itself with the given research questions within the context of
academia. While it is assumed that small startups with novice team members will be
equally applicable to the results of this study, no conclusions can be explicitly drawn
outside the context of academia.
The case study & survey
The project under study was carried out within the course “Agile Methods”, given at
Uppsala University over the period of two months. During this course the students were
expected to from-scratch carry out a SCRUM project with some elements of XP. The group
consisted of twelve students with essentially no, or little, experience of agile work. Many
also lacked real-world experience of software development in a corporate (or professional)
environment.
To the best of their abilities, and with moderately successful result the students carried out
the work over the course of three weeks, divided into three sprints. The following sections
list and discuss a number of issues that were experienced during the first sprint.

Observed bottlenecks
During the first sprint of the project the team suffered from a number of stacking
bottlenecks. This paper refers to a bottleneck, as the unexpected need to, longer than
expected, maintain work with a specific task, and thus pushing depending tasks into the
future.

Bottlenecks of sprint one

The following section outlines a number of bottlenecks that in retrospect were identified as
problems of sprint one. The order in which they are presented corresponds to the order in
which they were handled in the project. The order does not correspond to any kind of
dependencies between them. The concrete tasks that were delayed (except of course the
next bottleneck in the order) are discussed within each section below.

(BOTTLENECK I) High-level understanding of customer needs

Before the initial code frame could be decided upon, the participants had to actually know
what kind of application was to be created. Even to merely be able to intelligently decide
upon a set of technologies the project team had to have some kind of understanding of the
customerʼs need. Consequently this was a bottleneck for the team to be able to engage in
any other kind of technical work.

(BOTTLENECK II) Identifying an Agile Workflow

Even though the principles and practices of Agile Development, or as in this case -
SCRUM, are not only wide-known and -spread, the concrete implementation (how it is put
to use) seems to differ greatly from organization to organization. Evidence of this is the
wide array of available supporting tools in conjunction with the fact that many developers
still propose the use of a white board and a bunch of post-it notes. This proved to act as a
bottleneck in the sense that much time was “lost” in discussing and revising how the agile
workflow should be conducted.
(BOTTLENECK III) User stories formulation
To create the initial code frame, user stories would of course be
necessary as there is no data to model without knowing what the
goal of the modeling is. START

However, selecting a subset of modeling technologies/techniques

could indeed have been possible prior to the first formulation of
user stories. For example, in the case of this project, the decision
High-level understanding
was made as to create a ASP.NET MVC4 application with an of CUSTOMER REQ.
Entity Framework Code First database. Even though the team
members were not sure what to actually model prior to the user
stories formulation it would indeed have been possible to engage
in creating a test application as to eliminate potential errors as Identifying an
early as possible. No member of the team had excessive AGILE WORKFLOW

knowledge of this specific subset of technologies prior handed

and consequently it would have been good if some of the culprits
that later were to show up would have been realized. It is the
USER STORIES
authorʼs strong suspicion that these quite likely would have formulation
shown early on if a test application had been created.

(BOTTLENECK IV) Environment setup

Due to ordinary array of computer errors and environmental
ENVIRONMENT
differences a lot of time were spent on configuring the different setup
team members computers. While this wasnʼt done “all at the
same time” this caused a bottleneck in the sense that many
developers were unable to produce code singlehanded before
their environment was actually set up. BACKBONE wireframing
This issue takes software installation, repository access, selection
of tools and techniques into consideration, as well as basic
education and navigation within these tools into account.
FIRST CONCRETE
(BOTTLENECK V) Backbone wireframing TASK IN SPRINT
Since the project members had (a) no experience in coding
together as a team, (b) no rigid technical process to follow, nor (c)
no actual resources or infrastructure at hand (except initial requirements), an initial code
wireframe had to be constructed. Simply put, before you can start to add features, you
must have something to add features to. This caused a smaller group to associate itself
with creating the initial code frame as it proved counter-productive to attempt to build the
initial frame with five developers in front of one screen. Consequently, this played out as a
bottle neck for the remaining developers.
This issue takes both database modeling, as well as application frame flow modeling into
account.
Confirming existence of bottlenecks
The results of the questionnaire concludes that there were indeed some perceptions of
bottlenecks. Two out of three (there was one full non-response) developers felt that both
themselves and someone else was at some point idly waiting for a third person to finish
some kind of task before they themselves could actually carry on with their own. One of

QUESTION YES (TOTAL)

“Were you ever waiting (idle) for SOMEONE (one or many people) to finish some task so 2 (3)
that YOU could perform your own task?”

“Did you ever feel SOMEONE (one or many) were waiting for SOMEONE else (one or 2 (3)
many) to finish a task?”

“Did you ever feel people were waiting for YOU to finish a certain task?” 1 (3)

Did the developers experience “idle time” because of bottlenecks? An extract from
the results of the questionnaire answered by a part of the developers.

these developers also felt others were idly waiting for him or her to complete a certain
task. The questionnaire only concerns the first sprint so consequently this idle time was
experienced during the same time as the bottlenecks were hit.

A database example
As to further discuss an example, letʼs look at the bottleneck of backbone wireframing.
More specifically, a situation occurred during the project, were a smaller number of
developers were more concretely concerned with the creation of the database while the
other developers were occupying themselves with other productive or non-productive
tasks. A bottleneck was hit because too many unexpected errors spawned and created
confusion.
Simply put, since there was no code base at the time, there was, from a developerʼs
perspective, nothing to work upon expect the elimination of the bottleneck - producing a
first version of the database. Hypothetically - if the same errors would have spawned
during the second sprint it is, by the author, assumed that it would not have caused a
bottleneck. Because during the second sprint there actually was an environment already
set up and consequently there was some kind of code that “the other” developers could
concern themselves with.
During a reflective meeting upon the ending of the second sprint the author of this paper
raised this issue and the idea that this was a bottleneck, or “showstopper”, was confirmed
with the other developers.
What now becomes interesting is if we ask the question - so if the developers could not
work with development - what could they work with? If we assume that there were other
bottlenecks that could have been handled, idle developers could have addressed these. If
we assume researching the errors of the current bottleneck would aid in itʼs breaking, that
idle developers could have helped this way. This would however require of developers to
step outside their given role, which by experience, didnʼt seem to happen.

QUESTION YES (TOTAL)

If you at any point lacked a task at hand, did you instead conduct some kind of 1 (3)
research?

What does idle programmers do? An extract from the results of the questionnaire
answered by part of the developers.

When asking if the developers, at these times, indeed did conduct research, unfortunately
only one out of three answered yes. The authorʼs personal suspicion is that the underlying
reason for this is the lack of understanding that research might be part of a developerʼs
role. Also it is believed that since the team members of this particular team all were fairly
novice, a stricter respect was held towards the concept of roles.

Eliminating idle time

Of course, a bottleneck shouldnʼt necessarily have to result in idle programmers. Say for
example the available tasks at hand are A, B and C, and the available workers count to
two. As it is realized that B is dependent upon A, and that the latter yet is not completed,
then if C is “stand-alone” both workers can be kept productive if one works with A and one
with C. Consequently, only handling B when the person working with A is completed with
his or her task. However, what if there is no task C? Consider a scenario where the
number of workers count lower than the number of available tasks.
To illustrate the problem, please consider the formula below:

(IDLE WORKERS) = (AVAILABLE TASKS) - (AVAILABLE WORKERS)

The problem is assumed to be of a logic nature and will consequently not be further
discussed. However, letʼs reformulate the statement as a condition.

ACTIVE WORKFORCE = ( AVAILABLE TASKS >= AVAILABLE WORKERS )

Simply, an active workforce can only be maintained as long as the number of available
tasks equal or exceed the number of available workers.
This suggest that if bottlenecks are handled simultaneously, a workforce can be kept more
active. In the following sections an attempt will be made to group the bottlenecks and
understand dependencies between them as to allow for simultaneous attacking.
This also suggest we can maintain an active workforce simply by increasing the number of
available tasks.
Grouping the bottlenecks
So far, the bottlenecks have only CUSTOMER-RELATED TECHNICAL LOGISTICAL
been discussed in relation to the
order they were carried out as
USER STORIES BACKBONE Identifying an
tasks within the project. formulation wireframing AGILE WORKFLOW

However, to proceed in the

discussion, letʼs attempt to
distribute these tasks into three High-level
ENVIRONMENT
understanding of
groups. The groups are (1) setup
CUSTOMER REQ.

customer-related tasks, (2)

technical tasks, and (3) logistical
tasks. Firstly, anything directly concerning communication with the customer falls under the
first group. Secondly, anything that can be described as a technical problem with a
technical solution falls under the second category. Lastly, anything that can be seen as an
internal issue falls into the third category.
The reason these bottlenecks are here grouped into different categories is to underline
the, potentially obvious, fact that role division might help in understanding which team
member(s) should address which issue.

Bottleneck dependencies
The following diagram illustrate the dependencies between the different bottlenecks as
perceived by the author. To
understand the diagram, use
to following general FIRST CONCRETE
TASK IN SPRINT
description: If task A has an
arrow pointing towards task
B, then task B cannot be
carried out before task A has
been completed. Simply, the
BACKBONE
wireframing 2
DEPENDENCIES
arrows are pointing from the
simpler task to the more
complex task.
Observing this diagram it
ENVIRONMENT
setup
USER STORIES
formulation 1
becomes evident that DEPENDENCIES

different internal teams

actually could address some
of these bottleneck issues at
the same time. As an
Identifying an
AGILE WORKFLOW
High-level
understanding of
CUSTOMER REQ.
0
DEPENDENCIES
example: assuming that the
dependencies are only the
ones depicted in the diagram above (which of course is not the real world case) then the
task depicted as “Identifying an agile workflow” could be conducted at the same time as
conducting any of the other tasks. As long as it is finished before the attempted initiation of
the first concrete task of the sprint, it matters not where it ends up in the sequence of
tasks.
In summary, the point is that if the dependencies between bottlenecks are understood than
teams should be able to effectively work with eliminating them several at a time, rather
than blindly one by one.

The problem of the bottlenecks

In essence, the initial (first sprint) bottlenecks of the project were neither (1) discovered in
time, nor (2) successfully averted when discovered even though they were thoroughly and
publicly discussed. At the same time, the project suffered from idle programmers during
the first sprint. Labor which actually could have been used to crush bottlenecks.
It is assumed that if the level of experience of team members were higher the situation
would have played out differently.

Results of case study & survey

The main results of the case study are outlined below.

(C1) Agility in itself does not ward off initial bottlenecks

Even though the team attempted to adopt the principles of agile development, or more
specifically SCRUM, it seems that this in itself was not enough as to eliminate the
existence of initial startup bottlenecks. While the existence of these bottlenecks should not
be considered any kind of “discovery”, as they should be fairly obvious to any seasoned
developer, the author consider it a relevant understanding that the application of agility in
itself simply does not eliminate the need to address or avoid the potential idleness caused
by these initial bottlenecks.

(C2) Strict role division cause idle programmers at times of

bottlenecks
When bottlenecks are hit it seems a strictly followed role division may prove to actually put
programmers that are not directly role-related to the issue into an idle state awaiting the
return of normal workflow.

(C3) Not all developers research solutions to others problems

when faced with idle time
While it might be considered fairly obvious it has now been (1) concretely experienced,
and (2) proved through direct questions in a questionnaire, that all developers do not
necessarily attempt to research solutions to other developers, or general, problems when
faced with idle time. This even though this idle time might be caused by some bottleneck
that another individual or group of individuals is working to crack.

(C4) Multiple bottlenecks can be addressed simultaneously

Bottlenecks can be addressed simultaneously, given that there are no direct dependencies
between them.
Literature review
The following chapters outlines what has been identified through literature reviews.

Having two roles improve both collaboration and result

Dubinsky & Hazzan (2004) has conducted ongoing research with students working with
eXtreme Programming (XP) within the academic context and drawn interesting
conclusions on the optimal groupings of students. Dubinsky & Hazzan (2004) suggest a
scenario where each student holds two roles, one as a concretely code producing
developer, and one with a more personal task such as being a coach or being responsible
for user interface design, customer contact, presentations
or so forth. Dubinksy & Hazzman (2004) claim this has
proven to have a mutual positive influence, and provide the
following example: Imagine a scenario where a student is a
developer, but also holds the personal role of writing unit
tests. In this case the student is likely to not only engage in
team education of about test-driven (e.g.) development, but
also to spend more effort in writing tests for the code he or
she is self producing. Consequently the latter means the
results of the studentʼs work will serve as a positive
example on how to write test cases. Dubinsky & Hazzman
(2004) mean that providing students with these two
The two roles of a single
simultaneous roles results in that “collaboration between team member.
team members is enhanced”.

SCRUM will make team members more helpful

In a paper by Rising & Janoff (2000) the authors review a case where Scrum was
attempted as a methodology in three smaller teams in an interconnected project. While the
paper of course hold several conclusions, one interesting comment is one from the leader
of one of the three teams. Quote as follows:

“Iʼve noticed an increase in volunteerism within the team.

Theyʼre taking an interest in each otherʼs tasks and are more
ready to help each other out.” (Rising & Janoff, 2000)

If the above quote is true then it seems SCRUM team members, in relation members of
teams practicing classical software development methodologies, are more willing to step
outside their own given tasks to help a colleague.
Another statement strengthening the one above, is the SCRUM principle suggesting the
hosting of an “energized working environment” where developers in the best-case-
scenario hold a “can do” attitude (Fruhling & Tarrell, 2008).
Tasks must be assigned to individuals
One finding of the article discussing an attempt to involve SCRUM into smaller teams in an
already existing organization (Rising & Janoff, 2000) was that tasks indeed had to be
assigned to one single individual. That even if the workload of a task would have to be
distributed or shared the task must still hold one primary responsible person (Rising &
Janoff, 2000).

Change response is better than planning

The highly praised Agile Manifesto (Fowler & Highsmith, 2001) state that an idea behind
the concept of agility is to allow oneself to respond to change rather than to follow an
original plan. That no matter how great the plan might be, and no matter how many risks it
has taken into account, the nature of reality is that change will have to occur in either case.
In essence, Fowler & Highsmith (2001) state that “scrupulously following a plan can have
dire consequences”.
While this concept has become fairly obvious in the discussion of agility, the concept is
here restated as to underline itʼs importance to the very foundation of the concept of agility.

Results of literature review

The results of the literature review are the following corner stones that will be used to
support the discussion and corresponding suggestions of this article.

(L1) Willingness to help comes only with experience

Dubinsky & Hazzan (2004) seem to attempt to formalize the form of natural helpfullness
that Rising & Janoff (2000) states will come naturally through the incorporation of SCRUM.
It would be possible that this form of formalization that Dubinsky & Hazzan (2004) has
conducted might have been necessary because of the one major differing factor between
the two projects in question. The first is a student project within the context of academia,
wheras the latter is a project where already highly experienced individuals simply are
attempting to adapt a new methodology. The major difference is consequently the level of
experience of the individuals.
The author of this paper suggest that that this form of “willingness to help” will not occur (to
the same extent, or with the same success) if the team members are less experienced.
Supported by the fact that this “mutual positive influence”, observed by Dubinsky &
Hazzan, only first occurred when a formalization of roles were introduced, while the helpful
attitude was experienced by merely applying agility in the project observed by Rising &
Janhoff (2004).
(L2) Every decision does not have to concern everyone
Rising & Janoff (2000) proved that SCRUM can be carried out successfully even though
every member doesnʼt attend every SCRUM meeting. Further, even though the SCRUM
meetings isnʼt even held daily (Rising & Janhoff, 2000). While this is interesting because it
is a “personalized” version of SCRUM, it is also interesting because the author suspects
democracy was maintained even though these two factors.
There are two points to support this idea. Firstly, the agile manifesto do after all suggest
that developers should “respond to change” (Fruhling & Tarrell, 2008) and that it is better
to make short-term plans and expect them to change rather than attempting to make more
“general” long-term plans. Secondly, Turk & Rumpe (2005) state that agile methodologies
actually challenge the conventional believe that the latter a change is made, the more
costly it will be. So case argued with point one and two is thus that it would be a feasible
suggestion to only allow a smaller number of team members participate, and allow “the
others” to give opinions later on.
The author of this paper does not in any way endorse an anti-democratization of the agile
team. However, since change is not costly, anti-democratic decisions should not be feared,
as long as they are (1) always subject to change and (2) open for discussion at any time.
As earlier discussed, the agile concept of change response (i.e: Fowler & Highsmith, 2001)
in conjunction with the idea that a latter change is not necessarily a more costly change
(Fruhling & Tarrell, 2008) could be interpreted as that - it would be equally efficient to allow
smaller groups within the group to make quick decisions, and then allow changes to occur
if the other members wish at any later time. Rather than involving everyone in every
decision.
In the context of bottlenecks this means that multiple bottlenecks could theoretically be
addressed by different subgroups of the team simultaneously as to restore regular process
flow as early as possible.
Conclusion
So, what to do with these pieces of somewhat detached information? Returning to the first
research question (RQ1) the answer is, in accordance with the first finding of the case
study (L1) that agility in itself indeed is not a sufficient solution for a group of students to
avert initial startup bottlenecks.

(FIN1) Agile methodologies is in itself not a sufficient mean

for students to avert initial bottlenecks of a project.

Consequently this means the second research question (RQ2) becomes relevant - can we
introduce techniques or practices that help students avoid these issues? To be able to
suggest new principles, letʼs first look at the areas identified as problematic.
The case study (C2) prove that having single-role individuals does not avert the existence
of bottlenecks. However, in problematic contrast, both the literature (L1) and case study
(C3) suggest that not all team members will take the initiative to aid other members when
faced with idle time. Potentially this could be a product of lacking experience (which is an
idea supported by the case study). However these two pieces of information support the
paradoxical statement that: inexperienced team members need guidance as to take
initiative upon bottlenecks outside their role, but on the other hand - giving roles cause
bottlenecks to stagnate.
Confusing? Well, there is of course one fundamental miss weʼre making - the idea that
roles wonʼt avert bottlenecks actually only applies to the specific set where members have
one single role (developer) in contrast to two roles. Consequently nothing is yet known
about multiple roles.

(FIN2) Inexperienced team members need guidance as to take

initiative upon bottlenecks outside their role

(FIN3) Single role individuals does not aid in averting

bottlenecks

The last conclusion to draw is that even though agile development methodologies seems
to create teams with flat hierarchy it doesnʼt seem that all issues must at all times concern
everyone. Firstly, it seems useful to address bottlenecks, simultaneously by separate
groups (according to the case study, C4), and supported by literature (L3) it seems
sensible from an agile perspective that not every decision or action must concern
everyone.

(FIN4) Every decision does not have to concern everyone

So to conclude the answer to the second research question weʼve identified three pieces
of information that will lead us closer to eliminating the initial bottlenecks faced by students
in agile startup projects: (1) Roles are needed, (2) roles cannot be single-roles, and (3)
bottlenecks can be addressed simultaneously.
Suggestions
While the conclusion summarize evidence drawn from logical conclusions, the following
section gives a number of suggestions based on these conclusions. Consequently the
author consider the following points to indeed have logical support, but however to be
more of the subjectively speculative nature.

(SG1) Shoot first, ask questions later (suggesting a principle)

Students working with agile must understand that it is may be equally or more beneficial to
act upon a problem when it is identified as opposed to raising it for discussion. When
discussing bottlenecks this mindset becomes utterly more important.

(SG2) Let somebody else do the job (suggesting a principle)

As to avoid the stagnation of work, and situations of idle developers awaiting normal
process flow because a number of developers are stuck in a bottleneck, it is suggested
that it must be communicated to students that if one is working on an important task (letʼs
call this A) and another important task is discovered (letʼs call this B). Then it is utterly
inefficient to “stack” these tasks and assign them to oneself. If these tasks are both
causing bottlenecks, then one of them should be distributed to an available team member.
Simply, assign as many people to a bottleneck as possible, and the rest to another
bottleneck.

(SG3) The Renaissance Researcher (suggesting a role)

As to strengthen the second suggestion, the author would
also like to suggest, first the adopting of the concept of
giving each student two roles, but also to escalate this into
a set of three roles per student. While this might seem
exaggerated it is merely a formalization of a task that
should come natural to students but might not because of
lack in industry experience. This ties back to the discussion
about how the mindset of discovering others problems and
helping them, only shows when team members are
experienced. Consequently the suggestion is to make it
explicit that all student have three hats. Making them a (1)
developer, a (2) researcher (or: problem-solver), and (3)
something unique defined in the specific project.
The author has chose to call this role the Renaissance
Researcher as to imply that it is important that every
member of the project understands that it is their
Introducing a new “hat” to the
responsibility to aid in finding solutions to every problem set of roles that each team
that any other member might be facing regardless of the member should hold.
subject area.
Discussion
The issues discussed in this paper can definitely be considered “people-issues” and
consequently there might be as many variations of this scenario as people on the planet.
However, the author still believe the suggestions of this article are solid since there is
nothing oddly bold about suggesting that guidance will help the novice.
While the identified (or rather: highlighted) bottlenecks were of course not necessarily all of
the bottlenecks that were hit during the first sprint, the author has chosen to highlight these
as to prove the case in point and doesnʼt necessarily believe that choosing a different set
of bottlenecks would change the argued point in question.
While there is no evidence to suggest that the bottlenecks highlighted within this paper is
likely to be hit within any project, the author would still be so bold as to suggest that these
grouping of activities are so general that they in fact can be considered (almost) inevitable
for all student startup projects.
The above are however all merely opinions.

Further research
Further research would be beneficial as to evaluate the actual effects of implementing the
suggested techniques in student projects.
References
Fruhling, A L & Tarrell, A E (2008). Best Practices for Implementing Agile Methods: A Guide
for Department of Defense Software Developers. IBM Center for The Business of
Government.
Turk, D, Frande R & Rumpe, B (2005). Assumptions Underlying Agile Software
Development Processes. Journal of Database Management, 16(4), pp. 62-87.
Dubinsky, Yael & Hazzan, Orit (2004). Roles in Agile Software Development Teams.
Springer Berlin / Heidelberg.
Rising, L & Janoff, N. S. (2000) The Scrum software development process for small teams.
Software IEEE, vol.17, no.4, pp.26-32, Jul/Aug 2000.
Fowler, M. & Highsmith, J. (2001). The agile manifesto. Software Development, 9 (8),
28-35.