November 29, 2012
Agile and Lean transformations depend to a great extent on cultivating a good sourcing ecosystem. The decisions you make around the partners and providers supporting your transformation and projects will be at the core of a successful strategy. But sourcing strategy needs to go beyond just resource or services providers (read outsourcing) and address a larger ecosystem made of Agile SW development and delivery choices, collaboration and communication capabilities for distributed teams, and teams' physical work spaces, standard equipment, and office layout.
In September, I published a report on how to source your Agile strategy, that describes what the ecosystem looks like and how to navigate it effectively, the document is part of our larger research container on Agile – The Agile and Lean Playbook. The report gives an overview on how large vendors, SIs, and medium to small consulting organizations can (not) help you with your Agile journey but also what you need to do to be successful. Here are some of the takeaways from the research:
- What you think about Agile and Lean might not be what your SI thinks. You need to take control of your own destiny with Agile and Lean. Change your application development and delivery sourcing strategy to embed the best talents around the world to help you make it happen. But be careful with the traditional SIs, because Agile is as disruptive to them as it is you, and if they have not been seriously transforming themselves, it will be hard for them to deliver Agile services to you. Some good alternative new fully Agile players exist, including highly specialized external consulting firms. You might want to start testing the ground with these options.
- Existing contracts based on waterfall projects are a showstopper to Agile. Test your existing partners on what they are ready to do to liberate your relationship from dated terms and conditions, service-level agreements (SLAs), and pricing models. Until you change or remove these old contracts, it will be impossible to create the right relationship with your partners to deliver more value to your business. Agile requires transparency, trust, partnership (not just in words), and a lightweight contract – with Agile, you see what you get as you go, so TCs and SLAs can be simpler. If your existing provider is willing to change the contract with better terms, that's a good sign of partnership trust.
- Educate finance, sourcing, and business stakeholders to drive partner success. Agile's cultural impact and changes are significant and ongoing. You need a more open relationship with your partners regarding your strategy, objectives, and road map. Keep partners focused on delivering software often, improving team performance, and increasing quality, but at the same time, keep the relationship flexible and not too binding. Because you need to change the way you work with your partners, your internal stakeholders from finance to purchasing to legal all need to be onboard with the Agile values and principles as well as the new types of milestones you will define with Agile. You must prepare them before you outsource.
- Tools and technology don't come first but are essential to scale Agile. During initial team-level adoption, existing project management tooling will suffice. Adopting more-advanced Agile techniques requires tools that support automation and collaboration. Scaling Agile calls for tools that work with PPM and PMO governance processes and provide distributed team collaboration support. Agile is changing the perimeter and requirements of ALM offerings and requires that teams, especially when distributed, have a standardized office setup and common equipment that breaks walls and reduces distance. Distributed Agile is possible but it is hard, and is harder when time zone differences are big.
I'd like to add a few sentences on the distributed Agile issue. Agile adoption keeps growing, although only 27% of organizations have scaled Agile to the enterprise; some of these are distributed and have some form of outsourcing. However, distributed outsourced Agile is not easy. Because Agile requires a frequent feedback loop and a rigorous development process with the tight involvement of the product owner that MUST be from the business, the pain of distributed outsourcing often becomes an impediment. Agile is in fact contributing to the growing trend of localization of application development work versus off shoring (especially if very remote). There are also more reasons for this happening, but it's a new trend that with looming economies governments don't dislike.
Download the webinar I gave on Monday, December 3, where I discussed how to rightsource your Agile ecosystem, submit an inquiry, or share your experience here with the community on how you are sourcing your Agile efforts.