Effective use of Agile methods (Scrum, Kanban) for Global Remote Teams

Remote teams and agile methods

In this article I cover various strategies and methods for effectively implementing and using agile Scrum and Kanban for globally remote teams (virtual workforces, telecommuters). I will also attempt to debunk the myth that Scrum may not be used for remote teams. Over the years I have heard many people say that you can’t “do” Scrum with remote teams or some other such non-sense. I find this fascinating because I have done Scrum with remote teams for years — successfully. In my estimation, the cause of this misunderstanding of Scrum is generally lack of knowledge of the framework or because folks are looking for an excuse to not change processes. I will attempt to describe methods by which an organization can successfully use agile Scrum and Kanban with remote teams.

Survey says…Scrum sucks because…

Scrum is only effective with local teams and it is impossible to use Scrum for geographically remote teams
You can’t do a daily stand-up with remote teams, so Scrum will never work
The team can NEVER meet all at one time because of time zones so Scrum / Kanban will never work

I have heard these points (with some variations) from many people in software, services, and hardware sectors over the past five years or so. I am not certain of the origin or why people believe that Scrum cannot be implemented in a geographically remote team composition. In my estimation, people make these statements of non-fact because of a lack of understanding of the Scrum framework and method. Or, possibly they have other motivations like being a project management zealot and their feelings are hurt because Scrum doesn’t have a role for PM’s (so they believe). Perhaps they invested thousands of dollars in CEU’s for the PMI PMBoK or even worse… CMMI!

Defining effective use of agile Scrum (or Kanban)

Scrum is a simple framework for effective team collaboration on complex projects. — Scrum.org

Quite simply, any software development methodology is effective when it is generating value for the team, the project, and the customer (stakeholders). When a team is using a process/method and expending tons of effort doing so but have little to show for it over time in working software then the method is possibly not effective. Definitely not efficient.

While each case can be different there are some common reasons why teams are not effective. It is rare for it to be the fault of the process/method. Agile software development is a philosophy. If the team has not adopted the underlying philosophy of the framework, in the example of Scrum (or Kanban), then becoming effective as a team using Scrum will be quite impossible.

It is important to consider efficiency.

Traditional methodologies like waterfall or serialized processes are effective over long periods of time. This is a key source of improvement in lean and agile software development methods. In business time is money. Specifically with regard to development of software — time is everything. Agile methods are by design much more efficient.

For every bit of overhead placed on a product (software) development team subtracts from productive effort that could be put into producing working software. Waterfall methods have been successfully used to produce software. Compared to agile methods however, waterfall/serialized methods fall short on statistics as failure and challenged project rates are significantly higher. Clearly, waterfall methods generally have larger process overhead burdens for software development teams as compared to agile methods.

Agile methods take advantage of shorter iterations and focus on prioritization of features / stories that have the highest value to customers (e.g. product owner). The shorter iterations allow teams the ability to quickly produce underlying code frameworks, structures, infrastructure, and baselines necessary to focus on delivery of working software to the customer early in the overall life cycle of the product development.

This has benefited teams using agile methods like Scrum. Organizations like the Standish Group have tracked and studied IT and software projects and written the CHAOS report annually. They update the CHAOS database every year and reissue the report. The statistics show a remarkable edge in success rates and far less challenged projects when agile methods are used.

Agile methods like Scrum are very successful

You do not need to take my word for it. Agile methods like Scrum and Kanban are taking to the software development economy like wildfire on a dry Montana field of hay. While your mileage may vary the facts on the ground are indisputable. Agile is winning when properly implemented and coached. The Standish Group has released the Chaos Report in various flavors for over 20 years. Each year that the report has considered agile methods the data has shown higher and higher success rates.

Agile succeeds three times more often than waterfall — Mike Cohn, Mountain Goat Software

Conversely, Scott Ambler wrote an article titled, “The Non-Existent Software Crisis: Debunking the Chaos Report” in 2013 that attempts to dismantle the data provided in the Standish Group report. I am not interested in getting in the middle of that battle. However, it is interesting to point out that even using Ambler’s survey data, agile methods clearly represent a higher success rate by either parties “standard of measurement.”

An alarmist report that’s become a universal reference in discussion of development practices obscures a much less dire reality. — Scott Ambler

So the take away is that continuous improvement principles work. Lighter, more maneuverable frameworks like Scrum and Kanban are more effective andefficient than burdensome traditional methods like waterfall. No surprises really. This is also my perception of the various methods in my 20+ years of “managing” software development projects.

Remote agile teams are effective and can bemore efficient than you locals

Unless you have lived under a rock on a remote Pacific island you know that globally remote teams are more prevalent now than any time in history. I will not bother with explaining the economic / business / financial / political / social / other reasons companies are choosing to go this route as the topic is well covered by other experts. In my personal experience managing numerous remote teams over the past 20 years I have found them to be just as effective as purely localized teams when properly managed and led while using the right tools.

Additionally, remote teams can actually be more efficient than local teams. The reasons why are the subject of many social experience articles. Remote team members gain productive work time in many ways. We don’t have to shower in the morning (gross guys seriously!), we save time and money by not having to drive to an office. Speaking of offices. Have you ever tried to rent one? WOW they are expensive! We put all of our infrastructure in the cloud these days. Why not virtualize that workforce too!

Like it or not Ms. Yahoo CEO… remote teams are more efficient than a huge cubicle farm. There are realistically mostly majority benefits for remote workers vs. under the thumb folks. Technology available today, not tomorrow, enables teams to collaborate just as well as they can in a room. First, you have to get a connection to this new thing called the, “Internet.” Then, acquire a personal computer (Linux or Mac, seriously don’t waste time with other stuff) and a camera. What Ms. Mayer has done (in reference) is corrected a non-existent problem. If your organization is having problems managing remote users then it is a leadership and manager problem. Not a physical location problem. Clearly.

“but they’re more collaborative and innovative when they’re together. Some of the best ideas come from pulling two different ideas together. — M. Mayer, Yahoo CEO”

Really? Wow! When people talk to each other the best ideas come out? What does that have to do with physicality? Nothing. There are almost infinite ways to communicate remotely with live video with today’s tech. I smell leadership failure and control freak. Both of which do not foster innovation nor creation of great ideas.


This is mentioned so many times in management books and business articles as a key to success that people must forget about it. Glossed over like that annoying billboard on the way to the mall. Cliché? Yes of course. But that does not take away from the importance of focus on clear communication.

If you are implementing agile Scrum, Kanban, or especially lean agile Scrumban it is critical to establish great lines of communication in your organization. Artificial barriers across the organization chart vertically are a sign of weakness and should be eliminated.

Don’t get stuck in the trap of just “saying” words. People sometimes hear all of the words, but it doesn’t process. Make doubly sure that your communication is received, processed, and consumed.

Cultural and language barriers are a challenge for all remote global workforces. Sensitivity to these differences must be directly addressed by leadership figures on each team. Plan on how to deal with it upfront. I work with folks from around the world and even with good plans communication can occasionally break down or be misinterpreted. Comms that your American or English buddy at work may intuitively understand can be completely lost by your boss in India.

You can defeat these communication failures by using an array of techniques:

  • abundance of patience
  • use more than one communication tool — e.g. telephony plus an e-mail follow up
  • changes to the frequency of communication to break repetitive cycles that cause dreaded “ignoration”
  • be cognizant of the quality and quantity of your communication
  • use a specialized tool like Jira, Bugzilla, Spotlight PPM or other favorite task management/issues management tool

Spotlight PPM is particularly useful for agile teams as it is designed from the ground up for use with remote teams.

The Leadership Vacuum — Killing agile implementations everywhere

There is no more destructive force in the world more damaging to your agile implementation than leadership and executive teams that do not understand the ROI of agile. Worse yet are implementation managers, scrum masters, and agile coach’s that act like managers. Agile philosophy is that of a servant leader and the self-organized team. It is critical to understand that project managers do not have a role on the scrum, kanban, or scrumban teams. Separating this operationally is critical to agile success.

Managers involved in agile implementation and operations need to hang up their authoritarian ways and fit in with agile philosophy. Enablement and coaching are two key focus areas for newly minted former managers, agile coaches and scrum masters. Look for my article on Killing Project Management: Why project management must die for your organization to truly become agile in a future post.

Whomever wears the mantle of agile evangelist and/or coach, or even scrum master in your organization must work to communicate and sell the idea and philosophy that agile Scrum/Kanban/Scrumban can and will produce positive results in their teams.

Ideas on how to proceed:

  1. Try to get executives to attend tailored agile training for Scrum and/or Kanban
  2. All scrum and/or kanban team members should attend instructor led in-depth training (for scrum and/or kanban for at least 24 hours including hands-on workshops
  3. Create a sales pitch — a set of slides geared towards business managers and executives and another set for engineers / developers
  4. Get a pilot project approved. Before you start, spend at least 6 months gathering data on your current projects and their various metrics for success/failure. Continue measuring those metrics for current projects and your pilot. When completed, put together a presentation for business manager and executives that clearly shows the different results. Make sure you include a metric for process overhead in time.
  5. Create metrics that track the value generation of various activities and deliverables

Be self-organized

Agile Scrum breaks the typical mold of software team organization and defines new roles for all team members. The project manager does not exist on a Scrum team. She may exist outside of the team, but not within nor in control of. The agile Scrum team is an independent software creation unit that has specific interfaces. Scrum roles include the product owner, scrum master, and the scrum team. The scrum team organizes itself from within. Software development process controls occur within the team.

The scrum team does have reporting and other communication requirements outside of the team. We all have our masters and if you want your paycheck…adapt. Some organizations that are not fully on the agile bandwagon may enforce inheritance of certain processes and controls on the scrum team. Generally, these almost always have negative effects on the scrum team.

The key principle of a self-organized team is self-control, self-managing, internalized organization which inherently means lack of external control.

This is often difficult for new scrum teams. Developers and engineers look to hang formerly project manager tasks on a non-existent project manager role. Project managers who are now scrum masters try to control and plan too much, placing non-scrum related process burdens on the team. All the people involved need to dedicate themselves to acceptance of the underlying philosophy. As so well defined in the Agile Manifesto for Software Development. Then the scrum or kanban or scrumban team can truly become agile.

Obvious Inputs

For any process or methodology to be implemented successfully you will need the right ingredients. Just like yummy chocolate cake, too much of a good thing can ruin the final product. Take for example processes themselves as artifacts of your operations. If you are too heavy handed with process and controls your team will begin to work around the process as a part of their natural instinct to become more efficient. When this happens, the organization is broken. All inputs must be kept on balance for the recipe to success.

The same can be said of tools. If you implement that amazing $2M super tool that is so cumbersome and complicated to use…people will work around it over time. The end result is less productivity and poor quality.


Process for the sake of process, is not progress.

I will not cover details about Scrum, Kanban or Scrumban frameworks/processes in this article as that would be out of scope. The point I want to make here is to double down on my earlier notion that all inputs in your operational system for production of software must be held on balance.

Tools for effective Agile implementation with global remote teams

This subject is worth an entire article on its own but rather than try to duplicate various companies marketing machines I’ll just cover the types of tools your team will need. Just like a carpenter framing a building your team will need the right set of tools to get the job done.

The following is a list of values all tools should possess:

  • All tools must have demonstrable value to all stakeholders
  • One tool does not fit all problems or needs
  • Tools are not always the answer; tools you buy are not always the answer; choose wisely and methodically
  • Tools have absolutely no value if they are not used! surprised?
  • Use the right tool for the job. I have tried using a hammer to drive a screw. It looks like it should work, but it doesn’t.
  • Tools must provide: more efficiency, collaborative capability, communications, a system of record

Different types of tools that your agile software development team may need to be successful:

  • Requirements management — depending on the size and scope of your projects you may need to front end your agile product backlog with an RQM tool designed specifically to handle requirements (like Jama).
  • Issue management — your team will need a way to manage defects and other issues found in your software (Jira, Bugzilla).
  • Product backlog / agile process management — having a tool from which your team may manage and report on the epics, themes, and user stories including collaboration is critical. There are specialized tools like Spotlight PPM, or you can use Atlassian Jira, VersionOne, et cetera.
  • Continuous integration — YMMV depending on customer / product requirements
  • Source code database — if you are reading this… you know. If you don’t…well. Hmmm.
  • Test Framework & test case management — dependent upon the tech your team is using
  • Document management — again, dependent on the tech your team is using; keeping good documentation is also part of agile
  • IDE — integrated development environment; or not…some people like to use text editors.
  • Video conferencing — there are lots of free options, some really great reasonably priced options. I use and like: Google Hangouts, Bluejeans, Cisco Webex, Zoom.us. One nice feature of Google’s platform is the apps integration. All of these options have limitations — YMMV.


So I have provided various strategies, methods and tools for effectively implementing and using agile Scrum and Kanban for globally remote teams (virtual workforces, telecommuters). It is critically important for the organization to adopt agile principles and philosophy or risk falling back on past behavior. Managers must throw away authoritarian / project management theory (excessive process overhead) to become enablers, coaches and work to lead their teams as self-organized software production units. Establishing excellent lines of communication throughout the organization, especially vertically, is a key to success. Finally, choosing the right tools will enable your people and agile implementation to succeed.

Take away:

  • Focus on enabling leadership potential to become a real driving affect on projects
  • Engage only the processes that you need
  • Choose the right tool for the job