![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
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.
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.
Tony Grout is part of a small hand-picked team within IBM that helps IBM clients solve wickedly hard software and systems development challenges around areas such as scale, complexity, quality and innovation. Tony spends his time coaching IBM customers at the executive, middle management, and practitioner levels on moving to more agile and lean ways of working in a measurable way. He also works as a mentor for internal IBM teams on their agile and lean adoptions, including facilitating retrospectives and conducting leadership workshops.
Prior to joining IBM, Tony worked in most roles in IT, including as programmer; architect; and project, program and product manager to general manager of software organizations. He has worked across industries, delivering systems from banking, EPOS, ERP systems, jet fighters and product development to drug-regime modeling and trading systems. His focus has always been to deliver measurable value to the organization, their customers and the individuals on his team. He has led the successful implementation of object oriented and SOA-based development, using disciplined agile into his own and many other organizations. He also worked on the team that built an implementation of iterative development mapping to the PRINCE2 project management approach. Tony has delivered numerous keynotes, presentations and podcasts on outsourcing, software architecture, implementing effective software processes, agility at scale, software metrics, project management and how to rescue failing projects. Tony's keys areas of expertise include: agile development, agile outsourcing, agile metrics, disciplined agile, agile at scale and agile leadership.
