Remote teams and agile frameworks
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. Please keep in mind that agile Scrum is a framework, not a process or method. Kanban in its pure form can be considered a method.
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 agile Scrum framework. 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 framework/process/method and expending tons of effort doing so but have little to show for it over time in working software then the way of working is possibly not effective. Definitely not efficient. (efficiency and effectiveness = e2)
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/framework. Agile software development is a philosophy first. A cultural revolution in thought, decisions, and action for people using an agile framework/method/process. 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. But we want to evolve past e2 and scale agile principles and practices across the entire endeavor
Traditional methodologies like waterfall SDLC’s or serialized processes are somewhat effective over long periods of time or on projects with easily identifiable reductionist management application (see Taylor’s Scientific Management Theory). This is a key source of improvement in lean and agile software development frameworks/methods/processes and philosophy. In business time is money. Specifically with regard to development of software – time is everything. Agile frameworks and philosophy are by design much more efficient (see, lighter).
For every bit of overhead placed on a product (software) development team subtracts from productive effort that could be put into producing working software. Forcing a rigid process timelines/phases destroys feedback loops and incremental improvement.
Waterfall methods have been successfully used to produce software. Compared to agile methods however, waterfall/serialized methods fall short on statistics and reality 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 frameworks/methods.
Agile frameworks/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, API’s, services, 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 frameworks 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 frameworks/methods are used.
Agile frameworks like Scrum and Kanban are very successful
You do not need to take my word for it. Agile frameworks like Scrum and methods like 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 frameworks/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 frameworks/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 (relentless improvement is the next evolution). Lighter, more maneuverable frameworks like Scrum and Kanban are more effective and efficient (e2) than burdensome traditional methods like waterfall. No surprises really. This is also my perception of the various other methods and prescriptive processes in my 20+ years of “managing” software development projects.
Remote agile teams are effective and can be more 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 and process. Process being the net of your framework implementation.
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!
The Yahoo Rant.
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 software development implementations everywhere
There is no more destructive force in the world more damaging to your agile software development implementation than leadership and executive teams that do not understand the ROI of agile SDLC frameworks. 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 organizational transformation success.
Managers involved in agile SDLC 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.
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:
- Try to get executives to attend tailored leadership focused agile training for the SAFe, Scrum and/or Kanban.
- 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.
- Create a sales pitch – a set of slides geared towards business managers and executives and another set for engineers / developers.
- 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.
- Create metrics that track the value generation of various activities and deliverables.
- Show the executive team the results of your agile SDLC framework/lean pilot vs. current methods.
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.
For any framework, 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.
The team must change their thought from traditional fixed scope thinking to fixed people and time (iterations) focused on driving up and building value.
Process for the sake of process, is not progress.
I will not cover details about Scrum, Kanban or Scrumban frameworks 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. Your organization must enable relentless improvement by implementing a framework that enhances and supports the tenets of the Agile Manifesto. Methods and processes are built or changed to fit within the construct of the framework. The framework is NOT the process.
Tools for effective Agile SDLC 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:
- Scaling agile – the Scaled Agile Framework for the Enterprise (SAFe)
- Way of working – the agile Scrum framework; lean Kanban; Kanban’s
- 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 framework and lean Kanban method 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 – Taylor’s Scientific Management cards) to become enablers, coaches and work to lead their teams as self-organized long-lived 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.
- Focus on enabling leadership potential to become a real driving affect on projects
- Engage only the frameworks and processes that you need
- Choose the right tool for the job