26 March 2015
Why You Should Co-Locate With Your Development Team
I used to love my cube at Knovation. It was comfortable and secluded, held all of my belongings, and gave off that “don’t bother me I’m busy” vibe. For the work I was doing at the time, it made sense. I moved between managing metadata and writing lengthy software requirements, so the big three-and-a-half walled hug from my giant cube friend was comforting.
About a year ago, Knovation began working with Gaslight on icurio 2.0, a new version of our web-based learning engagement software, and I was invited to work full-time at the Gaslight office in my new role as product owner. It was unfamiliar, and I wasn’t sure what would change. Still, I accepted the opportunity, and I’m glad I did (a reaction I find holds true for most new experiences I embrace in life).
I’ve spent roughly half my time working from the Gaslight office this past year, and I’m now a strong supporter of co-locating. If you care about your customers, your process, and your end product, you’ll sit as close to your development partners as possible. Here’s why:
Talking is easy. Writing is hard.
Your development process is probably preceded by some amount of user story writing, requirements definition, and wire framing. Whether it’s done during or as part of this process, your stories are probably being groomed with developers, too.
For icurio, we only groom the story that is in the “up next” column with Gaslight (as developer Doug Alcorn likes to say, “Always minimize work in progress!”). The nice thing about working side-by-side is that we groom when we’re ready. We don’t have to schedule a meeting; it happens as needed.
During grooming, we have conversations about how a feature came about, how it will be used, and its long-term role within the system. These are important things to establish before a feature is built, but we’ve also found that it’s important to continually revisit these items during the development process. There are times when I’ll remember an anecdote that may help the team better understand the direction of a feature, or a developer might express concerns that may cause us to diverge from our earlier plans. It’s difficult and inefficient to capture the essence of these things in writing. The meaning is often lost, and when you rely on writing to provide or receive context, you’re making a decision to invest time in a less effective form of communication. Talking is way better.
Developers need open access to the why behind the what.
Short of taking a super cool minivan road trip to a customer site, software developers probably aren’t going to speak with customers and stakeholders to the same degree that you will as a product owner.
I’m always asking myself whether I’m accurately synthesizing and communicating what I know about the value that needs to be delivered to the customer. Did I mention to designer Ryan Arthur that teachers want to spend less time grading? Does developer Alan Audette know that I’ve made a few assumptions about how this widget is used? Does the team know this warning message text is non-negotiable?
I can try to relay all of this as we groom a story, but having open access to the development team means that I can share the user’s voice as the feature is being developed. Plus the developers can tap into my understanding of the why behind the what as questions arise.
You should be as vigilant about positioning your development team alongside your product folks as you are about positioning your product folks alongside customers. If you’re close with customers but not developers, you’re sabotaging the flow of information.
You’ll get more than you expected; sooner and with less effort.
Classes are a really important part of icurio 2.0. Teachers primarily use classes to connect with students, but they can also connect with other teachers, even if those teachers are at a different school. This creates some really exciting opportunities for teachers to share, collaborate, and learn from each other.
One of my favorites things about this feature is that it came from an offhanded comment that developer Kevin Rockwood made from across the table. Originally, I had defined classes as a structure that teachers used to deliver lessons to students. While building this feature, Kevin asked if it would be valuable for multiple teachers to join the same class. It didn’t take long for us all to agree that classes should support teacher collaboration, and five minutes later, it was a reality. As Kevin likes to say, it was “so easy.” (I think he just makes it look easy.)
Would this feature exist today if I hadn’t been sitting beside Kevin? Probably. But it would have arrived months later and at a greater cost, as we re-established the context around the feature that existed in that moment.
You’ll receive more feedback about what you’re doing well and … not so well.
When you sit next to people that are tasked with doing the very things you’re writing about, they will naturally share what confuses them and what is working well. Developers are my primary audience, so the user stories I tell need to be communicated in a way that makes sense and accurately translates the value a feature should deliver. Working remotely from the development team delays this feedback loop until the confusion prevents work from going forward.
If you’re committed to being agile in your software development process, you should also be agile about how you define and communicate stories.
You will grow as a product owner.
Whether it’s by trying new tools, learning about ways to improve your existing process, staying in touch with the latest goat GIF, an introduction to great coffee, or seeing that there is a better way to brew coffee, there is an opportunity for growth when your physical workspace supports open communication during the development process.
I’m cube-less these days and parked beside the nearest developer that will have me. It’s a great place to be. I encourage you to make the same change for your product, your process, and most importantly, your customers.
