Working with other rails firms/developers as partners
5 views
Skip to first unread message
Kapil
Dec 1, 2009, 7:09:33 AM12/1/09
to Ruby on Rails meets the business world
We work with some good rails developers/design firms in US or Europe.
I am just posting some notes that I want to share from our experience
of working with some developers as partners.
I am defining partners as good individual developers/designers to
small sized rails shops who work with another rails/design shop on
regular basis.
* Understand the core motivation for partnership - Usually, most
people approach us because they wish to overcome a weakness ( high
cost, lack of confidence in rails , less time but more projects,4 hour
work week) in the resources available to them. Because of our
location benefit, most partners saw a real cost advantage/margin gain
as a result of working with us , and we are able to leverage partners
brand value and increase reference-ability for winning new projects.
* Don't go for partnership in first round - We ask our prospective
partners to work as clients for first few iterations or an entire
project. Most of our partners started out with us as clients, and they
were really impressed to get into long term partnership with us. It
helps partners to understand each other process , communication ,
tools, team, culture etc before committing to something in long term.
There is no harm in going for few dates before marrying somebody.
* Only Look for kickass development and design firms - Partners
should look to acquire skills and gain new competences through inter-
organizational learning as a result of partnering. As a result of
working with some experienced development partners, our team has
learnt best practices and lots of agile process level learning that
has helped us to become more competent.
* Culture, Approach and Process - We follow agile methodology and
have been trying to improve ourselves in this regard. We usually work
with only those rails shops that REALLY do some work through agile
philosophy. So, its very important that your values,process and
culture aligns with each other.
* Remain Loyal - Sometimes, due to external or internal factors,
most rails shops or design shops don't get enough business. In some of
the cases, we didn't work together for months with our partners. We
realized that all the special benefits and discounts for our partners,
we need to make sure that we have certain minimum targets every month
that should be revised in the partnership charter based on mutual
consensus based on various factors. But, at the same time, partners
represent important allies that will remain loyal over time and will
willingly come to the aid or support of the partner firm. It is
therefore worthwhile to continue to nurture and develop them.
* Align your services - Apart from development, there are other
services like product research, project managment, deployment/scaling,
code audits, test coverage, design integration, maintainence etc.
required in a typical rails project. Most people are not awesome in
all the stuff or don't have time/inclination to work on them. So, you
can pick and choose services based on your strengths and let your
partner choose what they are good in and align each other to become a
kickass team.
* Flexible approach to partnering - Few partners wanted us to
engage with clients through them or some partners wanted us to work as
"technology partners". So, we follow two modes
1. Technology Partners - You disclose us as your technology
partner with the client and open up the flow of communication between
all parties.
2. Behind the Scenes - We work behind the scenes and engage with
the client through our partner. This model works well when the other
partner doesn't want to introduce a 3rd party to client and feel
confident handling the necessary communication between all parties.
* Write it Down - Many disputes among partners are essentially
battles of memories. Putting the spoken word on paper has an almost
magical way of moving partners understanding from vagueness to
clarity. Some partners might fear that writing down their agreements
will be misinterpreted as a lack of trust or non-agile way while not
realizing the other benefits of writing their agreements and
objectives. If trust is present, putting agreements in writing will
not diminish it.
Our partnership program has worked well for us.
http://vinsol.com/vinsol-services/partnership-program
What has been your experience with partnership initiatives and
partners ?
Regards
Kapil Bhatia
kapil at vinsol dot com
www.vinsol.com
www.vinsol.com/blog
www.railsbizcast.com
Vinsol is a web consulting company specializing in Ruby on Rails
development since 2005.
I am just posting some notes that I want to share from our experience
of working with some developers as partners.
I am defining partners as good individual developers/designers to
small sized rails shops who work with another rails/design shop on
regular basis.
* Understand the core motivation for partnership - Usually, most
people approach us because they wish to overcome a weakness ( high
cost, lack of confidence in rails , less time but more projects,4 hour
work week) in the resources available to them. Because of our
location benefit, most partners saw a real cost advantage/margin gain
as a result of working with us , and we are able to leverage partners
brand value and increase reference-ability for winning new projects.
* Don't go for partnership in first round - We ask our prospective
partners to work as clients for first few iterations or an entire
project. Most of our partners started out with us as clients, and they
were really impressed to get into long term partnership with us. It
helps partners to understand each other process , communication ,
tools, team, culture etc before committing to something in long term.
There is no harm in going for few dates before marrying somebody.
* Only Look for kickass development and design firms - Partners
should look to acquire skills and gain new competences through inter-
organizational learning as a result of partnering. As a result of
working with some experienced development partners, our team has
learnt best practices and lots of agile process level learning that
has helped us to become more competent.
* Culture, Approach and Process - We follow agile methodology and
have been trying to improve ourselves in this regard. We usually work
with only those rails shops that REALLY do some work through agile
philosophy. So, its very important that your values,process and
culture aligns with each other.
* Remain Loyal - Sometimes, due to external or internal factors,
most rails shops or design shops don't get enough business. In some of
the cases, we didn't work together for months with our partners. We
realized that all the special benefits and discounts for our partners,
we need to make sure that we have certain minimum targets every month
that should be revised in the partnership charter based on mutual
consensus based on various factors. But, at the same time, partners
represent important allies that will remain loyal over time and will
willingly come to the aid or support of the partner firm. It is
therefore worthwhile to continue to nurture and develop them.
* Align your services - Apart from development, there are other
services like product research, project managment, deployment/scaling,
code audits, test coverage, design integration, maintainence etc.
required in a typical rails project. Most people are not awesome in
all the stuff or don't have time/inclination to work on them. So, you
can pick and choose services based on your strengths and let your
partner choose what they are good in and align each other to become a
kickass team.
* Flexible approach to partnering - Few partners wanted us to
engage with clients through them or some partners wanted us to work as
"technology partners". So, we follow two modes
1. Technology Partners - You disclose us as your technology
partner with the client and open up the flow of communication between
all parties.
2. Behind the Scenes - We work behind the scenes and engage with
the client through our partner. This model works well when the other
partner doesn't want to introduce a 3rd party to client and feel
confident handling the necessary communication between all parties.
* Write it Down - Many disputes among partners are essentially
battles of memories. Putting the spoken word on paper has an almost
magical way of moving partners understanding from vagueness to
clarity. Some partners might fear that writing down their agreements
will be misinterpreted as a lack of trust or non-agile way while not
realizing the other benefits of writing their agreements and
objectives. If trust is present, putting agreements in writing will
not diminish it.
Our partnership program has worked well for us.
http://vinsol.com/vinsol-services/partnership-program
What has been your experience with partnership initiatives and
partners ?
Regards
Kapil Bhatia
kapil at vinsol dot com
www.vinsol.com
www.vinsol.com/blog
www.railsbizcast.com
Vinsol is a web consulting company specializing in Ruby on Rails
development since 2005.
Wojciech Kruszewski
Dec 2, 2009, 5:13:52 AM12/2/09
to Ruby on Rails meets the business world
> 1. Technology Partners - You disclose us as your technology
> partner with the client and open up the flow of communication between
> all parties.
Both U.S based client and your partner need to be online in the
evenings?
Cheers,
Wojciech
--
http://oxos.pl = Ruby on Rails development
Kapil
Dec 2, 2009, 8:55:42 AM12/2/09
to Ruby on Rails meets the business world
hi Wojciech,
This "mode" is not referring to the way we communicate. It just says
that our partner declare Vinsol as a development partner to the client
openly instead of our team working behind the scenes with our partner
who is directly managing the project.
As far as communication is concerned,
-> There are two ways of communication :
Synchronous - Frequent team meetings help to build trust and improve
communication. Yes, we also need phone/skype calls for initial round
of talks, sprint planning meeting and retrospectives etc. And we
usually set a schedule convenient to everyone. Usually this schedule
is followed throughout the iteration. And, in addition to that,
product owner and developers are accessible on IMs.
Aysnchronous - A lot of project communication happens asynchronously
through tools like pivotal tracker, basecamp etc.
In case you are interested in knowing more about communication, you
can look at
http://martinfowler.com/articles/agileOffshore.html
and Dean Leffingwell book on scaling software agility that talks about
working with teams in distributed environment also.
http://www.amazon.com/Scaling-Software-Agility-Practices-Enterprises/dp/0321458192
regards
kapil
This "mode" is not referring to the way we communicate. It just says
that our partner declare Vinsol as a development partner to the client
openly instead of our team working behind the scenes with our partner
who is directly managing the project.
As far as communication is concerned,
-> There are two ways of communication :
Synchronous - Frequent team meetings help to build trust and improve
communication. Yes, we also need phone/skype calls for initial round
of talks, sprint planning meeting and retrospectives etc. And we
usually set a schedule convenient to everyone. Usually this schedule
is followed throughout the iteration. And, in addition to that,
product owner and developers are accessible on IMs.
Aysnchronous - A lot of project communication happens asynchronously
through tools like pivotal tracker, basecamp etc.
In case you are interested in knowing more about communication, you
can look at
http://martinfowler.com/articles/agileOffshore.html
and Dean Leffingwell book on scaling software agility that talks about
working with teams in distributed environment also.
http://www.amazon.com/Scaling-Software-Agility-Practices-Enterprises/dp/0321458192
regards
kapil
Reply all
Reply to author
Forward
0 new messages