This question keeps coming up, usually from people who insist that Agile=Flexible. But in fact, the Agile development requires 11-14 key practices (counts vary). One of those key practices is co-location. The simple truth is that outsourcing is incompatible with co-location. You still may be able to make your project work if you outsource it, and it may even benefit from some of the other Agile practices. But it won’t be an Agile project. Links: http://agilemanifesto.org/principles.html
I have to disagree with Paul. I do think there is some outsourcing groups that can be agile. Primarily, it works with an outsourcing group that is located in the same time-zone as the client. If the outsourcing group has the communication model and tools to grant the client a clear view of how the project is going, Agile can work with outsourcing groups. My company, Prosoft Nearshore provides an agile solution to your typical off-shore model. We target companies in the US as our operation is in Costa Rica. Our clients have stated we have increased their Agile presence within their company and have even been more productive than their on-site full-time employees.
The problem with the question is that “agile” cannot and should not be an adjective for “outsourcing.” Agile is a form of XP (Extreme Programming), a development methodology that some tout as the Answer to all programming project management issues, such as those that often crop up in more traditional methods such as waterfall. (Of course it’s not, but many who advocate its virtues are convinced of the rightness of their point of view.) Outsourcing is merely when a company turns to outside help, often cheaper in dollar costs (but just as often more expensive in management costs, product quality, employee morale, and a host of other metrics), to get a specific subset of work done. When outsourced resources are siloed, that is, the project they have contracted to do is self-contained, they have the option to use any methodology, including agile, to get the work done. When outsourced resources are meshed with in-house resources, they would appropriately adopt the methodology used by the in-house talent.
I would agree with Chuck. Agile models are driven by the need of improving productivity. XP/Pair programming ensures to remove the “loner geeks” from the team (In my experience there are lot of engineers – onsite or offsite who love to work alone) and creating a social and productive team which completes the project on Time. I do believe in Agile Outsourcing if you can control the team and technical infrastructure, team depends on. In last couple of projects, I have used social networking tools such as Skype Groups to use Agile methods between different locations such as India and Bulgaria. It can work sizeable teams such as 5-20 people. For large projects, we all know the importance of processes and introducing change can cause a dip in your budget.
I think the terminology is misleading. Surely agile outsourcing would mean being agile at the process of outsourcing and I don’t think anyone actually does that. I suppose what you are talking about is the ability of an outsourcing supplier to utilise agile development techniques and live up to the spirit of the agile manifesto. I remain to be convinced of the overall business value, especially from India, where CMMi (the antithesis of agile!) was the last big thing.
I have the feeling that Agile Outsourcing just means “We keep our client informed regularly, instead of just giving a monthly report and we don’t work on a list of prerequisites but build it dynamically”. Which to me, unless there’s a fixed price for project, sounds dangerous. Not only for the increase of costs, but for the scope creep you can end up having on the programmer’s side.
In my experience the challenge in Agile outsourcing comes down the procurement or contracting style. If the outsourcer is an extension of the in house organisation (probably T&M with a solid management methodology), I cannot see why there should be differences or bad experiences. It is when you try to do fixed-price outsourced development contracts in Agile mode that gives challenges. Given the incremental and learn-and-build style, it is difficult to completely identify the scope at the beginning of the contract. The result is either the client ends up feeling they are CR’d to death, or the outsourcing firm ends up with massive overruns and feels abused. Outsourcing Agile projects can work just fine, but it requires emotional maturity on all sides, and a very solid contract / project design to back up the project. Links: http://www.linkedin.com/redirect?url=http%3A%2F%2Fwww%2Eajmusgrove%2Ecom%2Fblog%2F2010%2F03%2Fputting-the-contract-in-the-drawer%2Ehtml&urlhash=vnli
I am assuming that your question is supposed to open a dialog with potential customers. The best projects allow for constant dialog between the customer and the development group, with well-bounded scope and plenty of opportunities to make good business decisions regarding the development path of the software. “Agile” is not new…I did it in the 80s, except it was called something less romantic: builds. Even some of the tools are not new….i used a scrum board (although it was a simple white board), we had daily meetings (i moved the chairs out of the room, so they were fast and focused), we did sprint planning, and we did daily estimations of time-to-complete. Outsourcing is not new either. In the 80s, we built big software systems for customers. We were not colocated. Of course, I think in the context of this question, “outsourcing” refers to off-shore development. But some folks would argue that Virginia is a different country then Maryland…. So, lots of folks probably have experience with it. It was called something different. Now, it would be interesting to hear about a truly innovative approach to software project management.
Much of my current work is both outsourced and co-located. Where the outsourcers are prepared to go and live on the client site, I do not see any conflict between Agile and Ousourcing. If this isn’t the case, then there’s a conflict. You will never be as agile as you could be if co-located. But with ready access to the customer and “broad bandwidth” forms of communication, this need not be a killer impediment. If it impedes access to the customer, then you will find it difficult to be very agile – information provision needs to be planned; information needs to be stored, and you will need to make assumptions and fix them when they turn out to be wrong. This latter, if the schism between customer and developer gets worse, will create a further schism between developer and tester. Unless you’re careful you are back to ‘traditional’ and not very agile at all. For these reasons, I don’t care about Agile Outsourcing; that in itself is not the problem. The real problems are by no means unique to Outsourcing. : I note that several of your other respondents equate “agile” to specific sets of practices. They are wrong. The Agile Alliance, and the thought leaders in Agile, have never, and will never (IMHO) make ANY practice mandatory. Sure, they strongly recommend some practices (some stronger than others), but it is a fundamental that the practices must suit the context. While early agilists took this as a go ahead to demand the ideal context, a later wave of agilists have taken the ideas and applied them to a much broader range of contexts. Many of your respondents don’t seem to have followed this later wave of agilists and still demand the ideal context. Sure, it’s still the ideal context. It’s no longer absolutely necessary, if you know how to make the requisite trade-offs.
Agile as they rightly say is more in the DNA rather than in the contracts or the practices defined in a manifesto. As Paul rightly pointed out that people (having the agile mindset) have been doing it for more than 2 decades now. From what I understand working for over a decade under various commercial arrangements and project methodologies, there are following important aspects in the genetic composition of a relationship (between a customer and vendor) that can make you agile: 1) Lack of divide in the Tech and Business objectives. Are developers building a business solution OR coding a software? Is their enough conceptual overlap b/w what business is trying to achieve and what the developers are building. Can your lead developer write a spot-on busienss concept document for what he’s getting his team to program? This can be achieved by breaking through the barriers between tech. and business mindsets by pairing up our developers, team leads and project managers with business users on the customer’s end.An evolutionary business analysis throughout the project if you will, as opposed to single spec document and a single project plan. 2) Is the relationship tactical or strategic (Does failure for one means the failure for another – OR does it only mean one unhappy customer (out of too many) which the vendor doesnt care much about. As one of the respondents rightly pointed out requires an emotional maturity at both ends and a trust relationship to generate maximum results. However, if done properly it can deliver amazing results! One interesting approach we’ve found to work which enables agility in the outsourcing contract is to bundle a bit of BPO in to the IT Services contract. Even for a pure IT outsourcing project, add a little bit of BPO. Have the IT vendor allocate a few people at their end to perform a business process (alongside with your business users) that has to be automated by the desired application they’re programming. You’ll set the business agenda for the project whereby the business users (and their outsourced representatives) will be working hand-in-hand with the developers throughout the project all of them aiming at the end business results while taking an intelligent and agile approach best suited to achieve them. Links: https://www.ephlux.com
If I understand correctly, Agile outsourcing here refers to software development methodology or project management practice which are normally used in software houses. Anyways I would try to link it with Agile IT management. Based on my 8 years experience on the customer side of the court, I have worked with companies who deploy their back office applications in pursuance of their strategic business objectives. However the responsibility of managing these systems is solely on the IT department, where very few people have understanding of the business. Such a situation creates what I call as an Ag (isle) IT Management vis-à -vis Agile IT management. In performing technical endeavors, many IT professional don’t understand how they can help the business acquire customer confidence, loyalty and build a value proposition. IT must understand that Customer oriented IT systems not only help gain operational excellence but also enable the business to focus on customer acquisition and retention by helping the management understand the market dynamics, customers needs and wants and demonstrate agility to meet those demands. However management has to manage one very important thing when using new IT systems i.e. “Change”. Is the software really helping the business gain operational efficiency or it is just a replacement of an old legacy application with a new one with more appealing graphical interface. Are the people doing the tasks in the old fashion or any thing new has been incorporated so that overall turnaround time has reduced. Is the cost of using the new software is more than the benefits, hence little or no value addition to business and its customers? Although these may appear to be very simple things and one could argue that these issues are handled amicably by automation, one must consider that the organization culture and management philosophy is very important. Software can deliver good results, if not then bad results. It depends on the management how you want the results delivered. Therefore the environment whether its public or private culture has to be agile. Only then the business can reap the benefit of an IT system if its approach is towards agile business management.
These are my personal opinions. Outsourcing is part and parcel of life no matter which area we take (Manufacturing, Healthcare, IT …) I understand that Agile stresses on co-location but we need to dig one level deep! Now, if you want to be Agile, you have to create sub-Agile (co-located) focus groups and manage all via UC (unified collaborations) systems. The fundamental rule is to establish standard communication systems between inter-agile groups.
Comments are closed.
how can we help you?
Contact us to discuss your business need or a digital initiative. Feel free to submit a business inquiry online.
This question keeps coming up, usually from people who insist that Agile=Flexible. But in fact, the Agile development requires 11-14 key practices (counts vary). One of those key practices is co-location.
The simple truth is that outsourcing is incompatible with co-location. You still may be able to make your project work if you outsource it, and it may even benefit from some of the other Agile practices. But it won’t be an Agile project.
Links:
http://agilemanifesto.org/principles.html
I have to disagree with Paul. I do think there is some outsourcing groups that can be agile. Primarily, it works with an outsourcing group that is located in the same time-zone as the client. If the outsourcing group has the communication model and tools to grant the client a clear view of how the project is going, Agile can work with outsourcing groups.
My company, Prosoft Nearshore provides an agile solution to your typical off-shore model. We target companies in the US as our operation is in Costa Rica. Our clients have stated we have increased their Agile presence within their company and have even been more productive than their on-site full-time employees.
Zintro has quite a number of Experts who might be willing to take a call on this topic. Go to http://www.zintro.com/area2/software%20development and Zintro will help you find Experts who are both qualified & interested. Your identity will not be revealed and doing a search is FREE.
Regards,
Stuart Lewtan
Zintro Inc.
http://www.Zintro.com
Links:
http://www.zintro.com/area2/software%20development
Have you looked this page?
http://freecomputerbooks.com/specialAgileBooks.html
Links:
http://freecomputerbooks.com/specialAgileBooks.html
http://freecomputerbooks.com
The best Agile will always be In-House Agile!
The problem with the question is that “agile” cannot and should not be an adjective for “outsourcing.” Agile is a form of XP (Extreme Programming), a development methodology that some tout as the Answer to all programming project management issues, such as those that often crop up in more traditional methods such as waterfall. (Of course it’s not, but many who advocate its virtues are convinced of the rightness of their point of view.)
Outsourcing is merely when a company turns to outside help, often cheaper in dollar costs (but just as often more expensive in management costs, product quality, employee morale, and a host of other metrics), to get a specific subset of work done. When outsourced resources are siloed, that is, the project they have contracted to do is self-contained, they have the option to use any methodology, including agile, to get the work done. When outsourced resources are meshed with in-house resources, they would appropriately adopt the methodology used by the in-house talent.
I would agree with Chuck. Agile models are driven by the need of improving productivity. XP/Pair programming ensures to remove the “loner geeks” from the team (In my experience there are lot of engineers – onsite or offsite who love to work alone) and creating a social and productive team which completes the project on Time. I do believe in Agile Outsourcing if you can control the team and technical infrastructure, team depends on. In last couple of projects, I have used social networking tools such as Skype Groups to use Agile methods between different locations such as India and Bulgaria. It can work sizeable teams such as 5-20 people. For large projects, we all know the importance of processes and introducing change can cause a dip in your budget.
I think the terminology is misleading. Surely agile outsourcing would mean being agile at the process of outsourcing and I don’t think anyone actually does that.
I suppose what you are talking about is the ability of an outsourcing supplier to utilise agile development techniques and live up to the spirit of the agile manifesto. I remain to be convinced of the overall business value, especially from India, where CMMi (the antithesis of agile!) was the last big thing.
I have the feeling that Agile Outsourcing just means “We keep our client informed regularly, instead of just giving a monthly report and we don’t work on a list of prerequisites but build it dynamically”.
Which to me, unless there’s a fixed price for project, sounds dangerous. Not only for the increase of costs, but for the scope creep you can end up having on the programmer’s side.
In my experience the challenge in Agile outsourcing comes down the procurement or contracting style. If the outsourcer is an extension of the in house organisation (probably T&M with a solid management methodology), I cannot see why there should be differences or bad experiences. It is when you try to do fixed-price outsourced development contracts in Agile mode that gives challenges. Given the incremental and learn-and-build style, it is difficult to completely identify the scope at the beginning of the contract. The result is either the client ends up feeling they are CR’d to death, or the outsourcing firm ends up with massive overruns and feels abused. Outsourcing Agile projects can work just fine, but it requires emotional maturity on all sides, and a very solid contract / project design to back up the project.
Links:
http://www.linkedin.com/redirect?url=http%3A%2F%2Fwww%2Eajmusgrove%2Ecom%2Fblog%2F2010%2F03%2Fputting-the-contract-in-the-drawer%2Ehtml&urlhash=vnli
I am assuming that your question is supposed to open a dialog with potential customers.
The best projects allow for constant dialog between the customer and the development group, with well-bounded scope and plenty of opportunities to make good business decisions regarding the development path of the software.
“Agile” is not new…I did it in the 80s, except it was called something less romantic: builds. Even some of the tools are not new….i used a scrum board (although it was a simple white board), we had daily meetings (i moved the chairs out of the room, so they were fast and focused), we did sprint planning, and we did daily estimations of time-to-complete.
Outsourcing is not new either. In the 80s, we built big software systems for customers. We were not colocated. Of course, I think in the context of this question, “outsourcing” refers to off-shore development. But some folks would argue that Virginia is a different country then Maryland….
So, lots of folks probably have experience with it. It was called something different. Now, it would be interesting to hear about a truly innovative approach to software project management.
Much of my current work is both outsourced and co-located. Where the outsourcers are prepared to go and live on the client site, I do not see any conflict between Agile and Ousourcing. If this isn’t the case, then there’s a conflict. You will never be as agile as you could be if co-located. But with ready access to the customer and “broad bandwidth” forms of communication, this need not be a killer impediment. If it impedes access to the customer, then you will find it difficult to be very agile – information provision needs to be planned; information needs to be stored, and you will need to make assumptions and fix them when they turn out to be wrong. This latter, if the schism between customer and developer gets worse, will create a further schism between developer and tester. Unless you’re careful you are back to ‘traditional’ and not very agile at all.
For these reasons, I don’t care about Agile Outsourcing; that in itself is not the problem. The real problems are by no means unique to Outsourcing.
:
I note that several of your other respondents equate “agile” to specific sets of practices. They are wrong. The Agile Alliance, and the thought leaders in Agile, have never, and will never (IMHO) make ANY practice mandatory. Sure, they strongly recommend some practices (some stronger than others), but it is a fundamental that the practices must suit the context. While early agilists took this as a go ahead to demand the ideal context, a later wave of agilists have taken the ideas and applied them to a much broader range of contexts. Many of your respondents don’t seem to have followed this later wave of agilists and still demand the ideal context. Sure, it’s still the ideal context. It’s no longer absolutely necessary, if you know how to make the requisite trade-offs.
Agile as they rightly say is more in the DNA rather than in the contracts or the practices defined in a manifesto. As Paul rightly pointed out that people (having the agile mindset) have been doing it for more than 2 decades now. From what I understand working for over a decade under various commercial arrangements and project methodologies, there are following important aspects in the genetic composition of a relationship (between a customer and vendor) that can make you agile:
1) Lack of divide in the Tech and Business objectives. Are developers building a business solution OR coding a software? Is their enough conceptual overlap b/w what business is trying to achieve and what the developers are building. Can your lead developer write a spot-on busienss concept document for what he’s getting his team to program?
This can be achieved by breaking through the barriers between tech. and business mindsets by pairing up our developers, team leads and project managers with business users on the customer’s end.An evolutionary business analysis throughout the project if you will, as opposed to single spec document and a single project plan.
2) Is the relationship tactical or strategic (Does failure for one means the failure for another – OR does it only mean one unhappy customer (out of too many) which the vendor doesnt care much about. As one of the respondents rightly pointed out requires an emotional maturity at both ends and a trust relationship to generate maximum results. However, if done properly it can deliver amazing results!
One interesting approach we’ve found to work which enables agility in the outsourcing contract is to bundle a bit of BPO in to the IT Services contract. Even for a pure IT outsourcing project, add a little bit of BPO. Have the IT vendor allocate a few people at their end to perform a business process (alongside with your business users) that has to be automated by the desired application they’re programming. You’ll set the business agenda for the project whereby the business users (and their outsourced representatives) will be working hand-in-hand with the developers throughout the project all of them aiming at the end business results while taking an intelligent and agile approach best suited to achieve them.
Links:
https://www.ephlux.com
If I understand correctly, Agile outsourcing here refers to software development methodology or project management practice which are normally used in software houses. Anyways I would try to link it with Agile IT management.
Based on my 8 years experience on the customer side of the court, I have worked with companies who deploy their back office applications in pursuance of their strategic business objectives. However the responsibility of managing these systems is solely on the IT department, where very few people have understanding of the business. Such a situation creates what I call as an Ag (isle) IT Management vis-à -vis Agile IT management. In performing technical endeavors, many IT professional don’t understand how they can help the business acquire customer confidence, loyalty and build a value proposition.
IT must understand that Customer oriented IT systems not only help gain operational excellence but also enable the business to focus on customer acquisition and retention by helping the management understand the market dynamics, customers needs and wants and demonstrate agility to meet those demands. However management has to manage one very important thing when using new IT systems i.e. “Change”. Is the software really helping the business gain operational efficiency or it is just a replacement of an old legacy application with a new one with more appealing graphical interface. Are the people doing the tasks in the old fashion or any thing new has been incorporated so that overall turnaround time has reduced. Is the cost of using the new software is more than the benefits, hence little or no value addition to business and its customers?
Although these may appear to be very simple things and one could argue that these issues are handled amicably by automation, one must consider that the organization culture and management philosophy is very important. Software can deliver good results, if not then bad results. It depends on the management how you want the results delivered. Therefore the environment whether its public or private culture has to be agile. Only then the business can reap the benefit of an IT system if its approach is towards agile business management.
These are my personal opinions. Outsourcing is part and parcel of life no matter which area we take (Manufacturing, Healthcare, IT …) I understand that Agile stresses on co-location but we need to dig one level deep!
Now, if you want to be Agile, you have to create sub-Agile (co-located) focus groups and manage all via UC (unified collaborations) systems.
The fundamental rule is to establish standard communication systems between inter-agile groups.