Remote teams and Lean-Agile frameworks

In this article I cover various strategies and methods for effectively implementing and using Agile, Scrum, Lean and Kanban (the system) for globally remote teams (virtual workforces, telecommuters). I will also attempt to debunk the myth that Scrum may not be used for remote teams. We are not going to deep dive into the “Agile” mindset, values, and principles (Agile Manifesto) or Lean thinking here. Although, they are the critical foundations for using / implementing Scrum effectively.

Over the years I have heard many people say that you can’t “do” Scrum with remote teams or some other such nonsense. 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! 🙂

*(I will use the words method and framework interchangeably in this article in some cases; danger danger Will Robinson)

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/organization [more importantly the product/service], 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. (effective and efficient = e²)

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. If the team has not adopted the underlying philosophy of the framework, in the example of Scrum (or lean thinking in 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 e² and scale agile principles and practices across the entire endeavor

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/frameworks. 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. Waterfall methods have been successfully used to produce software. Compared to Agile however, waterfall/serialized methods fall short on statistics as failure and challenged project rates are significantly higher (3x more success with Agile). Clearly, waterfall methods generally have larger process overhead burdens for software development teams as compared to Agile.

Agile with Scrum takes 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 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 methods are used.

Agile frameworks like Scrum and Kanban Systems are very successful

You do not need to take my word for it. Agile frameworks like Scrum and Kanban systems/lean thinking 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 ways of working 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 takeaway 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 (e²) 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 anytime 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.

Communication

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 Agile Lifecycle Management tool. Avoid task management/issues management tools like Jira, Bugzilla

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 way of working frameworks. Worse yet are implementation managers, scrum masters, and Agile coaches 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 way of working implementation and operations need to hang up their authoritarian (command and control) ways and fit in with Agile and servant leader philosophy (decentralized decision making). 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/Lean can and will produce positive results in their teams.

Ideas on how to proceed:

1. Try to get executives to attend tailored leadership focused Agile training for the SAFe, Scrum, Lean 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 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.
6. Show the executive team the results of your Agile way of working pilot vs. current methods.

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 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

Process for the sake of process, is not progress.

I will not cover details about Scrum, Lean, Kanban or Scrumban 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 ways of working 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 mindset, Scrum framework; Lean, Kanban Systems; kanban (information radiators)
• 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.

Conclusion

I have provided various strategies, methods and tools for effectively implementing and using Agile, Scrum, Lean, and Kanban for globally remote teams (virtual workforces, telecommuters). It is critically important for the organization to institutionalize adoption of the Agile value systems 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 servant leaders, enablers, coaches and work to lead their teams as self-organized long-lived teams using a deep learning and experimental way of working. 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 effect on value delivery
• Engage only the frameworks, methods and processes that you need
• Choose the right tool(s) for the job
• Become a learning organization