I am working with Tim Coonfield to develop a talk for the one day Agile Shift conference scheduled for April 12, 2019 in Houston, TX titled “10 Biggest Mistakes We Made on Our Agile Journey (and Why We are Glad We Made Them)“. This is the fourth in a series of articles that Tim and I will use to explore some of those mistakes and what we learned from them. You can find other articles in this series here.
If you are interested in hearing this talk or some of the other awesome speakers and topics that will be covered at the event, you can learn more about the conference and purchase tickets here.
Everything I will share here happened at Global Custom Commerce (GCC), a Home Depot Company, as we developed and improved our 2nd generation e-commerce platform, called Autobahn, designed to make it easy for customers to shop for and buy more complex configurable products and services like custom window blinds, custom windows, flooring and decks.
In 2011, when the Autobahn platform started development, GCC was already the #1 seller of custom window coverings online and owned several brands including blinds.com. We were a couple years away from acquisition by the Home Depot and had about 80 employees. The existing e-commerce platform had been in production for a number of years and was still actively being improved by a large team following a traditional project management philosophy using Gantt charts and reporting on percent complete.
The Autobahn project marked a number of firsts for GCC including our first use of cloud hosting at AWS and our first use of agile methodologies. This article highlights one of our bigger mistakes and how we were able to improve as a result.
In the early days of the Autobahn project when the team was still a small one with only 4 team members and a PO, our manager established a policy that each of us could and should work from home one or two days each week. Since we were practicing Scrum more or less by the book, the only exceptions were sprint planning day, the first Monday of each two-week sprint, and sprint review day, the last Friday. Most of the team took advantage. I was a notable exception mostly because I had two twin baby boys in the house, which made it difficult if not impossible to do focused coding at home.
The truth is I also hated working at home. I had plenty of experience. For years, I had run a small consulting company and spent a lot of my time working out of the house often on projects with geographically distributed teams. Along the way, I wrote a monthly column for an industry journal and a best-selling technical book on a tool nobody uses anymore (C++ Builder from the long gone, but fondly remembered IDE pioneer, Borland). Maybe it was the technology back in the late 90s, but I always found it more productive to lean over to the person next to me for a quick chat rather than getting on the phone or hopping on the latest flavor of chat.
Anyway, the rest of the team loved it. No getting up early and fighting traffic to make stand-up, no expensive lunches out and no long commutes home. It also was a great time to focus on writing code with no distractions, no background noise and no meetings.
We had all the best technology 2012 had to offer at our disposal. Our CI/CD infrastructure and our test environments were hosted at AWS. Our source code was at Github. Our office network featured a VPN that was already supporting dozens of call center associates that worked at home on a daily basis. The company paid for our cell phones and our contacts were up to date. We had Skype accounts and we were not afraid to use them. We all had fast Internet connections at home too.
Over the next few months a very clear and rather disturbing pattern developed. When everyone was in the office, things moved along very quickly. If you ran into a problem, you talked to the person next to you and solved it instantly. If you had a question for the PO, you stood up, walked 3 feet and tapped him on the shoulder. We used stickies on a whiteboard to track our work, and it was super-easy to walk up there and grab the next task. The team often went to lunch together and talked about architecture, the business and sometimes nothing at all, but always enjoyed the camaraderie.
The work at home days were very different even though they weren’t supposed to be. The day before, whoever wasn’t going to be in the office would be careful to grab a couple tasks and move them into the “work in process” column on our whiteboard. Although the remote person would call into stand-up, she would usually have a very hard time hearing the conversation and, when talking about the work she was going to do today, would struggle to point out the right cards on the board. During the day, the remote person would generally work in a pretty isolated fashion. We rarely spoke to remote workers. Often, when we tried, we ended up leaving a voice mail and got a call back within an hour or so. Pretty much the same thing would happen with Skype.After awhile, it was easier to find someone in the office or wait for the next day. It felt almost like the work at home folks fell into a short-lived black hole where the speed of collaboration fell asymptotically close to zero.
The good news was working code often came out of that black hole thanks to the lack of interruptions, but not as much as we thought. Working at home was harder than people thought. It was far easier to keep banging away at a problem than it was to get a second set of eyes on the code when it involved Skype calls, screen sharing and Internet lag. Every technical glitch and every missed call just made it more likely that everyone would wait for tomorrow to collaborate. Technical whiteboard design sessions just worked more smoothly with a real whiteboard. As a result, work at home productivity did not match what we saw from the same people in the office.
Of course, the team noticed and started talking about it more and more. Two camps formed — those for work at home days and those opposed. We all tried very hard. We experimented with new technologies. For example, we started to use video conferencing on an iPad to try and bring remote workers into the daily stand-up. We also moved to Jira to make it easier for the remote team members to share the task board. It all helped a little, but it was not able to close the gap.
Working in the office was just easier and more productive. One by one, the work at home advocates starting coming into the office more frequently. After a few months, work at home became a rare thing used mostly when a workman was expected to fix something or the kids were off school. We had all come to value face to face interaction and the speed of collaboration it allowed us.
Even today, our teams highly favor face to face interaction. Although most, if not all of them, use electronic tools to track their tasks, they still put various artifacts in physical form on whiteboards. We use Slack extensively, but we talk in person far more. Team members value collaboration so much that they willingly change desks to sit close together with other people working on a shared initiative even if it is only planned to run a month or two. We hold as many development-related meetings as possible in public spaces near the teams so people working at their desks can overhear what is being discussed and join the conversation if they think they have something to contribute. Even when doors are closed, engineers know they can simply walk over and interrupt if something important has come up. All of these things are just harder to do when you have team members working remotely.
That is not to say we never work at home or we don’t sometimes work with geographically distributed teams. Technology, people and business realities all are driving a demand for more and more remote work. We have worked very hard over the last couple of years to remove barriers to remote work. However, collaboration is still easier and more fun when you are in the same space. The benefits gained from remote work, such as better work-life balance and more control over interruptions, typically are outweighed by the tax you pay in collaboration friction. Although the technology has advanced, it simply cannot match co-location.
Tom Cabanski 
You must be logged in to post a comment.