Engineering

Five key principles that make geographically split software teams work

white laptop on wooden desk

The other day, I realized that I have worked on geographically split software teams for the last decade. I didn’t set out intending to do so. When I got my first job out of college as a software engineer, I thought being in the office was non-negotiable. If you ask company recruiters, most say in no uncertain terms they are not looking for remote employees.

But the reality on the ground is that many software companies end up letting most full-time engineers work flexible hours, from anywhere. Yet few companies acknowledge or advertise this explicitly. You can’t get this opportunity by asking for it in your interview, but after you are in the door, the opportunity arises. There are a few ways this happens.

Software companies with heavy on-call burdens, like Amazon for example, end up with an unspoken but widespread assumption that people can work from anywhere because they are working all the time. Since most engineers are contractually obligated to be on-call, and emergency issues arise at all hours of the day and night, these engineers start working remotely out of necessity. Soon, whole teams realize there is no barrier to working where and when they are most productive. On any given day during my tenure at Amazon, maybe half of my teammates weren’t in the office when I was.

 I’ve worked for several startups with surprisingly similar team environments. At one, people preferred to work at nearby coffeehouses with outdoor porches that made it easier to work while smoking. At another, unreliable wireless bandwidth in the office drove people to work from home out of necessity. At another, almost every person employed there lived in a different time zone, because this startup needed a very specific set of skills that happened to be scarce at the time.

Later I went to work for Rosetta Stone, which had three offices when I started, and grew to six offices when I left . Most of the teams I worked on ended up having people in at least three office locations, and as many time zones. Only one of the four bosses I had during those years worked in the same office as me. Not only were the teams geographically split, but once a team is split across two or more time zones, for all practical purposes, this team is also working flex time hours.

 These teams all worked well together. No matter where and when we worked, everyone still was accountable for meetings and deadlines. I never felt particularly disconnected from my team, and I had rapport with and support from my bosses.

Today I work for Pedago.com, a startup company that is geographically split and has been from the very beginning. It is the most productive team I have ever worked with.

Geographically distributed teams can work. How? In my experience, there are five key principles that make all the difference.

1. Shared chat room where all team communication, questions, updates, and banter happen

I’ve used Skype, IRC, and HipChat for this — there are many viable options. In a geographically split team, showing up to the chat room is the same as showing up to work. Conversely, not showing up to chat is like not showing up to the office, with the same professional and social side effects. Knowing everyone will be in one place means you always know where you can ask questions if you have them. And if you are ever away and need to catch up on team discussion, there’s a nice transcript of all the debates, conversations, and decisions the team made while you were away that you can easily read to catch up.

2. Shared “online” hours

These are the hours everyone is guaranteed to be available in the shared chat room. No matter how scattered the team is, there will always be some set of hours that work for everyone. Everyone is assumed to be available during these hours, and if any person can’t make it or needs to leave to run errands, they are expected to notify everyone.

3. Short daily video check-in meetings

If your team uses Scrum as its project management strategy, these are just your daily standup meetings. It makes a huge difference to see peoples’ faces once a day, if only to remember that they are human beings in addition to being demanding product owners or cantankerous engineers. The visual feedback you get from face to face conversations helps facilitate complex discussions, amplifies positive feedback, and the subconscious pressure to announce a socially acceptable level of progress helps hold everyone accountable.

4. Teammates need to be aggressive about helping and asking for help.

However tempting, no one should ever spin their wheels when stuck. Teams should declare that ad hoc pair programming, calls, and hangouts are a part of their team’s working style, and developers should be aggressive about picking up the phone or screen-sharing whenever they get stuck or need to ask a question.

5. Everyone on the team needs to buy into these rules.

No exceptions. If even one person refuses to get in the shared team chat-room or doesn’t feel like showing up to the video check-in meetings every day, these strategies won’t work for the rest of the team. Everyone on the team has to buy in, and in particular, managers and team leads need to lead by example, being disciplined about leading discussions and disseminating information only in the team’s shared forums.

But how do you know people are working if you can’t see them?

Simple answer. The same way you know they’re working when you can see them: you talk to them about requirements, check in on progress, look at what they deliver. If you are a technical manager, you monitor deployments or skim the latest check-ins. Software management really isn’t very different with distributed versus in-house teams. The secret to success is still the same: clear direction, well-defined, prioritized requirements, and carefully managed execution.

***

Check out more articles I’ve written on the Pedago Blog about edtech. For even more, you can follow me on Medium (@ann_lewis).

Standard
Learning

The Brave New (Wired) World of Online Education

iphone on table

It is a brave new world, indeed, in which milk, cars, and spouses can all be acquired via the Internet. But for all our advances, the jury is still out regarding the most effective ways to teach online.

Many online learning platforms consist of passive video lectures and podcasts, or universities repackaging classes for the web. To illustrate, imagine you have students who have never seen a pizza before and want to learn how to make one. Working with current online teaching methods, they’d likely not throw the dough, choose the toppings, or get feedback on their work. They would probably have to sit quietly through written descriptions and video lectures online.

The prevalence of this passive approach demonstrates a key challenge in the pursuit of engaging, effective web-based education: the issue of interactivity. While more studies are showing that interactivity breeds engagement and information retention, instructors and platforms are still struggling to employ effective levels and modes of interactivity.

Researchers at Columbia University’s Community College Research Center examined 23 entry-level online courses at two separate community colleges and made some interesting discoveries on this phenomenon. Their assessment was that most of the course material was “text-heavy” and that it “generally consisted of readings and lecture notes. Few courses incorporated auditory or visual stimuli and well-designed instructional software.” While technology that supported feelings of interpersonal interaction was found to be helpful, mere incorporation of technology was insufficient—and recognized as such by the students. The research noted that, “Simply incorporating technology into a course does not necessarily improve interpersonal connections or student learning outcomes.”

The research specifically called out message boards (where instructor presence and guidance was minimal) to be insufficiently interactive to engage students in a way that they found clear and useful. The consensus of their research was that “effective integration of interactive technologies is difficult to achieve, and as a result, few online courses use technology to its fullest potential.”

Another interesting look at web-based learning and interactivity is a 2013 study conducted by Dr. Kenneth J. Longmuir of UC Irvine. Motivated by the fact that most “computerized resources for medical education are passive learning activities,” Professor Longmuir created his own online modules designed for iPad (and other mobile devices). These three online modules replaced three of his classroom lectures on acid-base physiology for first-year medical students. Using a Department of Defense handbook as his guide for incorporating different levels of activity, Longmuir utilized text and images side-by-side and had an embedded question and answer format. From student comments, “The most frequent statement was that students appreciated the interactive nature of the online instruction.” In fact, 97% of surveyed students said it improved the learning experience. They reported that not only did the online material take a shorter time to master than in-person lectures, but the interactivity of the modules was the “most important aspect of the presentation.”

While Dr. Longmuir was reluctant to draw hard conclusions about this particular online course’s efficacy (due to variables in student procrastination, students skipping important material, etc.), there are a few clear points to be taken from both studies. For one, engaging, interactive content is the exception, not the rule, in today’s online learning environment. Both studies suggest the importance of interactivity in online learning—if not definitively in test results (though that’s a possibility), certainly in how students feel about their engagement with the material. This isn’t surprising since research is showing that lack of interactivity in traditional classrooms is detrimental, as well.

While the science behind producing effective online learning courses is still in development, the need for meaningful interactivity in new educational technology seems like a no-brainer. If we hope to teach our students to make that pizza, the most effective way is not to drown them in video clips and PDF files; we should create online learning experiences that mimic—or even improve upon—the interactivity and satisfaction that pounding the dough themselves would provide.

 

Standard
Company

Pedago Announces Partnership with Top Business School INSEAD

Today we’re very excited to announce a new partnership with INSEAD, one of the leading business schools globally.

INSEAD, the pioneer institution to offer MBA programs in Europe over fifty years ago, is given superior rankings by Forbes, Financial Times, and Business Insider, and is ranked number one in Europe and Asia-Pacific by the QS Global 200 Business Schools Report (registration required to view), which ranks institutions according to the preferences of over 4,000 actively hiring MBA employers across the world. INSEAD faculty created Blue Ocean Strategy, a revolutionary and highly-celebrated approach to business modeling, and the founder of INSEAD, Georges Doriot, is dubbed the “father of venture capitalism.” In short, they’re kind of a big deal, and we’re honored to be working with them!

INSEAD holds cutting-edge research and innovation in teaching as foundational pillars of their institution, and in line with these core values, they’ve offered us the opportunity to work closely with them and their incoming students to explore the ever-expanding and changing world of online education and educational technology. At Pedago, we believe that technology can accelerate learning outcomes by enabling education wherever the learner may be. We strive to create a more fulfilling and effective online experience.

We’d like to take this opportunity to welcome INSEAD students of the class of 2015 to our program. We thank in advance all participants for being a part of this milestone in our development.


Questions, comments? You should follow Pedago on Twitter.

Learn about interactive educational technology on Pedago.com.

Standard
Engineering

Build and Deploy with Grunt, Bamboo, and Elastic Beanstalk

In response to Twitter feedback on our recent post “Goodbye, Sprockets! A Grunt-based Rails Asset Pipeline,” we’d like to share an overview of our current build and deploy process.

It goes a little something like this:

Local development environment

We currently have a single git-managed project containing our Rails server at the top level and our Angular project in a subdirectory of vendor. Bower components are checked in to our repo to speed up builds and deploys. The contents of our gruntfile and the organization of our asset pipeline are described here.

We can start up our server via grunt server (which we have configured to shell out to rails server) or directly with rails server for Ruby debugging.

Even though both the client and server apps are checked into the same project and share an asset pipeline, we restrict our Angular code to only communicate to the backend Rails server over APIs. This enforces a clean separation between client and server.

Bamboo build project

When Angular and Rails code is checked in to master, our Bamboo build process runs. We always push through master to production, à la the GitHub flow process. The build process comprises two stages:

Stage 1: Create Artifacts:

  • Rails: bundle install and freeze gems.
  • Angular: npm install, grunt build. No bower install is needed because we check-in our bower_components. The grunt build step compiles, concatenates, and minifies code and assets. It also takes the unusual step of cache-busting the asset filenames and rewriting any references in view files to point to the new filenames.
  • The resulting artifact is saved in Bamboo and passed to Stage 2.

Stage 2: Run Tests:

  • Rails: run rspec model and controller tests, and then cucumber integration tests. It was a bit tricky to get headless cucumber tests running on Bamboo’s default Amazon AMI; see details in our previous blog post.
  • Angular: grunt test.

If the artifact creation succeeds, and the tests run on that artifact all pass, Bamboo triggers its associated deploy project. Otherwise, our team receives notifications in Hipchat of the failure.

Bamboo deploy project

After every successful build, Bamboo is configured to automatically deploy the latest build to our staging environment.

The Bamboo deployment project runs the following tasks to kick off an Elastic Beanstalk deployment:

  1. Write out an aws_credentials file to the build machine. We don’t store any credentials on our custom AMIs. Instead, we keep them in Bamboo as configuration variables and write them out to the build machine at deploy time.

  2. Run Amazon’s AWSDevTools-RepositorySetup.sh script to add aws.push to the set of available git tasks on the build machine.

  3. Kick off the deployment to our Elastic Beanstalk staging environment with a call to git aws.push from the build machine’s project root directory.

Since our project is configured to use Elastic Beanstalk, the remaining deployment-related configuration (like which Elastic Beanstalk project and stage to push the update to) is checked in to the .elasticbeanstalk and .ebextensions directories in our project and made available to the git aws.push command. If there is interest in sharing the contents of these config files, please let us know on Twitter.

Elastic Beanstalk staging environment

After the staging deployment has been kicked off by Bamboo, we can head over to our EB console at https://console.aws.amazon.com/elasticbeanstalk and monitor the deployment while it completes. The git aws.push command from the previous step is doing the majority of the work behind the scenes. For staging, we use Amazon’s default Rails template, and “Environment type: Single instance.” Amazon’s default Rails template manages Rails processes on each server box with a passenger + nginx proxy.

When we first decided to go to a grunt-based asset pipeline, we worried this might impact the way we deployed our servers. In fact, it does not. Our git code bundle containing our Rails app, Angular front-end, and shared assets is deployed to Elastic Beanstalk via git aws.push, exactly as it was prior to our grunt-based asset pipeline switch.

We then do smoke testing on our staging environment.

Elastic Beanstalk production environment

After we have determined the staging release is ready to go to production, we promote the current code bundle from staging to production simply by loading up the EB console for the production stage of our project, clicking “Upload and Deploy” from the Dashboard, clicking “All Versions” in the popup, then selecting the git version currently deployed to staging.

For production, we use Amazon’s default Rails template, and “Environment type: Load balanced, auto scaling.” Elastic Beanstalk takes care of rolling updates with configured delays, aka no-downtime deployments.

Wrap up

The above system, combined with the grunt-based asset pipeline described in our previous post, allows us to iterate and deploy with confidence. Future work will focus on improving deploy times, perhaps by baking AMIs or exploring splitting our monolithic deployment artifact into multiple pieces, e.g., code and assets, npm packages, etc.


Curious about Pedago online education? Enter your email address to be added to our beta list.

Questions, comments? You should follow Pedago on Twitter.

Standard