If you're a software project manager or business stakeholder committed to agile software development processes (and in my opinion, you should be!), then there may come a time when you realize an upcoming project is too large for your current organization to handle without some outside help. This may feel like a very new sort of challenge. Even if your own development team has managed larger (say, more than 25 persons) projects by using agile techniques, the prospect of bringing contract help into the next job can be daunting for teams who have experienced success with agile methods.
The spirit of agile development has a lot to do with trust within the team, however large or small, and requires an understanding of agile principles that can have certain nuances from one particular team to the next. You're right to recognize these concerns. But there are ways to approach outsourcing for agile development projects, and considering these conditions and possibilities can help put your mind at ease. Naturally, it's all about promoting the best relationship between the outsourced and the outsourcer, and understanding what each party is trying to achieve with thae ability to be agile.
Understanding your vendor's motives as well as your own
If you're fairly well-versed in agile methods, then you're well-equipped to assess the organization that may be hired to help with your next project. However, for many organizations seeking help from an outsourced vendor, there is often a mismatch between their team goals and the goals of their parent organizations. For example, a lot of internal development organizations I talk to are still caught up in the notion that you "do agile" development rather than that you "are agile" or aim to "become agile." Many believe agile is a bundle of simple techniques rather than an approach to delivering more value to their end customer—their own business and stakeholders—more quickly and in a more timely manner.
So I always start off by explaining that what you really want to achieve through agile software development methods is business agility. It's critical to understand how this works for your particular business prior to considering the outsourcing piece.
In other words, we should begin the conversation about agility at the business level, then work our way down to its technical underpinnings. It must always tie back to the business agility that you're looking for. For me, this is not a conversation about whether to do extreme programming (XP) versus test-driven development; it's about the need to get the right software to market so our businesses can drive more value for their customers and then to their profit-and-loss accounts or into their organization. This holds true whether you're the outsourcer or the outsourced.
I typically do not try to convince customers to move to agile development. Most organizations have already embraced agile methods at some level; although, naturally, many struggle with implementation in their own unique contexts. This article is organized around the principles of the Agile Manisfesto in an attempt to show how agile outsourcing maps to the very concepts that define agile development in the first place. Actually, I won't step through all four of the original principles in the Manifesto, but let's examine the first two principles, just to ground this discussion.
A preference for individuals and interactions over process and tools
As far as business agility is concerned, there's really a direct link between that concept and the Agile Manifesto, whose first principle states the preference for individuals and interactions over process and tools.
There's a perception in some organizations that you don't need "tools" if you can get individuals to work together in clever ways. In fact, one of the fundamental factors for success is a solid working interaction between the business and its core IT organization. The individuals within those core interactions are particularly important in an outsourced environment because when you introduce contractors things are naturally distributed. Key business assets are not necessarily sitting right next to the business teams, but in a different part of the world. We see this with various onshore and offshore models among our customers.
Under these conditions, the level of trust you need to bring to the relationship is high. And that's one of the things that are not explicit in the Agile Manifesto. We build trust with people; we don't build trust with organizations – that comes later.
A preference for working software over comprehensive documentation
The need to quickly create and iteratively deliver working software is fundamental, but in the context of outsourcing, the whole point of this principle in the Manifesto sometimes gets lost in the contract. I've seen some horrific contract negotiations and procurements which, in an attempt to do a competent and detailed job, focus on signed-off documents throughout the lifecycle rather the delivery of working software.
I worked on a government project to deliver an online system for the police force. The outsourced partner at the time was required to deliver the system on obsolete technology, which was going to cause some performance issues. The contract actually stated that the payment criteria and the gateway reviews would be seen as acceptable if they could produce a software architecture document showing how they overcome those performance issues in the heritage system. The writing was on the wall at that point—six months later they had a 250-page document with more diagrams than you could shake a stick at and hundreds of pages of text saying how they would go about doing this. And they got paid. But 18 months after that, there still was no working software and lawyers became involved.
Had agile methods been used on that project, the team would have first produced some working software to demonstrate the architecture instead of relying simply on documentation. That's a classic example of how agile methods can keep stakeholders and development teams on the same page.
Conclusion to Part 1
Successfully outsourcing your agile development projects requires selecting the best vendor, based on an understanding of your business goals and organization's limitations. This first of a two-part article examined the first two principles of the Agile Manisfesto—making sure you have a trusted relationship with the organization that will be doing the outsourced work, and making the primary objective the delivery of working software. Part 2 will continue this discussion with five tips to help ensure your success.
Dig deeper into developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Keep up with the best and latest technical info to help you tackle your development challenges.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.