It all started with our motion designer.

It all started with our motion designer.

He thought that if he was going to make recommendations on how to animate on the Web, that he should learn how to do that, and try it himself. He asked our developer for help and she happily jumped right in. She built a little scaffold for him to use to get up and running quickly and taught him some basics, including how to get his stuff versioned with Git. He got excited and ran with it. He talked about it, he raved about it. It took our visual designer about 2 days of hearing him enthuse about it to get curious. On her own, she set up the scaffolding late one night. Her excitement could barely be contained in her group message. When she got in to work, she paired with our motion designer to learn Git. They both started working in code as well as in their design tools. This all happened within the first week of moving our team from an old waterfall, static comp first workflow to an agile, all encompassing one. Within a month, they had both submitted their first pull requests ever. Within two months, they had become such large advocates that they got our UX designer and primary researcher not only up to speed, but submitting her first pull request ever – she’s become one of our most prolific contributors since. Three months in, and everyone from research to design to development to product and project management are all working together, in the same system, happy and in browser. They are also genuinely curious about the whole process, from content strategy through back end development.

Three months ago, there was a lot of tension on our team. We had tried Agile (note the capital A) in the past, specifically Scrum, and we felt like it drug us down. I’m remote, and that took a toll on communication and trust because it was hard to get a hold of me to talk. It was hard to build relationships with each other because it’s hard to have watercooler-type chat when you’re 1500 miles from your team.

So, what changed?

The first change was ripping out traditional project management tools. For the speed we wanted to move, we needed something more nimble. Our goal was constant, transparent, indexed communication and feedback, and that’s hard with heavy tools that are decoupled from the place you’re working. Our code already lived on GitHub and its issue system is super robust, so we moved our process there. We created a style guide for issue tags to help organize everything. Each of our issues usually gets between three and five tags that change and move as the issue evolves.

The second change was adopting a real-time persistent text chat and communication platform. This may have been the most instrumental change in our team. Any time of day, from anywhere, we could all hang out and chat just like we were all in the same room. We pushed changes from GitHub into the chat, so we were all always up-to-date with what was happening. We were able to have structured conversations and not-so-structured conversations. Between GitHub and our chat room, we removed the need to have daily standup meetings, relegating it to a #standup hashtag in our chat. We stopped sending email, meetings basically evaporated, video chat and screen sharing was used to pair with each other when text chat wasn’t enough. The team dynamic transformed from one where we were working not to get in each other’s way to one where we were truly collaborating with each other in real-time. Our visual designer commented that this is the fastest she’s ever received feedback on her work (the moment it’s done, at its height 5+ times a day). Our UX designer joked that the team now talks more to me than they do with each other (and they’re sitting next to each other).

The third change was adopting some Continuous Integration and Delivery practices, specifically automated testing and deployment practices. When we first deployed our CI system about half way through our project, our tests were failing. By this time, our team had gotten comfortable with most of our process, but this was new. Within two days of our CI system popping in to your chat room to announce that a PR had failed its tests, our team had come to hate failing tests without needing to teach everyone what they were! When our tests finally went green, we had a mini celebration! Now we talk about our CI system like it’s part of our team, happy when it’s green, angry when it’s red, and frustrated when a build errors, but we all intrinsically understand its importance. While so far I’ve been the only one to deploy the site, doing so doesn’t require me; anyone from my team can simply merge in to master and deploy the site.

So, what have we learned from all of this? First and foremost, having designers work in code only works if they’re enthusiastic to do so. Share your enthusiasm, and they’ll see it and become enthusiastic too. Second, don’t add structure to your process for structure’s sake. Each team works differently, add only the structure they need to do their job. Use existing processes for guidance, but not everything from all process will work for every team. Third, get everyone talking about the same thing, at the same time, on the same tools, using as few tools as physically needed. Different tools for different people means knowledge is split and no one’s ever able to truly get comfortable and happy with one of them. Find tools that work for how your team works, and build your process around that, not the other way around. Finally, push your team, but in doing so, give them the support and room to grow. You’re asking them to put themselves out there, and that’s hard for anyone to do. Many tools and things in our process were introduced gradually. If the process wasn’t followed exactly, we let it slide and kept moving, knowing that we saw what happened and could learn from it. Individuals will grow at different rates, be okay with that. Delivering value is more important than following a process or using a certain set of tools or techniques. The easiest way for a team to do that will shake out as you and your team grow together. Pushing your team to grow personally will build their skills, let all individuals shine, and help you find what truly works best.

Transforming your team starts with a spark, but grows from within. Don’t force the spark to define your team, instead, let it inspire them.