How To Outsource Scrum Projects
How To Outsource Scrum Projects
1. Introduction
2. Why do outsourcing?
a. Organisations culture is the first step
3. Why Scrum?
a. How does Scrum work?
b. Scrum vs Scrum-but
c. To Scrum or not to Scrum?
d. Which companies use Scrum?
4. How to choose the right team?
5. The art of cooperation
a. How to cooperate?
b. Cultural fit
c. How to gain trust?
d. How to choose the right cooperation model?
e. Fixed time, fixed prices, fixed scope
f.
g. Agile, Scrum
6. This is an investment
7. Why not to outsource?
8. Useful tips
9. Are your ready ?
10. Want to know more?
1
Introduction
This is a document which fulfils the need for information. It answers the
questions that inseparably go together with modern challenges of running
a business. Modern business more and more often creates a vision and
influences consumers towards following this vision and the product value it
implies. Rather than creating a product alone, it creates a need and value.
Thats why this free e-book is for business owners and managers. For
decision makers, who need tailored software which realises the initial idea
for the application.
As the authors of this publication, we believe in Scrum, we are its everyday
users. If theres a need to get familiar with it, this document provides the
necessary knowledge and practical tips.
We have made it to help decide on choosing the best possible way to
outsource software projects. We have also addressed the issue of Agile
and Scrum and the very important companys culture, as a part of natural
conjunction between the quality expectations and the final outcome.
The envisaged result of reading this document would be a better
understanding of the outsourcing itself and the challenges it predicates.
The process of making this e-book was based on the knowledge of the
topic itself. After researching the common and available knowledge (some
of which was used here, along with some graphic materials), we decided
on making something of our own authorship.
If the Reader knows Scrum already, we suggest skipping the contents and
heading straight to section 4.
The Authors
2
Why do outsourcing?
Venture Pact
http://bit.ly/1H7r83H
3
4
http://bit.ly/1ELHrSX
http://bit.ly/17RD3H2
3
Why Scrum?
The immanent characteristic of software is that its open to constant
development. Years ago, programmers noticed that traditional methods of
making software were less efficient than expected. Then some of the
developers started to find more effective frameworks to what they did
everyday. Nobody wanted to waste time and money.
On the other hand, a popular approach to outsourcing is still the Waterfall:
highly structured physical environments in which after-the-fact changes are
prohibitively costly. It is a sequential design process in which progress is
seen as flowing through the phases of Conception, Initiation, Analysis,
Design, Construction, Testing, Production/Implementation and
Maintenance. Once its done - its done. Changing or shifting things during
the period of making the software brings consequences - longer time of
making the software, longer exposure to stress produced over the process
of change. In Scrum its possible to make changes on-the-fly and
mandatory to cooperate.
A key principle in Scrum is its recognition that customers can change their
minds about what they want and need. This allows to recognise the
requirements late and cleverly respond to emerging business changes
without budget overruns.5
Scrum adopts an empirical approach: a problem cannot be fully understood
and defined, therefore the focus should be on delivering quickly and
responding to changes.
Scrum fulfils the
Manifesto for Agile Software Development6, which says:
omprehensive documentation
Customer collaboration
over
contract negotiation
Responding to change
over
following a plan
Following this come
12 Principles of Agile Software Development7
1.
http://bit.ly/1GlOq9S
http://bit.ly/1vDH6iO
7
http://bit.ly/1aLadtO
6
and the Partner, and makes sure the process supports Transparency,
Inspection, and Adaptation. And there goes the Development Team: in
Scrum its a self-organised team, which delivers a working product every
Sprint. The progress of work of the Development Team is transparent and
visible to all products stakeholders.
The main advantage of iterative approach is that the Partner receives a
working, and therefore valuable product, every Sprint. In Waterfall, a part of
the system can be delivered during the project, but these parts are not
designed to give business value before the project is finished:
Scrum vs Scrum-but
Scrum is easy to learn, but difficult to master. And Scrum is the most
wanted method in the modern software development. These reasons make
some developers unable to deliver Scrum Teams, even if they want to
prove they can. Sometimes the Partner can hear software companies
saying: Yes, we work in Scrum, but we found that only parts work for us.
This might be the first signal that such development company didnt master
Scrum.
Scrum-but isnt Scrum and might be dangerous
because it puts
Scrum Team off the balance and often results in Development being not
predictable and not accountable at all.
10
We are showing this example, but the outcome of cases above depends on
research methodology and we encourage readers to look into the matter.
12
4
How to choose the right
team?
The chart below shows the correlation among technology, requirements,
and
people building a software
http://bit.ly/1EsoWoC
13
Here are some key factors worth considering when looking for the right
Scrum Team:
Knowing and accepting the complicated nature of technology and
possible changes in the requirements regarding the product, the
team is capable of addressing challenges along the way properly.
Can they prove it by showing a number of completed, successful
projects? How would they approach a problem if the business
needed to change; when would they introduce the change? What is
their standard Definition of Done?
How responsive is the team and to what level does it welcome the
changes to the vision, direction, and the code itself? Do they treat
email/chat/video communication as a part of the job, or as a
distractor from programming? Do they welcome changes during a
Sprint and if so, would they later blame you for not delivering the
software? Who do they think is able to change requirements
besides Product Owner?
Is the team focused enough on a specific technology? What is their
technology stack of choice? How long have they used it? What is their
quality process? Can they name the biggest downsides of the
development stack? How do they assess if the given technology is
able to solve a business problem efficiently? What is their most
remembered problem when it comes to the technology, and how did
they deal with it?
Are the members tight together and have they got cohesive skills,
or are they a bunch of individuals? Do they understand
consequences of the changes in the code provided by themselves
and the team10? How long have they worked with each other? How
many projects have they left behind finished? In Agile,
understanding each other is the key. Can the outsourcing company
tell you whether the team assigned to the project will be a project
team (the one that is built for the project) or a permanent team? If it
is a permanent team, at which stage of teams development is the
particular team now?
10
http://bit.ly/1ajdqk1
14
11
12
http://bit.ly/1emDuLI
http://bit.ly/1MQQaZL
15
5
The art of cooperation
How to cooperate?
When a decision to outsource is made, there is the matter of how to work
with a subcontractor. The goal is to make your project proceed in the right
way.
Cooperating with the Partner benefits from understanding and
trusting each other and not hiding problems
. Properly built cooperation is
an important factor in achieving dedicated business goals, so its important
to find the right way of cooperation.
Product Owner might be the incarnation of the Partner or may work on the
developers team side. Product Owner is like the Partners eye, ear, and
hand. Thus, the Product Owners principal task is to take care of the
business like it was their own. Thats why this is the first person with whom
the Partner needs to build a relationship wisely.
If it is possible (and it should be), the Partner should meet Product Owner
face to face, it would allow the PO to better represent the Partners point of
view. However, even if for some reason its impossible to meet directly with
the PO, there are many ways/tools of constant communication with the PO
and the entire team.
A good opportunity to meet the team and to familiarise with them is
Project
13
Workshop .
Project Workshop is the analysis of the Partners requirements, vision of the
product, its needs and expectations. Does it have an impact on the
business value? Of course the better the team understands the Partners
needs and requirements, the greater is the chance for the realisation of
13
http://bit.ly/1FgxbFh
16
business objectives.
Theres no doubt that well thought software brings
the desirable benefits
. The first step is to find the right way of cooperation.
Software development is a complex and multistage process extended in
time. The process binds the cooperation of many people that have to go in
one direction. Therefore, all participants must have a sense of community.
If you let one another to know your goals, it will be a successful and
satisfying journey for all of you.
Cultural fit
We must keep in mind that the team is not a set of robots, but a bunch of
real people.
A team is more than the sum of its members. The Partner
should treat the team as confident co-workers
. Most of programmers are
very ambitious, and if the Partner gains their reliance, theyll do what they
can best and with high commitment. Cooperation should get smoothly
through every Sprint and finally they should become well-oiled
(moisturised) machinery that works on high speed with high quality. In a
few Sprints they are going to work almost without any needless words. But
most often it takes some time to upgrade on this level of cooperation.
Obviously, its easier to work together if the Partner and the provider are
culturally aligned to each other.
Some of these aspects of cooperation matter a lot and must be highlighted:
for example, fluent English and common culture. Insight in the technical
and non-technical universum has its importance as well. Do the Partner and
the developer have the same ground, laugh at same jokes, can they tackle
challenges from the same perspective?
To work with the PO and the team is to create the optimal process and
habits of working. The other side is to not be dominated by the process. Of
course, everyone has to respect commonly established rules, but rules are
to serve the realisation of the Partners goals, not vice versa. M
akingbespoke
softwarethatisfoundedonspecificbusinessassumptionsoneneedstostay
openmindedandawaretoprovideflexibleresponsestoproblemswhichappear
. It is
The Partner pays only for the order and only within the given time.
This model refers to the implementation of a predetermined scope of the
project, for predetermined costs, at a predetermined time. The scope of the
project is defined during Project Workshop. This model is designed for
Partners who are able to fully define their expectations (functionalities),
who don't anticipate the impact of any changes in business or ecosystem
on the project, and are sure that functional and non-functional
requirements will not change for the entire project.
18
Agile, Scrum
This is the model in which the Partner pays for a Sprint, with some Sprints
ahead. Thats because the provider cannot guarantee the continuation of
the work on the project by a particular team. Choosing another team and
then making payment for another Sprint requires the new team to make
themselves familiar with the project. The continuation of one teams work
limits the risks.
An integral characteristic of IT projects is their complexity. In every IT
project, which takes at least several months, there are many request for
changes in the scope of work (from 30% to 50%) in response to the
changing needs of the business.
Agile and Scrum require the competence
(know-how) and operational expertise from the developer
.
During the first meeting with the Partners product, vision and high-level
requirements are gathered, based on which the division into system
functionalities (Product Backlog) is taking place. These functionalities are
constantly prioritised by the Partner. Next, there is the planning of a project
schedule (Release Backlog). During every iteration (Sprint), according to
the priorities, functionalities are created and delivered to the Partner.
Theres a need for introducing changes to the project scope during its
development.
Partners should be encouraged to cooperate in the Scrum
model
, where changes are natural and can be added between Sprints to
Product Backlog.
19
Using the Agile approach is great. Even if the project has some constraints
(fixed time, fixed price, fixed scope), with this approach developers can see
an improvement in quality and productivity.
Fix-time, fix-price:
Scrum:
I
n this model of
20
6
This is an investment
Working with a developer in outsourcing environment is demanding, both
sides should invest in the relation; developers Partner should ask if they
are ready for it. The Partner should reserve time for conference calls with
the developer, should prepare him- or herself for talking over the
potentially problematic points (e.g. adding extra functionalities and impact
on future sprints). The Partner isnt just a Client and we dont use the word
in this e-book even once.
The Partner is the vital part of the process and
the awareness of that should be there
.
That also means appointing a Product Owner on the Partners side, that will
be achieved by talking with the development team and keeping a finger on
the pulse of things.
Outsourcing is a complex investment, not just buying a ready-to-use thing.
But Partners start with a ready-to-use team, and they head together to the
designated point - a valuable software product. Therefore, theres a strong
need for special awareness and commitment from the both parties.
Such a venture requires something else than the Partners money. And the
providers shouldnt represent the take-money-and-run approach. The
Partner must take under consideration all factors: threats, risks,
opportunities, and benefits.
A
mature development team, with an
experienced Product Owner ahead, should serve with all the already
acquired knowledge and skills
.
Below you can find the advantages of outsourced software development:
Professional team. Self-organised, aware of the Partners business.
Professional consulting: development with on-going notes and
remarks regarding possible functionalities.
Dedicated project management. Every stage of emerging software
has the attention of both Product Owner and Scrum Master; they
also stay up-to-date with the Partners feedback.
21
7
Why not to outsource?
Outsourcing software development and software services is a great
opportunity to scale business, provide high-quality software faster, and
focus on core elements of the business instead of developing tools
supporting it. But not always.
There are certain situations and reasons against outsourcing that should
be known before taking the decision.
First of all, the Partner might be simply not yet ready for outsourcing. For
many entrepreneurs, outsourcing is not only a tool to optimise cost and
timeline, but a serious risk of transferring unique product know-how out of
the companys country. Building a trust-based relationship with a developer
is the key.
Secondly, outsourcing is neither good for the Partner nor for his or her
business if he or she doesnt know Agile software development or doesnt
see any value in it. The Scrum framework, even though it appears to be
simple, is a difficult and disciplined approach that ignites change and helps
organisation evolve more rapidly with a better risk control, which requires
full focus, openness, and courage. If the Partner is not ready to take up the
glove - we recommend that he or she doesnt, although some
evangelisation always takes place.
Thirdly, outsourcing is always a risk of lower communication and a lack of
transparency between a Partner and a developer. Especially if the Partner
and developer represent different cultures. If the Partners not ready to
invest in online communication channels and regular meetings with a
subcontractor nor to be asked many questions not only before
development, but also during the entire collaboration - we'd rather
recommend reconsideration of the aims related to outsourcing.
Its smart to be careful with quality. Although the result of development will
be easily visible, the quality of software is usually concealed. It's easier to
measure it in the Partners own playground than in the developers one.
Thus, if you are not sure if a developer tests the software properly, it's
may be a good idea to look for an alternative
.
Finally, not only IT companies search for outsourcing opportunities.
Perhaps a reader of this e-book represents a different industry and is only
looking for a software house to develop and deliver what he or she needs.
If so, we're coming back to the trust.
22
23
8
Useful tips
Over 50% of decision makers have difficulties establishing
requirements of the project14 . And over 50% of those change them
during the development. That is why some tips might be helpful.
To avoid throwing money and unnecessary delays, the Partner
might want to consider a few aspects of the project. Its worth
asking these questions:
What is the subject of the product? (What do we want to do?)
What tools, people, and methodologies do we want to use?
(How do we want to do it?)
What happens when all fails? (What is the safety net?)
Make sure a team you choose takes care of the process of making
software as much as you do15 . This directly means that the price
should not be a factor. Good and cheaper teams can be found all
over the world. Good teams that actively participate in the process
are hard to come by.
Take care of Definition of Done in the contract itself. If the software
has passed the required tests, all documentation has been
gathered, and software has the previously assumed code quality,
DoD has been met. DoD should exist as an attachment to the
contract and be established during the negotiations of it.
Analyse who owns the copyright in the created code and make sure
you get the rights to the source code after the release of the
software.
14
15
http://bit.ly/1qJlek0
http://bit.ly/1FnHsfP
24
9
Are your ready ?
Are you ready to have your project made in Scrum? Answer the questions
below and find out.
Can you see the value in outsourcing and the direction from where
it came?
Can you see yourself working in Scrum with the developer?
Can you see the reasons why some teams are better suited for
Are you aware of the necessity of having one decision maker for
the whole time of a project? Can you see the reason why they can
establish contact with you on a cultural level?
Are you aware of Scrum requirements with reference to you as
the Partner on the project?
Can you invest time to give feedback to the development team,
for instance, when they give you feedback on the new ideas and
solutions?
Do you want to follow the changing business environment,
25
Credits:
This e-book was made under collective effort of XSolve crew:
Piotr Majchrzak
Leszek Pietrzkiewicz
Jaroslaw Scislak
26
Managing Director:
Piotr Majchrzak
Contact details:
+48 32 739 09 00
[email protected]
http://www.xsolve.pl
http://www.xsolve.pl/blog/
Designed by
Chilid
Agency
This document can be viewed and shared under the license Creative Commons 3.0 BY-NC-ND.
http://creativecommons.org/licenses/by-nc-nd/3.0/legalcode
27