Generally the organizations that are going to be most effective at agile outsourcing are those that have already made the cultural and organizational leap to agile and have some experience with it, institutionally. But if you don't have the skill and need to outsource those critical applications – those applications that are customer facing and really run the business – the following tips can help you be more successful.
Start by demonstrating some of the nonfunctioning requirements as early in the project as possible, and base them on the actual development environment you will use. For example, in the online police force project I described earlier, they could have produced a user story—that is, a set of requirements related to a particular benefit—to show how a police officer is able to display an assailant's details on a screen in less than two seconds. To do that they would have had to demonstrate how all the applications across the infrastructure would be connected, show how they will handle security issues, and more.
By the way, if you're unfamiliar with the agile concept of "user story," here's the idea: in its simplest form, a user story describes how a user gets some portion of value from the system in the context of how they're using it. Using the police example, say I want to retrieve the details of a particular assailant so that I can understand whether they are likely to have committed the crime I am investigating. That is itself the user story; the job of the software development team is to deliver that piece of functionality through some aspect of the software under development.
In this example, the "value" is represented in being able to access that information from the police systems onto a screen. However, certain stories will have more architectural or nonfunctioning significance than other user stories. The user stories themselves shouldn't necessarily have to focus on describing pure technical issues or nonfunctional ones. User stories can be both functional or business-focused (that is, nonfunctional, in terms of what the software actually does in interacting with a user; this is called a "use case"). What's important is that user stories parallel the technical risks along the way.
When you're outsourcing and negotiating with a partner, you must ensure that you balance the stories that will deliver the most business value early on with those that would eliminate or reduce the greatest technical risks.
The truth is, you don't know whether you're choosing the right outsource partner at the start unless you either a) worked with them before in a previous organization or b) have somebody very close that you trust who's worked with them before in another organization or worked with them in your organization.
Most outsource system integrators have delivery practices available. You need to first ask for those people who have the greatest agile experience, those who do this work all the time. You may not be guaranteed to work with the best resources, but you should always start off by asking if you can have those. If you use a disciplined agile delivery approach, there's no doubt in my mind that this will be more effective than a typical outsourced contract.
If your outsource partner is going to build software and, say, they can build something once a month for you, they should be able to produce automated build records. They should be able to send code over to you and deploy it into your environment, depending on where you're hosting or whether they're able to get access to your environment. They should be able to do this on a regular and frequent basis, so you can view the actual thing working rather than waiting until the end.
The beauty of using agile is that it gives you the ability to see that your delivery partner of choice will, according to the agreement, deliver against their first iteration deadline. If you have a critical project that needs to be done right and quickly, working in parallel with two different vendors can help you quickly assess which one delivers the best and gives you more confidence before proceeding. That gives you the ability to switch sooner if you are finding they are not delivering or to pull them up by the bootstraps more quickly and ask them to reassign the agile resource onto your project rather than the one they've given you who obviously isn't delivering. This ties the choice of vendor to one of the core principles of agile, which is to deliver working software frequently.
Make sure the contracts you have in place allow you to make choices about your outsourced vendor by iteration rather than by the full project; this gives you the flexibility to switch vendors, if needed, earlier in the process. Contracts must allow both payment and delivery exceptions criteria that link up with iterations or numbers of iterations, so that you can manage the risk involved as requirements change.
Make sure your service level agreements (SLAs) are in line with the agile approach you're taking. So, one of the things to consider up from are the terms for breaking the agreement. If you've got quality gates in place then use those to manage your relationship as you go, especially if you need the ability to back out of a signed contract.
Here's a great example of an agile outsourcing contract.
From a purely agile standpoint, we are there to deliver business value as quickly as possible to the business. But we also need to enhance our own knowledge both as an IT organization and as a business. After all, agility comes from being able to understand a situation quickly and then being able to make decisions. Good tooling gives you the ability to find information quickly and to make decisions based on that information. And I'm not talking about business intelligence at the moment, but rather being able to find architectural assets that document how things interconnect —i.e. how they can be linked together, what coding changes might be made in the application server to make those things work better or faster, or how to link to a third-party system.
Agile methods represent a fundamentally collaborative, whole-team mode of software development. That collaborative aspect is fundamentally important, and it's essentially the ability to communicate effectively. Software development, as Walker Royce puts it, is more like making a movie than it is like building a bridge. It's a collaborative, intellectual exercise that isn't always about carefully following the script. It's creative, and you need to be able to communicate with and among the people who make this happen.
Why is tooling important? So much time is wasted with poor handoffs and lack of ability to find documents and trace those documents end to end, not like the artifacts themselves end to end. Good tooling gives us the ability to start tagging assets to be able to identify who owns what and who is responsible for what, as you move through the software delivery project.
Tools in the open-source community are often used, but these are not well-geared for particular areas of specialty. For example, an open source tool may give you satisfactory code management in a small, co-located environment. However, once you start to link chunks of code into test cases, you may find that the open-source tool makes collaborating across organizational boundaries difficult. You want to connect as frictionlessly as possible, so that the teams are spending more time problem solving than trying to find where particular artifacts are, what has changed and where comments made about a particular asset are located.
Traceability from end to end is always important, and perhaps even more so when you're outsourcing. The ability to trace an idea from a business-level requirement all the way through to the code that's running and even to the data that's spinning on a disk somewhere—well, that's fundamentally important for a number of reasons. For instance, if the contract is written to a fixed price and there's tool-based change control on the project, you gain the traceability links for mapping changing requirements to corresponding code.
This is traceability at the business level and the contractual level. Once you start to scale up, having to deal with many issues such as crossing organizational boundaries with contracts and payments and schedules, traceability becomes much more important. This is especially true if the asset you're building is expected to have some degree of longevity. If there are six of you in a room and you're creating the next search engine, you're probably not concerned about reuse. You'll throw away the algorithm next year and make a better one, later. But if you're in an organization working with 300 people building the next core banking system, that's going to have a potential longevity of 60 years.
So whether it's traditional requirements to code traceability, or a higher level traceability through people and systems, an agile implementation is all about making it as frictionless as possible and dealing with it at the appropriate level, rather than just doing it for its own sake. That's true agility—being able to make decisions with speed, and traceability gives you that speed.
Essentially, in order to be successful at outsourcing an agile project, you have to trust the reporting, the management information, and the business intelligence around how things are going. We discussed the importance of traceability, which is critical to project success, but you also need visibility into what's really going on.
A scenario to consider is that of a car manufacturer. Car manufacturers have this whole concept of the end-to-end supply chain where the idea is that you can see into your partner's work to understand exactly what result you are going to get and when you're going to get it. You can see into their process to understand what's going and what's coming your way so you can start to do this just in time, which is a lean type of thinking.
Now we need to pull that into the software delivery factory, so we can get that same level of management information. This is the business intelligence that tells us where we are with the ability to reliably predict when we're going to be able to deliver our product or service to the business, whether we can deliver it early, and whether we have the quality we need. And we need that level of visibility throughout the project – from inception to delivery of the partner's project.
Ideally, you should be sharing the same tooling or they should be giving you access to their dashboards, so that you can see what's going on. Partner updates should be driven from real information about what's happening in their factory—not a spreadsheet, not a an e-mail or Word document that they hastily assembled, but rather a reliable record that enables you to drill down into the details, should you want to, to see the code that's being worked on by the individuals.
This kind of transparency and reporting is key to building trust and confidence with an outsourcing partner. The outsource partner builds that trust by delivering every four weeks and enabling you to have visibility into the details behind those reports, so you can compare actual results with the status that is being reported.
There are a few important things an organization with little to no agile experience can do to help bring greater success in the outsourcing of their business-critical application development. From defining the nonfunctioning requirements to selecting the right vendor to building flexibility into your contract and collaboration, visibility and traceability into your toolset, the key is to create an environment in which trust is earned and maintained and the iterative delivery of working software using agile principles is paramount.
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.