While face-to-face (F2F) collaborative work is often preferred, many of us now find ourselves in a situation where that may not be an option for the foreseeable future. Recently many organizations have asked their staff to work from home whenever possible. For those of us who have been working remotely for years this is business as usual, but for many of our colleagues this is a new situation. We all need to get better at working remotely, and an important aspect of that is making teleconferencing calls effective. So I thought I would share some tips that I've found to work well.
I've organized these tips into four sections:
The best calls are the ones that start well, and an important aspect of this is people joining the call well. Here's what you can do:
It's the responsibility of everyone on a call, not just the person facilitating, to ensure that the call runs smoothly. Here are a few ways you can do that:
Think about the last time you were on a call, and you were looking at other people over the video feed. You were probably assessing how they were groomed, how they were dressed, and what the state was of their work area is.
Nobody likes wasting their time on a call where nothing is accomplished. Effective planning and good facilitation can go a long way to making a videoconferencing call successful.
One last bonus tip: You are welcome to copy the image at the top of this article and use it as a quick reminder list of the key tips in this article. Print it and tape it to the side of your monitor if you like!
Please feel free to share this article with others or print it out so that you can keep it handy. We’ve also put together a short tip sheet that you can tape to your monitor.
I would love to hear about any other tips you would have so that I can update this blog and share them with others. Thanks in advance!
Many people, particularly those new to agile, will tell you that agile teams must be small and co-located. That is certainly a smart way of organizing a team, but is isn’t required. In fact agile teams are more likely to be geographically distributed in some way than they are to be co-located. In practice, not theory.
In November of 2016 we ran the 2016 Agility at Scale survey. It was targeted at people who were currently working on agile teams, or who had recently worked on agile teams, and we asked them straightforward questions around the size of the team, how distributed it was, what complexities they faced, an so on. The following graph summarizes the responses around geographic distribution.
The survey found that less than one-third of agile teams are near-located, where all of the IT members are either co-located or at least in a shared open space. Previous studies have found that this number drops to one-in-ten teams being near located when you also include primary stakeholders.
Don’t let anyone tell you that you can’t do agile with a geographically distributed team because others are clearly doing so in practice. Yes, geographically distributed agile is different than near-located agile, which is one of the reasons why you need to take a pragmatic, context-sensitive approach to agile solution delivery. The Disciplined Agile (DA) toolkit provides the foundation from which to scale your approach to solution delivery to address a range of scaling factors, including geographic distribution. In fact, you may find our article around geographically distributed agile teams to be an interesting read.
On April 19 Disciplined Agile Consortium ran a webinar entitled Disciplined Agile Offshoring: Making it Work for Both the Customer and the Service Provider (follow the link for the recording and other stuff). During the webinar we received a lot of very good questions, most of which we were able to answer. We’ve decided to write up the answers to these questions here. We’ve organized the answers into the following topics:
Ideally, what will be the Product Owner and Team Leader’s location in outsourced agile team? Can a Delivery Manager role be infused? The Team Lead and Product Owner (or a proxy) should be on site with the development team. Many times, however, the PO is located with key stakeholders who are rarely at the same location as the development team. In this case there will be a need for a proxy, either a business analyst or better yet a (Junior) Product Owner at the site with the team who interacts with the (Chief) Product Owner regularly. You will likely need to apply the Ambassador strategy and have people fly between locations regularly.
Do most successful outsource agile projects have a product owner (junior or otherwise) and team lead role at all sites? I would suggest that. The team needs someone who can answer questions regularly. The (Chief) PO needs to interact with stakeholders regularly.
What is included in the scope of the Outsourced Work? Should it include system testing and QA testing? This depends on what the contract calls for. It is possible to outsource most of the testing effort if you choose to.
What cannot be outsourced apart from UAT/Integration Testing? Actually, you could probably outsource a lot of your integration testing effort if you choose to do so. User Acceptance Testing (UAT) needs to be done by stakeholders and those people work for the customer organization, not the service provider.
When you’re working for outsourcer, I think it is better to do manual test, to see all bugs before than spend time on automating tests. Is automated test writing always better than manual testing? I think we lose the time on automation. Automation of yours tests, or I guess more accurately your checks, is absolutely critical to your success. You can’t afford to not automate as much of your testing as possible. Yes, some testing will be manual at first, but once you understand how to run the test manually you should be able to automate it in most instances.
What the metrics to evaluate the outsourced agile delivery? This depends on what your priorities are. Are you trying to improve time to market? Quality? Return on investment (ROI)? What you measure will be driven by what you’re trying to achieve. We’re a firm believer in an agile approach to GQM.
How to measure the performance of team during outsourced agile delivery? Once again, it depends. A very good strategy is to include code analysis tools in your continuous integration (CI) strategy that provide the customer with real-time insight into the quality being delivered by the service provider.
Are Development Intelligence (DI) dashboards and code analysis tools something the consumer should expect the Service Provider to have and be using, or is this something that the Consumer needs to acquire and then share with the Service Providers? It would be incredibly foolish not to use such tools. There are many very good ones available free of charge via open source, as well as some very good commercial tools.
Apart from sending ambassadors, can you suggest any other approaches to eliminate cultural differences and we-they attitude? The only way to reduce cultural differences is to work closely together. If you’re not willing to spend at least some money on travel then I would seriously question why you’re doing offshoring at all.
What kind of indicators stand out for failing offshoring activities? The primary cause of failure of an offshoring effort is an inappropriate procurement process by the customer itself. Other failure factors include an inflexible approach to changing requirements, inadequate monitoring/governance of the project, unwillingness to pay for travel, and unrealistic expectations by the customer.
Do you recommend doing development in one place and testing in another? No. Organizing teams by function injects a lot of overhead, cost, time and risk into your software development efforts. A much better approach is to have a whole team at each location with the skills and resources required to get the job done. Some testing may still need to occur on the customer site of course, but that should be a small part of the overall testing effort.
How can we possibly be called agile when the offshore team is developing while the onshore teams sleep, and vise versa? We fix this with 20 min standups, and heavy process, and using process over comms is by definition, not agile. Should we be happy with water-agile in this case? You can strive to be as agile as possible in the situation that you find yourself in. As you learned in the webinar there are many strategies that you can apply to become more agile. You might also find our article on Agile GDD to be of interest.
How do you encourage a move away from sign-offs? There isn’t an easy answer to this one. It is quite common for us to work with organizations to help them to evolve their IT governance strategy to be more agile in nature. We often coach and mentor IT governance people to help them to move away from signing off on artifacts to a more light-weight, risk driven approach. My suggestion is to contact us for help.
Can you share any successful case study in more details? You can find some fairly easily via a quick web search.
On June 25, 2015 we gave a webinar entitled Disciplined Agile Outsourcing: Making it Work for Both the Customer and the Service Provider (click on the link to see the slides on Slideshare). We will likely run the webinar again as it was very well received. We had hoped to record it but unfortunately weren’t able to save the file because the software crashed. Hopefully it will work out next time. During the webinar we promised to write a blog summarizing it and addressing any remaining questions from the audience. This is that blog.
Agile and Outsourcing? Really?
There are good reasons why organizations are taking an agile approach to outsouring IT delivery projects. The following table overviews the motivation and concerns of both customer organizations and service providers.
Table 1. Comparing the Viewpoints of Customers and Service Providers
Here are some interesting statistics about outsourcing:
The Challenges Associated with Agile IT Outsourcing
Here are some common pitfalls that organizations run into with IT outsourcing:
Here are some common pitfalls with agile IT outsourcing:
Here are some common pitfalls with geographically distributed teams:
How Disciplined Agile Delivery Supports Outsourcing
Disciplined Agile Delivery (DAD) provides several important mechanisms which enable agile IT outsourcing:
Disciplined Strategies to Make Agile Outsourcing Work
Our experience is that the reason why many customer organizations struggle with agile outsourcing is because their intuition (which typically reflects the traditional mindset) leads them astray. The following table indicates what traditional intuition often leads you to do and the corresponding disciplined agile strategies that we recommend.
Table 2. Traditional intuition vs. what you should actually do.
When Disciplined Agile Outsourcing Makes Sense
We’ve found that for agile outsourcing to be successful you must first meet all three of the following criteria:
I recently wrote a detailed article summarizing my thoughts about Geographically Distributed Agile Teams. The article addresses a series of questions that I suspect you’ll find interesting:
I hope you enjoy the article. Feedback is always welcome.