Collaboration Domination (part 2)

Slow is Smooth and Smooth is Fast

This post is continued from part 1

The second collaboration-based driver of our increased output is that everyone is “on the same page.” By that, I mean that with all team-members involved in all major aspects of the process, it has been easy to quickly shift, pivot or iterate on design and functionality. In the old model, most work was done independently. Our meetings were shorter, but they were usually one-sided; as part of the team presented, and another absorbed. We’d then have to reconnect to discuss, answer questions, and re-absorb. Ultimately, the process was either drawn-out, or the outcome was misaligned with the intent (the more likely scenario). The picture below (courtesy of FailBlog) communicates this perfectly. It was like a big game of telephone – the product team specified one thing, the designers created another, and the engineers took it in their own direction.

job fails - Monday Thru Friday: Something Definitely Gets Lost in Transit
see more epicfails

Another challenge we faced, beyond details being lost in translation, was that roadblocks couldn’t be fully anticipated. Each function within the team has its own strengths and weaknesses when it comes to understanding requirements, functionality and design/build challenges. While the product manager might design what he thinks is the most elegant solution to a customer need, there might be a few ways to actually go about solving the problem, each with its own design or engineering challenges. Working in silos, the specifications passed down from product to engineering are many times the most complex possible solution – often while a nearly as elegant solution can be built in far less time, and with far less complications. Working in a truly collaborative fashion lets you anticipate these potential challenges before development starts, and really before true specification begins. As a result, our outputs have matched our specifications, and the work we’ve completed has been done in less time than similar requirements sets had been done in the past.

I think the best way to sum this all up is with the “immortal” words of Modern Family’s Phil Dunphy (one of my favorite characters in one of my favorite shows, Modern Family – although all the characters are pretty awesome in that show). In the Season 2 premier, as the family is scrambling out of their formerly parked, and now drifting car, Phil is yelling “Slow is Smooth and Smooth is Fast . . . Slow is Smooth and Smooth is Fast.” While it was a pretty hilarious scene, there was some truth in it. When we move too quickly, details are missed and coordination (be it as in individual (perhaps even in a golf swing) or as a group) falls apart. Having each member of the team involved in process components like sprint planning, task decomp, user testing, etc. has certainly slowed those processes down. However, the time benefits gained from having everyone up-to-speed and in agreement has far outpaced any of the time lost in coordination. Small changes no longer require long discussions, mid-sprint meetings have gone more quickly because each participant was a participant in a prior meeting, and roadblocks or challenges have been anticipated.

 

As a result, post-planning, we’ve been able to work very smoothly and very quickly.  As an example, see the changes from our original manager, to the latest release of that same manager (shown above – click to see it larger).  The project took some time to complete, but in actuality, was likely done quite quickly for the complexity of the project, and with (what we believe) is an excellent final product. Our service, one that delivers english-language summaries of news from foreign-language sources, on companies and industries, through the web and through e-mail, can be a difficult one to clearly describe, even for those users working with our field sales team (and therefore have someone to walk-them through set-up). In order to deliver a valuable experience to our online users, who have only a brief, automated interaction with our product, we had to work with a very complex information architecture. Working collaboratively, with a cross-functional team allowed us to develop prototypes, rapidly iterate on those, user test, iterate further, release, iterate once again and eventually release a more robust solution. Working in this way, perhaps the hardest part was cutting ourselves off to move onto another project.

Over the past 6 months, and with projects such as the manager, its become so clear to me why small, cross-functional, collaborative teams are so powerful. Working together allows us to better anticipate challenges, iterate and pivot quickly, and generate ideas from a broad base of experience. For those organizations still thinking in a waterfall model, I’d suggest considering adding a bit of reorganization (both team-structure and even seating), in order to fold more collaboration into the process, and analyzing the results. For those at the top of the waterfall, it can be challenging to feel like they are giving up some control, and for those at the bottom, it can be a new experience to provide greater input. However, I truly believe that the output will be worth the effort. I personally would have a very hard time moving back towards a stage-gate model, and have very much been converted into a believer. Going forward, I hope to continue learning and growing within this environment.

For anyone reading, I’d love to hear your thoughts in the comments section below. I’ve surely not covered all of the arguments for small, collaborative teams, and I’m sure there are some to the contrary.

26. July 2012 by Jonathan Drillings
Categories: Imported from VC2BD | 1 comment