Merge Like A Zipper
Integrating Development with Design and Project Management
There is an unsaid pattern drivers follow when merging many lanes into one. “Merge like a zipper”, some signs will read. Those signs invalidate my first sentence by no longer leaving the rule unsaid.
It’s a sign of respect, a pact you invisibly sign when you’re handed that driver’s license. You will be courteous of other’s time and space, keeping the system swift and smooth (like a zipper). You will follow all of the said and unsaid rules in order to avoid causing an avoidable crash.
I’ve learned a lot of unsaid things in my first formal year of being a professional. That you should probably not hog the sofa more than once, maybe twice, a week. That you should convince your neighbour to water the little cactus sitting between both your desks, and then proceed to take all of the credit for it… But, in keeping with the analogy, I’ve learned that working efficiently as a member of a team has a lot to do with lanes. Sometimes you have to turn your part in a large project into a mini self-project that merges back into the main road. Along the way, you’ll want to avoid colliding with fellow drivers, or worse, causing a crash with cascading effects — where everyone loses time, and nobody leaves happy.
To run smoothly, software projects require a set of mutually agreed upon patterns, much like driving. As developers, we set coding standards to ease maintainability and extensibility. As team members from various disciplines, the Kanban board approach works swimmingly (see what I did there?) when working towards the completion of a project.
It provides a visual representation of the amount of issues in their respective states, giving all members of the team full disclosure to the project status. With work broken into sprints, it’s easy to see if the project is on track for a timely completion. Any member of the team can flag an issue, add detail to a problem, or provide solutions. Having daily stand-ups supplements this feedback with a more face-to-face communication. Regardless of the methodology you choose, the earlier you sit down and communicate with the people you are working with, particularly when there is cause for concern, the smoother the project will run.
I have learned that it makes a significant difference to my workflow if I have visibility into a project pretty soon off the bat. I strongly believe in engaging the development team early on in a project, while key decisions are being made and the breadth of the requirements is being laid out. This gives the developer an idea of what to expect, and how to best spend their time in order to achieve that home run we’re all rooting for. It provides a global context to each individual task laid out by the project management team. Essentially, you are trying to avoid what I have just now named the ‘Murky-Puzzle-Phenomenon’. You may have every single piece of a puzzle laid out in front of you, separated by edge pieces and various sections of a scenery — yet, it is exponentially harder to complete a jigsaw puzzle without a picture of the desired end goal before you.
You may have every single piece of a puzzle laid out in front of you, separated by edge pieces and various sections of a scenery — yet, it is exponentially harder to complete a jigsaw puzzle without a picture of the desired end goal before you.
As a web developer, and generally the final runner of the website redesign relay, you place a lot of trust in the members of your team. You trust the design team’s vision for the end product; that it has addressed the key desires of the client, and that it was designed understanding the effort required for development. You trust the project manager with your sanity; that the time and expectations for building components is within reason, and that all requirements are clarified. Yet, you cannot leave the onus on a single individual to ensure that the project is being managed efficiently. Every day you come into work, you need to know what needs to be achieved, what items are higher in priority, which questions you need to ask, what design problems you’re trying to solve, and who you need to talk to to get it done. Ultimately, you learn that to work efficiently, you trust yourself to be a little bit of everybody.
It takes a collaborative team with good habits to work as a well-oiled machine. Whether you’re driving, playing baseball, putting together a jigsaw puzzle, running a relay, or delivering a product to your end user, effective communication is always the key to achieving that precious W.
Pardon the excessive use of analogies.
