After an organization has successfully switched to Scrum and it needs to engage an outsourced Vendor for technical work, the Client will generally prefer that the Vendor also use Scrum. Scrum’s main benefits of transparency and repeated incremental delivery of finished work will be doubly valuable when working with an outside organization.
The following are a collection of lessons learned from managing outsourced Scrum Teams. The techniques suggested will enhance the relationship and productivity of the outsourced teams and boost the return on investment for the Client organization.
Creating a Partnership, not just a Relationship
When a Client contracts with a Vendor to provide some service there’s an inherent understanding about the relationship between the two parties. Basically, the Client is in the position of power and the Vendor is supposed to do what they are told. This may be the norm but it’s not the best model for when the Client is the Product Owner and the Vendor is supplying the Developers of a Scrum Team.
In this case, both the Client and Vendor should strive to create a partnership and an atmosphere of collaboration. This will be the best for operating under the Scrum methodology, and result in greater productivity and quicker delivery.
Building a partnership starts with how the Client communicates with the Vendor. It is important that respectful language and terminology to be used, essentially treating them as if they were new employees of the same company working down the hall. This alone will go a long way towards creating a collaborative atmosphere.
Also important is for the Client to set the Vendor up with the means for success. Providing project overviews, instructions, tools, training, and being available for questions, especially in the early stages, is absolutely vital. As the Client, it may be tempting to just “let them figure it out”, after all, the Client is paying for the service. However, investing time and effort in the beginning will result in a Vendor team that understands and produces quicker.
Building a positive working relationship takes time and both parties should do their best to cooperate and explain their positions clearly until the team members get to know each other’s styles better. If a relationship ever becomes antagonistic, it’s very hard to recover from this.
Setting up Conference Calls, Hardware, and Locations
Unless the Client’s team is planning on making numerous trips to the Vendor’s location, most meetings will occur over the telephone. Under the Scrum methodology, there’s a standard set of rituals (Sprint Planning, Daily Stand-ups, Sprint Reviews & Retrospectives) and each of these should be set up as reoccurring meetings at a time that’s convenient for both parties. When the Client and Vendor are in different timezones, be careful to pick times that won’t cause undue strain on either party because while they’ll be willing at first, they’ll become resistant later. All meeting invitations should include clear instruction on how to connect to the conference line and what to do when it doesn’t work. Setting a maximum time limit to wait and a backup number are a good way to ensure someone can get through and deal with the broken connectivity when it occurs.
Once conference call meetings are established with all the necessary information, attention must be given to the equipment and room to be used. Desktop phones often have a speakerphone function but they’re not ideal because the speaker serves double-duty as the microphone. With one of these phones the sound can be choppy because as sounds are picked up on one side, it can cut the other side off. Investing in a conferencing system is worthwhile because they are designed for synchronous conversations and often have satellite microphones for placement around a larger room.
The room design, furniture and adornments can impact the sound quality of a conference call. When we’re physically in a room we don’t notice all the noise that a hard floor, rocky table, squeaky chair, or loose whiteboard can make. We are vaguely aware of these sounds but because we’re in the room and there’s a correlation with someone or something causing it, we automatically filter it out. From the other side of a conference call however, these snaps, crackles, and pops occur randomly and may be as loud as the voices in the room. Closing your eyes and focusing on all the sounds in a room will give an indication of what might be causing disruptive noises.
Whenever possible, participants should sit equidistant from the conference system’s microphones and adjust their position depending on the power of their voice. Whatever equipment or facilities are to be used, it’s a good idea for the leaders of the team to test the experience and made any adjustments before serious meetings get started. Small distractions build into frustration and that will impact the working relationship and productivity of the teams.
Using Remote Viewing Software
Meetings regarding software development will benefit greatly from being able to share a screen, either to demonstrate work or for a quick review of code or troubleshooting issues. There are many services available and generally work across platforms so both parties don’t have to be on the same type of computer or operating system. When sharing screens, it’s important to be aware of mouse movements and screen scrolling. Most people move their mouse cursor in quick erratic movements when pointing to something on a screen and scroll very quickly. Remote viewing software doesn’t always keep up with these quick movements and the viewers on the other side will be lost or at least distracted by all the unnecessary movement. Be courteous, slow down, and provide some narrative regarding what is being shown or when a screen is about to be changed.
Trying Video Conferencing
Video conferencing has improved greatly in recent years but may still suffer from pixellation or lag when bandwidth drops. Once the sound and picture of someone talking becomes unsynchronized, it will be a distraction and confuse speakers because they’re getting mixed signals showing when someone has stopped talking and another person can start. Since people like to see who they’re dealing with, an alternative to a video conference is for both the Client and Vendor to exchange a group picture with the other so everyone can see who they’re dealing with. Great fun can be had by asking each team to guess who’s who offline and then view the answers together on another call.
Setting up and All-Inclusive Email Group
Assuming most communication will occur over email, it is useful to create an email group with all participants’ addresses included from the Client and Vendor. This way, as information or issues are discussed, everyone can be aware of what’s going on. Some of the discussion topics may not pertain to everyone and those people can selectively ignore the thread. This technique is very effective when the Client team members have other responsibilities besides working with the Vendor and everyone on the team can help pitch in where needed.
There will be times when it’s more appropriate for a conversation just between two people and in those cases writing directly to them makes sense. If information or a decision comes out of these side-discussions, it’s best to bring that back to the group in summary form versus forwarding the entire conversation which until that point, everyone else wasn’t even aware of.
Creating a Project Contact Information Document
To ensure everyone has a complete listing of all team members, it’s advisable to create a Project Contact Information document and have it shared with all parties. At a minimum it should contain a list of personnel, their contact information (email, phone) and role on the project, grouped by Client/Vendor:
If the Client and Vendor are separated geographically and by timezone, including a list of expected working hours and response times is also useful along with an escalation protocol for unanswered needs:
Periodically updating it and re-sharing through the project email address is important to make sure everyone has the latest copy.
Defining a File Exchange Protocol
Even the most trusted Vendors may not be allowed to connect directly to a Client’s network so sharing files can be challenging. Before a project starts, determine the types of files will need to be exchanged and the best way to accomplish this. Document the file exchange protocol and make sure all parties understand what it defines. This can include instructions on how to package up files, where to deposit them, and who to contact to handle the transfer.
When various file types will be exchanged and not all have the same level of security concern, create a matrix of file types and appropriate delivery channel. For example, project training materials could be sent via email where binaries or source code deliverables should be encrypted and sent more securely. The following table shows how such a matrix could be constructed:
Whatever protocol is established, it should be re-evaluated periodically to ensure it’s still a valid process and adjusted if needed.
Educating the Vendor on Client Methods
The Scrum methodology, with its focus on transparency and incremental delivery of work, is ideal for working with Vendors. However, every Vendor’s understanding of Scrum may not match the Client so it’s advisable to provide some training on the key processes the Client expects the Vendor to adhere to. This shouldn’t be a training session on the basics of Scrum but rather an orientation on how the Client expects the rituals to be performed and what artifacts (Product Backlog, Sprint Backlog) will be used.
Start with Short Sprint Cycles
Most Vendors will be keen to adapt to the Client’s ways but just to make sure the relationship starts off right and the kinks are worked out of the process, the first sprint or two could be shortened to half as long (one week vs two). These short cycles will establish how rituals are supposed to work and get all parties used to working with each other. This will incur some overhead as the time between Sprint Planning and Review are very short but will help establish a solid foundation for the subsequent sprints.
In the beginning of a Client / Vendor relationship, the Vendor will maintain tight control on their internal issues and processes and expose little of how the work actually gets done. Keeping a positive appearance is not unlike what the Client does for its customers where the best image is projected and any chaotic background activity is kept strictly hidden. Unfortunately, the tendency to gloss over issues and impediments is contrary to Scrum where even the smallest hinderance should be exposed and resolved to maintain the productivity of the team. There will always be something the Vendor would rather not talk about but an atmosphere of trust and collaboration should be encouraged by the Client. This can be done in two ways, (1) to always ask directly if there are any unanswered questions or needs and address them immediately and (2) never react in a strong, negative way to bad news for it will teach the Vendor to avoid bringing such things up. Over time, the two parties will be more comfortable exposing issues and working to resolve them. This is the essence of building a partnership and not just a Client / Vendor relationship.
Managing Questions & Answers
During execution of the project the Vendor will have questions about requirements, Client preferences, et cetera. In the beginning these questions are likely to be simple and relatively few but as the Vendor picks up speed the frequency and difficulty will increase. Some questions can be answered right away and others will take days of research.
The natural inclination of the modern office worker is to use email for tracking open questions but this quickly becomes overwhelming because of all the back-and-forth on a given topic and more importantly, the Inbox is the hub of our working lives and Vendor questions could be buried in all the traffic. Email can certainly be used to have a conversation about questions, but it is best to record and track questions in a single repository so there’s one source of information everyone shares.
Creating a repository is easily done with a spreadsheet program and a successful design depends not on including everything about the issues but just the essential set needed for sharing and tracking. The following example illustrates this point:
Each of the columns serves a specific purpose:
- ID# – Each row should have a unique identifier for referencing during conference calls and emails.
- Topic – This column is primarily to help the viewer get a sense of what the issue is about. It can be freeform text or a standard set of choices, whatever the teams prefer.
- Question – Since these questions will be reviewed and worked on outside of meetings, it is important that context be provided along with a clear request. Ideally there should only be one question per row otherwise answers could be confused and progress will seem limited as list of unanswered questions builds up.
- Answer – Answers should be concise and to the point. Any ambiguity will only prolong reaching resolution. Additionally, these question/answer pairs serve as a record of project requirements.
- Status – New questions have a status of ‘Open’ and when they are answered, ‘Closed’. This serves to identify which issue still require attention.
A Priority column can be added when there tends to be more open questions than a team can keep up with and it will be necessary to sort them according to which are the most important to address first.
The file should be shared via central location so both the Client and Vendor can view and update it but if that’s not possible, it can be passed back and forth via email but with one party responsible for its upkeep.
Conference calls provide no visual cues to those on the phone and even when a decent video conference system is in place it doesn’t provide the same experience as when everyone is in the room. The following tips will improve communication between all parties.
- When asking questions, provide context and then state the question directly, making sure it has a clear endpoint. E.g. “In the user interface mockups sent yesterday, the call-to-action buttons aren’t all the same color; which color is the correct one?”
- When answering complex questions, summarize the question, ask for validation, then provide a concise answer. E.g. “Let me make sure I understand what you’re asking. You want to know if the database schema is for the testing or development environment.” “Right, ok, it is for the testing environment.”
- When directing a question or answer specifically to one individual, address them by name. E.g. “Thomas, the code I updated will affect what you checked in last night.” “Richard, did you receive the file I FTP’d yesterday?”
- When you need to discuss something with the local team, let everyone on the conference call know you you need to have a side conversation so they’re not wondering if they should be engaged in the discussion. E.g. “Hey guys, hold on a minute, I need to clarify something with Harriet here.”
- When you need a moment to think about an answer or topic, inform the call participants that you need a moment to gather your thoughts. E.g. “Hold on a moment everyone while I think this through.” “Ok, here’s what we’ll do…”
These suggestion will add overhead to the conversation but will give both parties the necessary signals for smoother collaboration and will pay off as the project executes.
Project Manager Coordination
Getting two groups of people to work together isn’t trivial and especially so when they are separated by distance, timezone, or culture. Some form of friction should be expected with communication and established procedures. These issues will generally work themselves out in time but to quicken a positive outcome the two Project Managers, or equivalent roles, should meet periodically and have an open and honest conversation about how they feel the relationship is going and how the teams are interacting.
These conversations should be constructive with clear goals defined for addressing perceived issues and then evaluated during subsequent meetings in order to monitor progress. The two people should not think of themselves as being on either the Client or Vendor team but on a third team interested only in the success that a productive relationship can bring.
Not every issue can be solved quickly but if both parties make the necessary adjustments for each team everyone benefits.
© 2012 William Patrick Swisher