study of application of scrum methodology in a business incubator incubio
TRANSCRIPT
RESEARCH PAPER TITLE: STUDY OF APPLICATION OF SCRUM
METHODOLOGY IN A BUSINESS INCUBATOR INCUBIO
AUTHOR OF THE PAPER: ALINA TSIKHANAVA
DEGREE: BUSINESS ADMINISTRATION AND IT
RESEARCH SUPERVISOR: GABRIEL MESQUIDA MASANA
02 JULY 2014
ABSTRACT
Agile and Waterfall are the two leading approaches for software development. Agile
methodologies are relatively new compared to the Waterfall. First of all, this study
explains the reasons for Agile emergence and the new values and principles it brought
into software development.
Scrum is an Agile framework for complex software development projects. It supports
all the Agile principles and values and extends them with its own rules and practices. It
is a lightweight methodology, easy to understand on an intellectual level but difficult to
apply successfully in practice.
The paper presents Scrum theory and lists some of the common problems companies
come across on their way to success. Scrum often gets too much modified because of
misunderstandings of its principles or because of a deeply embedded Waterfall mindset.
During this study the business incubator Incubio was examined for those problems.
Interviews and observations were used to collect data in order to evaluate the
methodology Incubio is using. The eventual goal was to find out whether they actually
use Scum or not.
The result of the study showed that the Incubio’s projects follow Scrum prescriptions,
however not all the projects are equally successful. The conclusion can be drawn that
even though the adherence to the Scrum practices and rules is ensured on the general
level, the positive outcome and team satisfaction depend to a great extent on the attitude
of each particular team member.
CONTENTS 1. PROJECT GOAL .................................................................................................................. 1
2. METHOD .............................................................................................................................. 2
3. BACKGROUND ................................................................................................................... 3
3.1. Agile Emergence ........................................................................................................... 3
3.2. Scrum ............................................................................................................................ 5
4. SCRUM THEORY ................................................................................................................ 6
4.1. Iterative and Incremental Delivery ................................................................................ 6
4.2. Bottom-up Thinking ...................................................................................................... 6
4.2.1. Product Owner........................................................................................................... 7
4.2.2. Development Team ................................................................................................... 7
4.2.3. Scrum Master ............................................................................................................ 8
4.3. Empiricism .................................................................................................................... 9
4.3.1. Transparency ............................................................................................................. 9
4.3.2. Inspection and Adaptation ....................................................................................... 11
5. SCRUMBUTS ..................................................................................................................... 15
5.1. Good and bad Scrumbuts ............................................................................................ 17
6. INCUBIO ............................................................................................................................ 20
6.1. First interview. Acquaintance with Incubio ................................................................ 20
6.1.1. Scrum Team ............................................................................................................ 21
6.1.2. Scrum Master Performance ..................................................................................... 22
6.1.3. Visibility of the process ........................................................................................... 23
6.1.4. Workflow ................................................................................................................ 23
6.1.5. Product Backlog ...................................................................................................... 24
6.1.6. Human resources activities ...................................................................................... 24
6.2. Second interview. Quizlyse ......................................................................................... 25
6.3. Third interview. Groupiest .......................................................................................... 26
7. CONCLUSIONS ................................................................................................................. 28
8. BIBLIOGRAPHY ............................................................................................................... 30
ANNEX 1 .................................................................................................................................... 31
Manifesto for Agile Software Development ........................................................................... 31
Principles behind the Agile Manifesto .................................................................................... 32
1
1. PROJECT GOAL
The goal of this paper is to find out whether a specific company claiming to use Scrum
is actually using it or not.
The company chosen for the research is a business incubator Incubio whose
specialization is technological projects related to the Big Data. I knew the company was
using Scrum to manage their projects and was using it successfully. So my intention
was to learn how they were applying Scrum; to check if they adhered to the Scrum
theory and the philosophy behind it; what Scrum adaptations if any they had to make in
order to achieve good results; and in case there were deviations, whether it was still
Scrum they were doing or not.
2
2. METHOD
Scrum Guide was used as a theory basis. It is the official rulebook developed and
sustained by Jeff Sutherland and Ken Schwaber - the inventors of Scrum.
Ken Schwaber admits1 that Scrum has “black holes” which he fills by the tips in his
blog entries, videos, talks, etc. There is no complete published Scrum theory, because
otherwise it would be a methodology and Scrum was meant to be a framework.
Having taken this into consideration, the sources of information I have used for my
work were materials from Scrum.org, ScrumAlliance.org, Schwaber’s blog and his
book “Agile Project Management with Scrum” and blog posts by other certified Scrum
Coaches.
Scrum.org and ScrumAlliance.org are the two organizations that provide Scrum training
and certifications. They both involve individuals who participated in Scrum
development and promotion since its inceptions, therefore have the most experience and
expertise.
I used those resources to learn about the Scrum adoption in companies, to learn which
Scrum rules are commonly misunderstood, what Scrum elements get modified, how
much of Scrum is left after those modifications and what modifications still allow
Scrum to be efficient. All those problems are listed in the Scrumbuts chapter.
Relying on that knowledge I interviewed Incubio’s VP Engineering, a CTO of one of
the incubated start-ups, attended a Daily Scrum of another start-up and interviewed its
Scrum Master and its Product Owner. The eventual goal was to check whether Incubio
had run into similar difficulties, how they deal with them if they have and how they
avoided them if they haven’t. With the information obtained inside the company I
analyzed to what extent they deviate from Scrum. As a conclusion I suggest my
assessment of whether it is actually Scrum what Incubio is using or not.
1 Mezick, D. (2010). Interview with Ken Schwaber, Part 1. InfoQ.
3
3. BACKGROUND
3.1. Agile Emergence
There are several methodologies used in software development. The most prominent of
them are Agile and Waterfall. These models enjoy a lot of discussions and even heated
debates recently.
Waterfall methodology appeared first, that is why it is also called traditional or
classical. It was designed for physical environments such as manufacturing and
construction industries and later adapted and applied to software development since no
formal software development methodology existed2. It is a linear model in which each
following stage can’t begin until the previous one is finished. The stages include (may
slightly vary): Analysis, Design, Implementation, Testing, Evaluation and Maintenance.
Once a stage has been completed, developers can’t go back to make changes. Therefore
everything must be carefully planned from the start, due to which Waterfall is called
predictive approach. No changes or errors are admitted in Waterfall, the thoroughly
elaborated extensive initial plan must be carefully followed. Otherwise all the previous
work will have to be re-done from the beginning which involves time and budget creep.
There are both advantages and disadvantages of a traditional approach as in any
methodology. However, intolerance to changes in a rapidly changing world and
growing complexity became unacceptable. Furthermore, heavy regulation and abundant
documentation was often a time-wasting obstacle for trying to deliver value, to be
competitive and flexible responding to the market needs.
As a response to those disadvantages Agile methodologies appeared in attempt to solve
Waterfall’s shortcomings.
Agile is based on several new ideas: iterative development, incremental delivery, cross-
functional teams, time-boxed approach, requirements changes acceptance. Instead of
desperately making understand a client that changes are impossible Agile recognizes
that the customers can change their minds about their needs and wants. Besides the
changes coming from the customers there are changes coming from a better
understanding of a problem: as the work proceeds more is being learned about the
product, market, technology, requirements and time needed to implement those
requirements. Moreover, new markets, new technologies may come into sight while the
2 Benington, Herbert D. (1 October 1983). "Production of Large Computer Programs". IEEE Annals of
the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361.
4
project is in progress. If those facts are ignored the product delivered in the end may
already be delivered obsolete and useless. In order to deliver value one should monitor
the world and be ready for the changes. For that Agile introduced testing and launchable
product delivery on every stage so that developers can get feedback as soon as possible,
have the feeling of accomplishment and stay motivated, a client can assess if his
requirements have been understood and they have spoken the same language with the
team until it’s too late and expensive to clarify. Whereas Waterfall fully relied on
initially agreed requirements, delivered seldom therefore never got feedback, at the end
of the project a client might have got something he didn’t want. So at some point
Waterfall was already incapable of responding to the needs of a changing world and
Agile emerged to overcome those limitations. Agile is a completely new approach, it
expects changes rather than fears them.
Not only was “the changing world” out of a reach of the Waterfall. It simply didn’t take
into account the human factor: sometimes a client might not even know what he wants.
As the developers give him examples his opinion starts to form, he learns what he wants
and what he doesn’t. This can’t be overlooked, ignored or blamed.
There are still projects where Waterfall would be more suitable than Agile. If the whole
scope is clearly known, if there is a clear picture of what an end product must look like,
if the industry the product intended for is mature and doesn’t change, in case of high
employee turnover Waterfall should be used. Otherwise Agile should be considered.
Agile practices can be traced back to 1957 but only in 1990’s Agile started to evolve as
a methodology. In 2001 seventeen software developers met to discuss lightweight
software development methods. As a result of that meeting the Agile approach was
defined and Agile Manifesto was published3.
The Manifesto (Annex 1) includes 4 new values which contrast to the Waterfall values.
The Agile Manifesto authors captured the shift of view in those 4 sentences; here are the
new values.
3 Beck, Kent; et al. (2001). "Manifesto for Agile Software Development". Agile Alliance.
5
Individuals and interactions - Agile supports the idea of that the problems come from
the lack of communication. That’s why the work is done in closely collaborating teams
and even pairs. Teams are self-organizing, no management is imposed over them, as the
team knows better how to make itself comfortable to maximize productivity.
Working software - working software is much more visual than just documentation. It’s
more useful when presenting to a client.
Customer collaboration - in the beginning no customer or stakeholder knows what he
wants. Therefore there’s never a full list of requirements in the beginning of the project.
So collaboration is important to continually make sure that the Development Team is
implementing what the customer expects. If it doesn’t then inspection and adaptation
will fix the process before it is too late.
Responding to change - since Agile is thought for complexity it accepts changes on any
stage of a project. As the team proceeds it learns about the problem they are to solve, so
it’s natural to bring into some changes to adjust the initial planning.
3.2. Scrum
Scrum was developed by Ken Schwaber and Jeff Sutherland in early 1990’s.
It is an agile framework for complex software development projects. It is based on
Agile principles and share all its values, also extends them with its own rules,
philosophy, processes and practices.
Scrum is not prescriptive, it doesn’t specify what to do in every situation, neither does it
establish the sequence of actions. Instead of prescriptions it offers a skeleton made of
values and principles over which various methods and methodologies can be applied.
Scrum is simply a framework. It teaches how to treat emerging challenges in a changing
and uncertain environment, requires to keep everything visible and react on an empirical
basis.
6
4. SCRUM THEORY
Scrum is based on 3 concepts:
Iterative and incremental delivery
Bottom-up thinking
Empiricism
4.1. Iterative and Incremental Delivery
Scrum consists of short iterations of one to four weeks. At the end of each iteration
Scrum prescribes the delivery of the done functionality. Incremental delivery in
iterations maximize opportunities for feedback which means that any unwanted
deviations can be detected in time or with an iteration-time delay at worst. By these
means Scrum
reduces risk of cost to the duration of one iteration;
addresses complexity: only a small well understood part of requirements is
worked on during the iteration;
ensures availability of a working product version which is of a significant
interest to the stakeholder;
keeps the stakeholders believing that the Team is developing something
meaningful for them;
keeps the Team motivated by having the feeling of accomplishment without
waiting till the end of a project.
Iterations are called Sprints in Scrum. Sprint is a basic unit of a Scrum process. All
work is done in Sprints. Sprint is sometimes considered as an event, although being the
main unit of Scrum might be understood as a container for all other events. It contains
Sprint Planning, Daily Scrums, Sprint Review and Sprint Retrospective with the
development work in the middle.
The duration of a Sprint and the workload are fixed in advance and cannot be changed
during the Sprint.
4.2. Bottom-up Thinking
One of the central tenets of Scrum is that teams are self-managed. Team manager does
not exist. For every iteration the development team has a goal and it figures out itself
7
how it will build the functionality. This fosters creativity that cannot be planned
centrally but is essential for high productivity. The idea of empowering the team - the
people who actually do the work - is called bottom-up thinking. As opposed to
Waterfall, the decision making in Scrum is shifted from the central planning body to the
people close to the work.
This is an absolutely new approach to management that seems counterintuitive.
Nonetheless, it works provided it is implemented as Scrum prescribes.
Scrum Team consists of Product Owner, Development Team and Scrum Master.
Therefore there are 3 roles defined in Scrum: Product Owner, Developer and Scrum
Master.
4.2.1. Product Owner
Product Owner (PO) represents a customer. He is a person who has the whole vision of
a product and clearly understands the value it must deliver. PO defines the product
requirements which make up a list called the Product Backlog. Implementation of all
the requirements is supposed to deliver a vision of a project. PO is responsible for
managing the Product Backlog: clearly express the requirements, clarify them when
more is learnt, make sure the Development Team understands them, keep the Product
Backlog visible and ordered so that the team knows what to do next and in such an
order that maximum value is delivered. An ordered Product Backlog is a starting point
for any project.
Excellent communication skills are important for PO. He is a bridge between
stakeholders and the Development Team, so he should be able of speaking both
languages: the business language of stakeholders and the technical language of the
team.
PO’s role is never combined with that of a Scrum Master, and it’s always a
responsibility of only one person not a committee.
4.2.2. Development Team
Development Team is accountable for delivering potentially shippable increment at the
end of each Sprint. The teams are not normally very large (maximum of 9 persons).
They are cross-functional, meaning that any team member should be able to fulfill
several kinds of work (design, analysis, development, testing, documentation) that are
8
necessary to create a product increment. Although there might be titles and tags like
programmer, analyst, designer, tester, Scrum only recognizes a Developer role. Some
team members may have greater skills than others, but in any case accountability
belongs to the whole Team.
The Development Teams in Scrum are self-managing. They manage their own work.
They are also self-organizing. They figure out themselves how to turn the selected
requirements into potentially shippable increment.
4.2.3. Scrum Master
Scrum Master (SM) is accountable for teaching Scrum, making sure all the Scrum rules,
theory and practices are adhered to. He also protects the Team from external
impediments that prevent it from reaching its goals. It’s an important point that a
Scrum master is not an equivalent of a project manager. He only acts as a buffer
between the team and the external world, facilitates the process and with his vision and
knowledge of a framework helps to solve issues.
Scrum Master is so called “servant-leader”. As opposed to a traditional leader, servant-
leader does not exercise the full power, rather his power is shared among all the Scrum
Team members and he only helps (i.e. serves) others to develop and perform in the most
productive way. So, regarding Product Owner, Scrum Master helps him to find effective
techniques for Product Backlog Management, understand Product Planning in an
empirical environment, understand agility in general, and facilitate Scrum events. As far
as Development Team is concerned, Scrum Master performs as a coach for the Team
helping practicing self-management, self-organization, cross-functionality; removes all
the impediments the team comes across on its way to the progress; facilitates Scrum
events; helps to understand Scrum in those environments where Scrum is new, not fully
adopted or understood. As far as organization is concerned, Scrum Master serves it as a
leader in Scrum adoption, plans Scrum implementation, delivers the initial training for
the employees and stakeholders, works with other Scrum Masters inside the
organization.
Sometimes companies keep a role of a project management or keep responsibilities of a
project manager assigned to a SM. This means fundamental misunderstanding of Scrum
principles.
9
4.3. Empiricism
Scrum was designed for the high complexity projects. That means that in the beginning
very little is known about the project and even what is known can prove wrong later on
in process. Scrum addresses this challenge by applying empirical process control theory.
It is built on 3 basic ideas: transparency, inspection, adaptation. In a complex project
everything should be kept visible in order to be able to inspect the progress. If during
inspections problems are found, they must be solved and the process adjusted which
composes the adaptation stage. In this way Scrum helps to develop capacity for a fast
response to changes instead of trying to predict the future and build a plan on this guess
as happens in Waterfall.
4.3.1. Transparency
Scrum’s Artifacts are specifically designed to make the key information about the
project transparent. They provide information on the project’s state - how much has
been done, what is being done and how much of the known work is left. This gives an
opportunity of inspection and adaptation.
Besides having transparent all significant aspects of the process it’s important to have a
common understanding of what is being observed. The Definition of Done, for example,
ensures the common understanding of the Increment delivered at the end of each
iteration.
The Scrum Artifacts include Product Backlog, Sprint Backlog and Increment.
Product Backlog
The Product backlog is an ordered list of product requirements. It contains everything
that must be done to deliver value: features, functions, modifications, fixes, etc.
The requirements are usually formulated in user stories, but that is not the only
technique for requirements documentation. User stories describe the functions the
Product must provide. Those are several sentences in business language describing what
a user needs to do as part of his job. They should be concise and clear to everyone.
Mike Cohn, a well known author on user stories suggests the following format:
As a <role>, I want <desire/need>4.
4 Cohn, M. (2008). Advantages of the “As a user, I want” user story template. Mountain Goat Software.
10
Chris Matts emphasizes the importance of the value pursuit.
In order to <receive benefit> as a <role>, I want <desire/need>5.
Product backlog is an ordered list. All the requirements are prioritized by the Product
Owner so that the Team implements the functionality that maximizes the client’s
benefit. It’s a public list open to everyone, anyone can view it, but the Product Owner is
the person responsible for managing it.
The Product Backlog is never complete. The first requirements on the list are those best
known and understood. Then it is always evolving as more information about the
product is learned and as more feedback is received.
Similarly, Product Backlog refinement never ends. New details are constantly added,
estimates are adjusted and ordering is modified. This is a continuous process in which
Product Owner and Development Team collaborate. Higher ordered Product Backlog
items are normally better prepared to be picked for implementation. They are described
with a higher level of detail and refined so that any of them can reasonably be “Done”
within one Sprint.
The first block of requirements becomes tasks to implement in the first Sprint. It’s the
first tranche of information about the product that is sufficient to let the work start.
However, it’s advisable to elaborate it as complete as possible, as it gives the vision and
provides the base to assess the progress of the project.
Every record in a Product Backlog has 4 attributes: description, order, estimate and
value. PO is responsible for description and details and the Development Team is
responsible for estimates. The more details the easier it is to make estimates. PO may
influence the Development Team but the final estimates are made independently by the
Team only, because they are the people who will actually perform the work.
Sprint backlog
Sprint Backlog is a set of Product Backlog items selected to be implemented in the next
Sprint together with a plan for their implementation. The items for the Sprint are
selected from the top of the Product Backlog until the Development Team feels it has
reached the limit of its capacity relying on its past performance. Then the Development
5 Marcano, A. (2011). Old Favourite: Feature Injection User Stories on a Business Value Theme.
Antonimarcano.com.
11
Team breaks down every selected item into tasks. Tasks are never assigned, they are
always signed up for by the Team members according to skills, priority and workload of
each one. This is where self-organization lies.
During the Sprint the Development Team learns more about the task to complete, so it
constantly modifies the Sprint Backlog with new details on how the work should be
done, or a new work can be added if it appears to be necessary, similarly, work can be
removed if it is deemed unnecessary. All those adjustments are easy to make thanks to
Daily Scrums that help to synchronize all the Team Members and learn where they are
and where they are not.
Sprint Backlog must be kept up-to-date throughout the Sprint as it is a real-time picture
of the work to be done in the Sprint. This is the responsibility of the Development Team
and Sprint Backlog belongs only to it.
The Scrum Board or a Task Board is often used to visually represent the progress. It’s a
board with 3 sections: “To Do”, “In Progress” and “Done”. In each section stickers with
tasks are placed so you can tell easily by the stickers distribution which state the Sprint
is in.
Sprint Backlog can’t be extended with new functionality once it has been committed
except by the Team. After each Sprint the Product Backlog is analyzed and reprioritized
if necessary and another set of requirements is selected for the following Sprint.
Increment
The Increment, also called potentially shippable increment (PSI), is all functionality
implemented in the last Sprint and the previous Sprints. It is “potentially shippable”
because Scrum requires it to be in working conditions, i.e. must be done according to
the Definition of Done initially defined by the Team. The Product Owner may decide to
release it, so the increment must be ready for that at the end of the Sprint.
4.3.2. Inspection and Adaptation
Because of uncertainty and complexity there is no the defined “desired” as in Waterfall.
Instead, Scrum ensures avoiding the “undesired” by frequently inspecting Scrum
Artifacts and progress towards the Sprint goal.
In case any undesired deviation has been detected the process must be adjusted as soon
as possible.
12
There are four Scrum Events that serve the purpose of inspection and adaptation. All of
them are time-boxed, which means that their duration is limited.
Sprint Planning Meeting
It is an 8-hour meeting. First 4 hours Product Owner presents the top priority
requirements. Those requirements and priorities are discussed, the Development Team
tells how much it can do and selects the requirements it commits to accomplish. When
selecting the requirements for the Sprint the Team considers team’s capacity and past
performance. In this first part the Sprint goal must be set.
The second phase of planning lasts 4 hours during which the Development Team plans
out the Sprint. The planning includes designing and assigning tasks and time estimates.
As a result a Sprint backlog is obtained. Sprint Backlog is a real time picture of what the
Team is planning to do and it should stay visible to everyone at all times. All the tasks
in the Sprint Backlog are 4 to16 hours. If they take longer it means they are not properly
defined. The Development Team self-organizes both for Sprint Planning and for actual
performance throughout the Sprint. If some specific skills, experience or knowledge
needed the Development Team may invite specialists of specific domains in order to
provide advice.
By the end of this event the Development Team should be able to explain how it is
going to create an expected increment.
Daily Scrum Meeting
It is a 15-minute time-boxed meeting held in the same place and at the same time every
day, normally first thing in the morning. Each member of the Development Team
answers 3 questions:
1. What have you done since last Daily Scrum?
2. What are you going to do today?
3. What obstacles do you have on your way?
It is a useful event for self-organizing teams to catch up on the progress and inspect how
they are moving towards the Sprint goal, whether it is going to be achieved or not and
adapt or re-plan when necessary.
And important: it’s not a reporting to the Scrum Master. The Daily Scrum is for the
Team, Scrum Master might not even be present there, he just teaches the Development
13
Team to keep it time-boxed, watches it to be held every day, enforces the rule that Daily
Scrum is only for the Development Team members.
The purpose of holding Daily Scrums daily is to improve communication, promote
quick decision-making, ensure transparency, inspection and adaptation.
Sprint Review Meeting
This meeting is time-boxed to 4 hours, during which the Development Team presents to
the PO and in some cases to the stakeholders what has been achieved during the Sprint,
answers the questions, and explains what problems it encountered during the Sprint.
Only the “done” functionality is presented. This is both a Scrum and an Agile rule. In
the Agile Manifesto the seventh of the twelve principles says: “Working software is the
primary measure of progress.”6 Scrum also emphasizes deliverable increment on every
iteration therefore it’s important that the presented product be really “done”, i.e. it
should be a working product.
During this meeting the increment is inspected and adaptations of the Product Backlog
are discussed. This is the time when budget, scope, timeline, marketplace, new
opportunities are reviewed. Any significant changes must be taken into consideration
for adding new requirements or changing the way the Product Backlog is ordered.
Sprint Retrospective
This meeting is time-boxed to 3 hours. It’s an opportunity for the Team to inspect itself.
The purpose of the meeting is to inspect people, relationships, process, tools used. It is a
revision during which the Team discusses what went wrong, how the development
process can be improved or certain problems can be solved to make it better in the next
sprint.
At the end of the meeting the team comes up with the improvements it will implement
in the next Sprint to make its work more effective. This demonstrates the logical end of
the learning cycle (iteration) in Scrum. Although adaptations may be brought in at any
time, Sprint Retrospective is a formal event that fosters analytical activity aimed at
detecting opportunities for improvement.
6 Beck, Kent; et al. (2001). "Manifesto for Agile Software Development". Agile Alliance.
14
Figure 1. Scrum Process.
Source: Jansma, N., Mulder, T., Nikhogosyan, M. (2011). Scrum Beyond Software. How Dialogues Incubator
Goes Agile.
15
5. SCRUMBUTS
The Scrum Guide explicitly warns practitioners against modifying Scrum: “Each
component within the framework serves a specific purpose and is essential to Scrum’s
success and usage.”7 However, Scrum is disruptive for many organizations. When it
involves too much change sometimes companies choose to change Scrum instead of
changing themselves. In some cases Scrum elements seem useless or too much
overhead for the practitioners, so they just decide to omit them which often results in a
Scrum failure.
An adaptation or modification of Scrum is called a Scrumbut, because it sounds as “We
use Scrum, BUT (excuse) (workaround)”. For example: “We use Scrum, but (our team
is dispersed over various time zones), (so we have Daily Scrums whenever we can).”
Scrumbut is basically avoiding problems instead of solving them. This prevents from
taking full advantage of Scrum.
Here are only some of the Scrumbuts, but there can be an endless list of them.
1. Goalless, soulless Scrum8
Doing goalless Scrum means doing Scrum just to follow the fad. Before choosing to use
Scrum the company should be sure that the project can benefit from using Scrum.
Knowing that Scrum is the right framework for the project encourages to follow all its
rules willingly, not trying to cheat someone or yourself in every possible occasion for a
workaround.
Soulless Scrum refers to “practicing Scrum by rote” (Bunning, R.). It means using
Scrum as a set of instructions without responding to Scrum’s call to think critically,
observe, inspect and adapt. Soulless Scrum inevitably lies on the way to Scrum’s
understanding. Until it is fully understood it will be soulless.
2. Fractional theory implementation and premature Scrum adaptations
Some Scrum novelties bring so much excitement (Daily Scrums, light documentation)
that others not so appealing parts remain overlooked. It’s a typical Scrumbut which
results from not following the Scrum Rules. The worst of ignoring even one element in
7 Schwaber, K., Sutherland, J. 2013. Scrum Guide. Scrum.org.
8 Bunning, R. (2009) Kicking Scrumbut. Scrum Alliance.
16
Scrum is that it may endanger the success of the whole project. According to Kent
Beck, one of the 17 signatories of Agile Manifesto: “If you follow 80% of the process
you get 20% of the benefits.”9
As far as premature optimization is concerned, once Scrum practitioners learn that
Scrum allows adaptation for every particular organization they try to tweak it right away
without implementing Scrum as prescribed, not even once. Without trying a complete
Scrum a novice might confuse his implementation failure with the limitations of Scrum.
That’s why Bernd Schiffer’s (Agile coach, trainer and consultant) advice for novices is
to “do Scrum by the book” in order to “internalize the essence of Scrum” first10
.
3. Protracted planning
Scrum is delivery orientated. So it values doing over talking about doing, i.e. planning.
The planning must be enough to only get started. There is no need in big up-front
planning which makes Sprint planning last days instead of prescribed 3,5 hours. The
rest comes in process through frequent feedback and adjustments.
To avoid planning paralysis Rowan Bunning suggests grooming the Product Backlog
and dedicate 5-10% of the effort to prepare future work11
.
4. Scrum Master in a role of a project manager
Keeping a manager or having Scrum Master telling the Development Team what to do
is a gross Scrumbut. The teams in Scrum are self-managing and self-organizing as seen
in a previous chapter. Scrum Master has no authority over the Team, he is only there to
facilitate communication, remove impediments, protect the Team, and watch Scrum
rules are followed.
5. Competition among the team members
If the Team members compete with each other this Team is doing Scrumbut. There is
no place for an outstanding individual in Scrum. The Team must move forward as a unit
driven by the common goal. The whole team is responsible for the failure as well as the
whole team gets credit for success.
9 Bunning, R. (2013). A Simple Formula for Becoming Lean, Agile and Unlocking High Performance
Teams. 10
Schiffer, B. (2013). Blasphemy! They Call It Scrum! Agile Trail. 11
Bunning, R. (2009) Kicking Scrumbut. Scrum Alliance.
17
6. Rehearsed demos
Scrum allows only demonstrations of “Done” functionality. Everyone might have his
own understanding of “Done”, that’s why Scrum forestalled misunderstandings by
introducing the obligatory “Definition of Done”. Everything presented at the demo
meeting must be done according to this definition since the Product Owner who is
presented to will believe it is really “Done”. If the team prepares the demo in a way the
bugs they are aware of won't come up this team is doing Scrumbut.
7. Overcommitment
There may be many reasons for overcommitment: pressure from the outside
management, the desire of the developments to please, not being accurate with
estimates, being too optimistic and others. Overcommitment can be dangerous because
it causes the feeling of failure. Scrum Master should help the Team in this case to find
out what the team’s capacity is, first of all by removing the outside pressure.
8. Problem recurrence
If the team reports the same issue from Retrospective to Retrospective meeting it means
that it is doing Scrumbut instead of Scrum. That means that the Team has got stuck
between inspection and adaptation phases in the empirical control process. Any
deviation detected should be adjusted as soon as possible. If it’s not done during the
following Sprint then it is most likely that Sprint Retrospective meetings are not
realized correctly. They should close having a set of specific actions for the problems
solution.
5.1. Good and bad Scrumbuts
Scrumbuts are often seen as dysfunctions, although not necessarily it is so.
At first sight it might be hard to tell between a Scrum adaptation (good adaptation) and
a Scrumbut (bad adaptation). Both of them are Scrum deviations. Scrum deviation is a
Scrum framework alteration. It happens when at least one essential Scrum element is
replaced by a new one. Good deviations are those that remain within the Scrum
framework, stay in harmony with all Agile values and principles, i.e. all the intentions
behind the original element are met after replacing it with a new element. For example,
if a Daily Scrum is held once a week it’s a bad deviation since the intentions of the
18
transparency and Team synchronization are not met. Whereas if a Daily Scrum is held
every 2 hours it’s a good deviation because all those intentions are still met12
.
So on the one hand all the Scrum rules must be followed to be able to call it Scrum, on
the other hand we know that good deviations also happen. This conflict can be
explained with the help of the skill acquisition model Shu Ha Ri. This model was
borrowed from aikido and introduced to Agile community by Alistair Cockburn. The
stages on the way to mastery are as comes from the name:
Shu - the 1st stage, novice level. A novice only follows the rules and of all the
possible options he picks the one he was taught.
Ha - the 2nd stage, expert level. Experts already know the basics, so they start to
learn the underlying principles, learn from other people, dig into theory behind
the technique. They are allowed to break rules.
Ri - the 3rd stage, master level. Masters don’t need rules, they don’t learn from
others’ experiences any more but their own. Masters can create their own
approaches.
So the adaptations made by someone of Shu level are Scrumbuts. Shu level practitioners
must strictly follow the book13
(Scrum Guide by Ken Schwaber and Jeff Sutherland and
the Scrum Alliance’s Core Scrum statement). The adaptations made by those who
achieved Ha level are good deviations since those practitioners already feel the essence
of Scrum and understand all the implications of the changing of an essential Scrum
element.
Moreover, Scrum deviations are desirable and even necessary for improving Scrum.
Scrum elements must be questioned and reinvented if needed. In other words the
philosophy “Inspect and adapt” that Scrum promotes should be applied to Scrum itself.
Here is an example of a good deviation.
In July 2011 the prioritized Product Backlog was replaced by an ordered Product
Backlog in Scrum Guide. James Coplien, Software Architecture and Agile Consultant,
explains the reasons why the Product Backlog should be ordered with a smart example:
12
Schiffer, B. (2013). Blasphemy! They Call It Scrum! Agile Trail. 13
Schiffer, B. (2013). Blasphemy! They Call It Scrum! Agile Trail.
19
he suggests imagining the project of building a house in the tropics with the main
purpose of protecting you from the afternoon rain that comes every day. Being roof of
the highest priority, a prioritized Product Backlog would start with the roof which
doesn’t make any sense. This erroneous reasoning happened because Scrum requires
delivery in order of providing the highest business value. And this is often understood in
a wrong way: most people think of each Product Backlog Item’s single ROI as priority
whereas the entire Product Backlog should be considered. When ordering the Product
Backlog, ROI must be perceived as a long-term result of the total Product Backlog
ordering, not a sum of single ROI’s of each PBI. As Coplien says, using now ordering
instead of prioritization entails Product Owner making decisions: “He or she cannot just
say “These five items are all priority 1; these three items are priority 2 and so forth. The
product owner must deliver a totally ordered Product Backlog.”14
Through inspection the leaders from Scrum community detected that prioritization is
just one of the ways to order Product Backlog and priority orderings are not always the
best orderings. This change would never have been possible if nobody questioned
Scrum elements.
14
Coplien, J. (2011). It’s Ordered -- Not Prioritized! Scrum Alliance.
20
6. INCUBIO
The following phase of my work was the examination of Incubio with the purpose of
finding out whether the company adheres to the Scrum rules and what Scrumbuts they
do if any.
Incubio is a startup incubator. It specializes in technological projects related to Big
Data. It offers support to the entrepreneurs from the concept development phase to the
private investment phase.
Each incubated company - there are 10 at the moment - is a project for Incubio. Scrum
was chosen for project management across all the company more than 4 years ago by
the chief financial officer.
6.1. First interview. Acquaintance with Incubio
I had an opportunity to interview Albert Roig first who is VP Engineering in Incubio.
He gave me a general outline of a Scrum process in the company.
Albert joined the Incubio 4 years ago and entered as a Project Manager. Although the
company had already introduced Scrum the “Project Manager” title still existed, which
contradicted Scrum basic principles. This was almost the first thing Albert told me. By
voicing this he assured me he would be sincere and self- and company-critical if
needed.
Albert had worked as a Project Manager before. He says he had applied about 50% of
Scrum techniques to the Project he was managing without having heard about Scrum.
He introduced short iterations, established daily meetings, reviews, made the team
communicate, he didn’t intervene, only watched, etc. Later he completed a Course on
Scrum and got certified as a Scrum Master.
The fact that Albert applied Scrum techniques without knowing anything about Scrum
describes him as a clever and sensible professional. The way he explained everything to
me gave an impression of his complete understanding of a process, awareness of all the
cause-and-effect relations in Scrum.
Having a pro-Scrum person in an upper management position definitely benefits Scrum.
Just as well as in any other domain anything is more likely to work well with a positive
attitude.
Today Albert is like a “Chief Scrum Master” for the incubated start-ups. He watches the
process and helps when necessary. The teams often need help since a few of the team
21
members are experienced enough. We talked with him about how the Scrum works in
general for every team in Incubio.
6.1.1. Scrum Team
Incubio’s organigram in terms of IT management is rather special.
Scrum Master or Product Owner roles are not entirely fulfilled by the team members.
Product Owner ideally should be a founder of a start-up, the author of the approved by
Incubio idea, the one who has a clear vision of his product. However, they (founders)
are normally too busy to manage Product Backlog or some of them simply don’t believe
in Scrum.
There is one person inside the team who performs as a Scrum Master, but he may lack
training or experience in this role.
So these two deficiencies are covered by the certified Scrum Master Albert and his 2
colleagues experienced in Agile and Scrum. They are formally called IT managers and
informally - tech leads.
All the incubated start-ups are assigned among these 3 persons. They stay in close
collaboration with the teams, watch their performance intervening as Scrum Masters in
case the teams need help with some impediments in their work.
A tech lead works together with the Product Owner to help him manage the Product
Backlog and he works together with the Scrum Master to solve issues with the team or
Scrum process.
22
Figure 2. Incubio's Organigram
The teams often include interns. Sometimes a little-subsidized project start out with the
Team composed of only interns. Further in process they get a senior.
Albert shared an observation from his experience with me: even though Scrum doesn’t
recognize leaders, a leader always happens in any Team. It is clear in case there are
interns, but this is also confirmed for the teams of senior members.
In Incubio all the interns are called juniors. This is an intention of making a team more
uniform if not in action at least on paper. Albert is against this practice. He says
everyone should be called appropriately and should have the responsibility according to
what he is.
6.1.2. Scrum Master Performance
By having tech leads and Albert as a kind of a “chief Scrum Master” each internal
Scrum Master secures himself from what he might overlook. This way the internal
Scrum Master has the opportunity to learn Scrum by doing.
VP Engineering
Start-up 1
Internal SM
PO
Dev. Team
Start-up 2
Internal SM
PO
Dev. Team
Start-up 3
Internal SM
PO
Dev. Team
Start-up 4
Internal SM
PO
Dev. Team
Start-up 5
Internal SM
PO
Dev. Team
Start-up n
Internal SM
PO
Dev. Team
IT Manager (Tech Lead)
IT Manager (Tech Lead)
23
I asked Albert whether he could give me examples of some issues they solved
inspecting and adapting. Albert told me about one project the team members of which
were complaining at the meetings about confusion and not having things well-defined.
Internal Scrum Master couldn’t figure out what was causing the problem. Albert had to
take the initiative to fix it. The problem was solved by simply specifying the definition
of Done.
6.1.3. Visibility of the process
All the Incubio’s projects use JIRA software which allows keeping Product Backlog,
Sprint Backlog and Scrum board visible to everyone.
The whole view of a Scrum board in JIRA doesn’t fit the screen. Incubio has learned by
experience that the real-life board works better and provides better visibility, therefore
JIRA’s Scrum Board is not used. Instead, there is a real-life Scrum Board on the wall
for each team. The board is divided into 3 vertical parts: To Do, In Process and Done.
The cloud of stickers with tasks travel from left to right as the project proceeds. Scrum
board is perfect for Daily Scrums, noted Albert. There was a Project that didn’t use the
board, but as soon as they introduced it they admitted its advantages.
6.1.4. Workflow
Sprint
Every Sprint lasts 1 or 2 weeks depending on the functionality to develop. The
functionality is not so complex to have Sprints of 1 month. The complexity lies in the
fast-paced, extremely competitive and uncertain environment.
Events
As far as Scrum events are concerned the Teams comply with all of them: Daily Scrum,
Sprint Review, Sprint Retrospective and Next Sprint Planning.
The Next Sprint Planning is not time-boxed as Scrum prescribes. It starts 2-3 days
before the current Sprint ends. Every member of the team has enough time to provide
better estimates. During this time the team-members can assess the task with all its
implications and foresee difficulties. The real Next Sprint Planning adds up to a short
planning poker. Planning poker, or Scrum poker, is an estimating technique that allows
24
avoiding the cognitive bias of anchoring when the first pronounced estimate influences
all the subsequent ones.
After the estimation all the tasks are put on a Scrum board inside the To Do part.
At the Sprint review meetings only Done functionality is presented because almost
always the Product Owner chooses to release the Increment.
At the Sprint Retrospective meeting the team discusses the problems they met during
the Sprint. They often come across personal issues. But if someone doesn’t feel at ease
there are no barriers, people switch the teams and as a result everyone ends up in a team
where he feels comfortable.
6.1.5. Product Backlog
The Product Backlog is managed by the Product Owner (usually CEO) and a Scrum
Master. They write together user stories. The Product Backlog contains requirements for
a period longer that one Sprint. It is not too extended due to the fast-paced environment
the incubated companies have to survive in. The CEO may receive an order from a
client and in order to keep this client the functionality he asks will be made priority 1 to
be delivered in one week.
6.1.6. Human resources activities
Incubio seeks after every member of the company accepts and shares its mission and
vision. This supposes not to do only the things they know or the way they know. This
supposes meeting the high quality requirements established by the company. For this
purpose intragroup dynamics are conducted. As Albert says, this helps to look up the
monitor. When the teams get the task they usually start looking for a solution among
their resources: their skills and knowledge, technology with certain limitations. During
the group dynamics they are made to forget about limitations, they told to imagine
anything they need is available. And only then they are asked what they would like a
product to be, how they see it.
Although it’s a very powerful exercise, not any person would be able to switch from the
problem based on some technology limitation to the idea of unlimited resources. That’s
why a lot of attention is paid to personnel selection. The suitable profile for the
company is an initiative, flexible, proactive person willing to learn.
25
6.2. Second interview. Quizlyse
The second person I interviewed was Jose Manuel Perez, the CTO of Quizlyse, one of
the incubated start-ups. He has a role of a Scrum Master in Quizlyse team. I had an
appointment with him for watching them do the Daily Scrum. Unfortunately one hour
before my arrival 2 team members had been fired. So I found the team rather surprised
and a little bit discouraged. The Daily Scrum was cancelled, still Jose Manuel agreed to
answer my questions.
Jose Manuel joined Incubio 6 months ago and started as a Scrum Master for Quizlyse
team of 6 people. He came with a previous experience of 6 years in Agile Project
Management.
He confirmed everything Albert had told me. As an example of the applied inspection-
adaptation Jose Manuel told me about the problem with documenting effective time
spent on tasks. The team was taking this activity for pure bureaucracy and simply
copied estimates instead of putting down the effective time. Together with Albert they
held an explanatory meeting talking about the benefits of having the control of effective
time spent. In addition they offered techniques to better manage those records. That is
when Pomodoro technique was introduced. This is a time management technique that
prescribes breaking work in short intervals up to 25 minutes. Those intervals must be
separated by breaks.
As far as “iterations as learning cycles” is concerned, Jose Manuel noted that his team
has advanced a lot in estimating since he came. However in the complex environment
anything can happen so sometimes the estimates are not met and some tasks have to be
moved to the next Sprint. If the reason for that is not justified enough Jose Manuel
receives a complaint from the Product Owner. All the necessary investigation is done to
prevent it from happening again in the future.
Yet, I learnt one curiosity about Quizlyse. By a lucky for me accident Quizlyse turned
out to be the start-up with the Product Owner (also CEO) who didn’t believe in Scrum.
The CEO has never been trained as a Product Owner and acts a little like a real
customer. Instead of being a bridge between the technical and business environments he
only represents a business environment. For instance, he assigns equally high priorities
to several requirements, doesn’t specify the order and expects all of them to be done
simultaneously. He is also displeased with the team using JIRA software, doing all the
estimates procedure. He sees that as a waste of time, because everything could be done
26
in an excel sheet according to him. Jose Manuel sounded annoyed when speaking about
the Product Owner. Although it could be because of the upsetting incident with his
workmates dismissal, I got the impression of a tension inside the team.
6.3. Third interview. Groupiest
Groupiest is the next start-up I got acquainted with. I was invited to the Daily Scrum at
10 a.m.
The meeting began at 10 o’clock sharp. All the team members were standing in a circle
in the middle of the room they work in.
Figure 3. Daily Scrum at Groupiest
The Product Owner had been on a business trip the previous week so he started the
meeting with telling the team the news from the trip. Then the member who is in charge
of marketing spoke. Those were apparently the people who had no problems with
speaking up, because after them the Scrum Master had to name every next person to
make him speak. Although the Scrum Master was guiding the meeting he was not
perceived as a boss to report to. Each one was reporting to the whole team. I could see
all the members knew each other’s problems, so they really use Daily Scrums for
27
synchronization. Moreover they are all aware of that it is only for synchronization, not
for problem solving; because whenever someone deviated from keeping it concise there
was always someone who would stop that tactfully. I could see everyone was feeling
comfortable and easy, they were ready to help each other and there was a friendly
atmosphere in general.
After the Daily Scrum I talked to the Product Owner (Guillem) and the Scrum Master
(Xavi). I really enjoyed talking to them because they were transmitting excitement
about Scrum and about everything they were doing. They spoke knowledgeably about
every Scrum practice I asked. For example their team is the only one in Incubio that
doesn’t use a Scrum board. They use the board provided by JIRA. Thanks to that they
can have Daily Scrums with the remote teammates or when on a business trip. They
have also tried various durations of a Sprint and decided that a 2 week Sprint suits them
best.
They two told me about the advantage of having a team of juniors. First of all, juniors
learn whatever they are offered, they are younger and easily accept changes, whereas
seniors would try to apply the knowledge they already have by all means. Secondly,
Groupiest employs the technologies that are not widely used so it’s also complicated to
find an expert in the domain. Before talking to them I was convinced that having the
teams composed of juniors was definitely a Scrumbut. Guillem and Xavi made me
change my opinion.
The CEO, who is also a Product Owner, is only 22. He is multidiscipline: has both
technological background and business expertise acquired in the projects he
collaborated. He manages the Product Backlog. The marketing people sometimes give
him advice but he is the only one who has access to modify the Backlog.
They also said that their estimates are so accurate and even keep on improving that in no
time they would be able to do up to 3-month planning, as in Waterfall - added Guillem.
And both burst out laughing surprised by the “discovery” of a pseudo point of contact
between Agile and Waterfall.
28
7. CONCLUSIONS
I perceived a very friendly and creative environment in the office of Incubio with the
colorful stickers and graphs all over, creative mess on the tables, smiling people.
Altogether that gave me an impression of no problem with efficient communication
which is often an obstacle for a good project progress. Work area is an open area, no
cubicles, no partitions.
There is no doubt Incubio is Agile. It follows all the Agile values and principles:
the teams deliver working software iteratively;
the customer collaboration is perfect since the customer (CEO) forms part of the
team in a role of a Product Owner;
the teams are self-organizing and self-managing, there is no control from above;
requirements changes are expected and accepted;
motivated individuals form up the teams;
working space is perfect for communication and close collaboration.
With regard to Scrum application Incubio’s case is very particular.
On one hand all the Teams work in time-boxed Sprints; bottom-up thinking is enabled
and empiricism is put into practice. Incubio’s Scrum is not “soulless and goalless” for
most people agree that following an iterative Agile methodology is the only suitable for
them way to manage the work. All the adaptations they make get approved by VP
engineering and tech leads who are Ha level practitioners. “Cherry-picking practices”
Scrumbut was not detected either, since all the practices prescribed by the Scrum Guide
are respected. There are no rehearsed demos, overcommitment or problem recurrence.
Scrum Masters don’t act as project managers: all the projects are left to survive rather
than managed which allows creative solutions and insights in the environment the start-
ups operate. Protracted planning was avoided by introducing the hack of starting
planning 2-3 days before the current Sprint ends.
So Scrum Prescriptions are generally respected.
On the other hand the existence of the VP Engineering and 2 tech leads puts the project
management of each start-up in a controlled environment, hence makes it a little
artificial. Incubio states its philosophy as “Practice is the only way to learn” and call
29
themselves The Big Data Academy. According to what I saw inside Incubio I would
also call it The Scrum Academy. There are 3 Ha-level practitioners who ensure the
young start-ups “follow the book”. Groupiest is already a mature project with a solid
team so they are given more freedom and are allowed to deviate from the theory.
A significant part of Scrum implementation success depends on the people. In Quizlyse
Product Owner creates somewhat of a tension because by seeing JIRA useless he might
not believe his team is busy doing something useful for him. Therefore there might be
distrust. This is a Waterfall leftover. Quizlyse would benefit from having a pro-Scrum
Product Owner but the business model of Incubio’s projects is such that the idea author
is a Product Owner. In the end “the art of the possible” has to be applied. “The art of the
possible” is what ultimately Scrum promotes which means “we do the best we can with
what we have”. 15
In conclusion I would sum up that Scrum success in Incubio is ensured by Albert and
tech leads who are Scrum coaches in fact. But their influence has effect only until it
runs into human factor on a single project level. Groupiest’s Scrum is definitely Scrum.
Quizlyse’s Scrum is a Scrumbut strictly judging because of the Product Owner.
Thanks to this project I have seen in a real company that people are the most important
component of a project. No methodology has an in-built mechanism to deal with the
human factor.
In addition, Scrum has taught me some principles I will definitely apply in my life both
personal and professional. For instance, dealing with complex tasks: if you don’t know
what to do - do something. Some tasks can be so complex that the whole picture doesn’t
show up itself, neither does the plan draw up itself. In this case Scrum suggests starting
doing and see what happens. The first positive, even though insignificant, outcome may
be often enough to get inspired in order to continue, Time-boxing is another practical
idea I have borrowed. These two pieces of advice are extremely effective against
perfectionism and procrastination.
15
Schwaber, K (2011). Empiricism, the act of making decisions based on what is. Ken Schwaber’s Blog:
Telling It Like It Is.
30
8. BIBLIOGRAPHY
1. Schwaber, K. 2004. Agile Project Management with Scrum. Microsoft Press.
2. Mezick, D. (2010). Interview with Ken Schwaber, Part 1. InfoQ, Retrieved June, 2014,
from http://www.infoq.com/news/2010/08/kenschwaber-interview-part1.
3. Benington, Herbert D. (1983). "Production of Large Computer Programs". IEEE
Annals of the History of Computing (IEEE Educational Activities Department) 5 (4):
350–361.
4. Beck, Kent; et al. (2001). "Manifesto for Agile Software Development". Agile
Alliance. Retrieved June 2014 http://www.agilealliance.org/the-alliance/the-agile-
manifesto/.
5. Cohn, M. (2008). Advantages of the “As a user, I want” user story template. Mountain
Goat Software. Retrieved June, 2014, from
http://www.mountaingoatsoftware.com/blog/advantages-of-the-as-a-user-i-want-user-
story-template.
6. Marcano, A. (2011). Old Favourite: Feature Injection User Stories on a Business
Value Theme. Antonimarcano.com. Retrieved June, 2014, from
http://antonymarcano.com/blog/2011/03/fi_stories/.
7. Beck, Kent; et al. (2001). "Manifesto for Agile Software Development". Agile
Alliance. Retrieved June 2014 from http://www.agilealliance.org/the-alliance/the-
agile-manifesto/
8. Jansma, N., Mulder, T., Nikhogosyan, M. (2011). Scrum Beyond Software. How
Dialogues Incubator Goes Agile (Online). Retrieved June, 2014, from
http://www.dialoguesincubator.nl/wp-content/uploads/2011/06/scrum.pdf.
9. Schwaber, K., Sutherland, J. 2013. Scrum Guide. Scrum.org. Retrieved June, 2014,
from https://www.scrum.org/Scrum-Guide.
10. Bunning, R. (2013). A Simple Formula for Becoming Lean, Agile and Unlocking
High Performance Teams. Retrieved June, 2014, from
http://www.slideshare.net/rowanb/a-simple-formula-published.
11. Schiffer, B. (2013). Blasphemy! They Call It Scrum! Agile Trail. Retrieved June,
2014, from http://agiletrail.com/2013/03/27/blasphemy-they-call-it-scrum/.
12. Bunning, R. (2009) Kicking Scrumbut (Online). Scrum Alliance. Retrieved June,
2014, from www.scrumalliance.org/resource_download/1122.
13. Coplien, J. (2011). It’s Ordered -- Not Prioritized! Scrum Alliance. Retrieved June,
2014, from
http://www.scrumalliance.org/community/articles/2011/august/it%E2%80%99s-
ordered-%E2%80%94-not-prioritized!
14. Schwaber, K (2011). Empiricism, the act of making decisions based on what is. Ken
Schwaber’s Blog: Telling It Like It Is. Retrieved June, 2014, from
http://kenschwaber.wordpress.com/2011/05/03/empiricism-the-act-of-making-
decisions-based-on-what-is/.
31
ANNEX 1
Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas
© 2001, the above authors
this declaration may be freely copied in any form, but only in its entirety through this notice.
32
Principles behind the Agile Manifesto
We follow these principles:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Welcome changing requirements, even late in
development. 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.
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.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
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 behavior accordingly.