An Agile Revolution
The use of agile as a methodology has revolutionized the software development industry. It allows teams to shed detailed requirements in favor of user stories that give context to application functions and to release working software incrementally throughout the project that can be tested and evaluated. The interaction within agile teams, the ability of teams to change plans when a new idea surfaces during the development cycle and the attention to quality are all critical aspects of the success of the methodology.
At its core, the success of agile in software development is based on achieving better communication and understanding between all members of a project team. The improvements come from enabling all team members to interact face-to-face, in real time, within a framework of planned events that recur at regular intervals throughout the project. A basic mantra emphasizes the responsibility of each team member to understand the required outcomes of the functionality they are developing and how it fits into project goals or ask for clarity.
But, just as agile addresses the problems of software development with an acknowledgement that we cannot presuppose we know everything or can plan for every eventuality at the outset of a project, it also allows for adjustment and scaling of the core methodologies and processes behind successful agile implementations to meet the needs of different types of teams and their environmental constraints. So, when we consider the world of outsourced software development, with many different types of team environments, can we still use agile and the supporting systems and processes around it successfully? Can we bring the success of agile to development teams that aren’t colocated? The simple answer, in our experience, is yes. But, having said that, it does require planning and experience to achieve a successful adaptation agile to outsourcing with an understanding of desired outcomes, rather than a strict adherence to a formal set of processes and procedures.
How Does Outsourcing Impact Agile?
If you are using outsourced resources, collocated in your site and environment, the temptation would be to simply say there is no impact at all. But in reality, is that an honest assessment? Do the outsourced members of your team feel they are on an equal footing with your internal team? Do they feel they can ask probing questions about the outcomes of a user story they are working on or a technical approach they are considering? Does your internal team feel threatened by the appearance of contactors on their home turf? Do they trust them as equal members of the team or hold them at arm’s length during discussions? These problems of team dynamics can impact any project, whether the teams are collocated, distributed within a geography or more distant.
So, let’s examine some common “bumps in the road” when using agile with outsourced software development teams:
- Methodology – Beyond agile itself, there are many “flavors” of agile that teams use including scrum, kanban, pair programming, adaptive software development and many more. Beyond that, each team can customize their implementation to fit their needs. If a team has worked together for a long time using the adaptations to agile they are comfortable with, changes can create issues with productivity and team interaction. But that said, when a team is blended with internal and outsourced members, time must be spent during project setup to find an approach that everyone can accept and that will be productive for the team as a whole. Working with different methodologies can create silos that are hard for other parts of the team to monitor and make it difficult for the team to manage the project backlog and plan appropriately.
- Recognize & Remove Barriers – When you have a methodology everyone can agree is something they can work with, you will find you need to consider the barriers to productivity and communication you might have. Where should you look?
Communication – Removing barriers to real-time communication and interaction is a key part of achieving success with agile. It is easy to focus on the technical means of communication, especially in situations where teams are distributed across geographies and it is important to consider. Looking at the infrastructure, technical compatibility of communication systems, reliability and cost are all well worth the time to review and adjust. But, it is also important to consider the direct person-to-person aspect of communication, especially at the start of a project. Can the teams get together in one place for sprint zero? Can some time be set aside to just spend some time getting to know the faces, voices and personalities of team members – with team games and other activities? Building trust and understanding among team members creates an environment where communication is more natural and direct. It also exposes cultural differences among team members that, without some interaction that builds a level of comfort, could become barriers to easy communication.
- Processes – While you might agree “in theory” to use a methodology or process in development, there is no substitute for doing run-throughs early with careful monitoring to ensure things actually work as expected and everyone is on the same page. Again, if in the startup phase of a project, teams can work together in one location using the processes they have agreed on – a lot of problems that might come up down the road can be ironed out. This should include technical systems that help the teams manage user story backlog and burndown, shared repositories, continuous integration and quality assurance. When issues arise, the shared experience of working on the system early in the project can make it much easier to find solutions and move on.
- Internal Team Integration and Acceptance – The impact of outsourcing on your internal team is a very important area to consider and monitor throughout the project. Of course, if you have an internal development team that will be working with an outsourced team directly, the issues will be more direct than they would if the outsourced team is entirely responsible for development. But, in all cases, it is important to consider some key issues. When it comes to the morale of your team, an assessment of equality of status between teams should be part of the review. What are the “rules of engagement?” Does your internal team see the outsourced team as a equal in the project? a threat? a subordinate? or…? How has outsourcing impacted their workload and hours? responsibilities? Do they feel the project has high-level sponsorship? Do they understand the problem that outsourcing is solving for the business operation? All these areas of concern can create an environment that lowers trust and productivity in the project and ultimately can cause the project to “go off the rails.”
There are, of course, other areas where outsourcing all or part of your software development can impact agile practices. As a company providing software development teams for our nearshore clients, we recommend focusing on ten top considerations in every outsourcing engagement that will remove barriers and help to ensure project success:
Ten Top Considerations for Success with Agile Software Development Outsourcing
- Strong, Executive Sponsorship – There is no substitute for top-level executive sponsorship of an outsourced project. It sets the agenda as an organizational priority that has visibility and goals that are considered part of business strategy.
- Solve Real Problems – Recognizing that using outsourced resources is a conscious decision to solve a real business problem is a critical part of executive sponsorship and the elevation of the purpose, beyond the development project at hand. The business problem outsourcing is solving needs to be directly acknowledged in the statement of sponsorship whether the problem is finding qualified resources quickly for a critical business project, lowering operational costs of development or other issues that can be tied back to business success for the organization.
- Flexible Contract – Contracts that spend pages on the operational aspects of an engagement create a “straightjacket” and barriers to change that down the road can endanger the project and team interaction. Instead, focus on a shared understanding of critical business objectives for the project and the responsibilities of each team in reaching those objectives.
- Planned, Face-to-Face Meetings – At the start of a project, the entire team should meet in one site. In the best case, it should be in either the client or outsourced team offices, but it can also be in a central location everyone can reach. No matter where it is, it needs to be a location where both work and easy interaction can happen, both as team and in smaller, focus groups for specific issues. In addition to dealing with normal project startup issues, it should also include planned team games and cross-team interaction to build trust and understanding. Good quality network access, power, lighting, air conditioning control, white boards with markers, projector and screen, tables and chairs with flexible organization are all issues to consider before the team comes together. If some members cannot attend the face-to-face, planning for shared meetings over the Internet with video and sound are also issues to work out before the meetings. Some method to record meetings and meeting results is of course, very important to both assuring everyone is on the same page when the meetings are over and to include anyone who cannot attend or who might need to “come up to speed” later. For longer projects, additional face-to-face meetings can clear up issues and bring better team cohesiveness much quicker than remote meetings can. Outsourcing should not be a barrier to bringing team members together, but knowing that it requires planning and has a cost, it should be an opportunity to focus on building team understanding, trust and ironing out the issues that are creating barriers to productivity and success.
- Open Communications – Developing open, trustful communications is critical to success with agile, especially in outsourcing situations. All team members must be enabled and responsible to raise issues, clear questions and improve understanding. If they feel they must ask someone to ask someone else, setting up chains of communication to solve daily issues, the result will be a loss in fidelity and in many cases, problems that start out as small issues will mushroom before they are noticed and become critical priorities. Having planned face-to-face meetings at the start of a project and at key points in longer project can help to establish open communications, but there is no substitute for team communications plan that goes beyond the technical aspects and establishes the critical value of open communications for the team as a whole.
- Equal Partner Status – Establishing that all teams have an equal stake in a project and equal status in assuring success is another area that is often overlooked. If any part of the team feels subordinate or “out of the loop,” they will begin to hold back issues or worse, build internal resentment and isolation. Once that change becomes the accepted cultural adaption, it is very hard to reverse. The result will be that instead of sharing status and barriers, teams will withhold issues, sometimes even slowing production rather than opening up so that problems can be quickly addressed and cleared. A shared sense of being part of the team and part of reaching project objectives is critical throughout the project. In addition, when equal status is established, it is more likely that the creativity of each team and individual will recognized, valued and used effectively. Tapping into the experience, skills and creativity of every team member can be the difference in many projects.
- Team Continuity – Assuring team member continuity is critical to all elements of a development project. When a team member is added or replaced during a project, it will create a new cycle of “forming–storming–norming–performing” within the team that can lower productivity and team cohesion. If the change is planned carefully, the downsides can be overcome, but regardless it is an issue that must be considered in outsourced development, just as it is for internal development teams. Continuity can and should be addressed at the contract level, assuring that individuals in the teams are interviewed for personality and fit as well as technical skills. In real life, personal issues and conflicts will happen, but assuring that there is an understood value in low turnover needs to be part of the outsourcing relationship.
- Shared Processes & Systems – One of real technical barriers in agile development is poor integration of systems and processes between teams. When updates must be “thrown over the wall” instead using shared repositories, when continuous integration and automated testing cannot be implemented across the entire team, the opportunities for isolated issues to “rise out of nowhere” increases considerably. In addition, if regular processes and procedures are different between teams, the understanding and integration of the teams as a whole will suffer. Reaching a common set of regular processes and integration where it is not possible must be a part of initial team planning to ensure that issues do not limit the ability of teams to reach full productivity quickly.
- Shared Vision & Priorities – A shared understanding of the business need and goals behind the project, the priorities that drive not only the schedule but also the functionality of the application, is critical for the entire project team to embrace and keep ahead of them. They must be able to relate their daily work to that vision and know how it fits into the whole for them to understand clearly what must be done and when bits of functionality are slipping off the path to the goal, falling into the realm of “nice to have” and “window dressing.” With that understanding, a shared purpose begins to drive the team and priorities, without having to be constantly refreshed in their minds. It also helps the team to know when they have reached the goal and can begin to wind down, instead of finding more ways to “polish the apple.”
- Celebrate Success & Give Credit – Many people will tell you one of the best moments of their professional careers was when they were given the opportunity to take a bow as an acknowledgement of their success and hard work. It is an important aspect of any engagement and it doesn’t need to wait for the end of the project. Special achievements that get the team out of a tough situation, unusual insights that gave the team new opportunities to reach their goals, contributions to team processes that remove barriers for the entire team, all these accomplishments and more are points when acknowledgement of individuals and teams makes all the difference. Recognizing success is just as important as recognizing issues before they become monsters, and sometimes the person who correctly identifies the issue and a solution is the biggest hero you can have. Shared success doesn’t mean that cash bonuses are needed or a certificate should be prepared, but it does mean that an acknowledgement needs to come from project sponsors that is supported by the team as a whole.
Within this list should be points that everyone that has been on a software development project can relate to and understand. They are more related to how people interact and work than a strict list of operational procedures. For technical teams, issues that call on their soft skills can be difficult to place in their priorities, but none the less, they are important to get control of from the start of a project and maintain control of throughout. Teams can and do deal with these issues everyday, but in the end, they deal with them better if there is an overriding commitment to solving problems continuously, as they arise.
Scio Consulting is a provider of nearshore software development services, offering outsourced teams and resources for our clients in North America.