PlanningPuca: PucaTrade and the well of knowledge WRITTEN BY Daniel Miller

Welcome back to Planning Puca everyone!

As usual this week let’s start with quick recap of the progress on Future Site development. The site wide review I discussed in my last post took several days, and as a result we only had a half-week of work on bug fixes. In those three days we managed to only fall slightly behind our target weekly velocity for a full week, and have continued to maintain this faster than expected pace.

We did experience a small setback do with the recent bug with the MTGO trading system. This set our bot testing back a little, but since it’s been resolved we fully expect to be back on track within the next week or so. Not too shabby, all things considered!

From what we can tell, the work items we’ve been encountering in this bug pass have a much smaller scope than those that made up the actual feature development. This would explain why we’re burning through tasks much faster than before.

Our burndown chart showing that we didn't quite manage to meet our pace expectations for the week of 5/16-5/23 (that was a shorter development week because of several days dedicated to bug fixing), and that we were able to make up that deficit in the following cycle. The plus symbol indicates where we will be if we match our normal pace of 35 tasks per week, the smiley face shows what we believe we will be able to achieve based on our recent increase in veocity (just over 40 tasks).

Now, with the development retrospective out of the way I’d like to change gears. For this week’s column I’m not going to be focusing on Future Site. I think you guys all have a pretty clear idea about our timeline, and in my next post I’ll be back to talk about the features that we’re most excited for you guys to start playing with. I, for one, could use a break from focusing so narrowly on this one topic. Instead, this week I’m going to take a step back and look at the Planning Puca process on an Organization-wide level rather than just focusing on the tech team.

PucaTrade is a pretty small group: our office team consists of eight people, with an additional six people working remotely across the country. While you might think this should make coordination fairly easy, remember that we are working on a really complex project. From community management and economic policies, to intricate development tools and fraud prevention software, PucaTrade has an incredible number ideas to communicate and to keep track of.

When a multiple people share responsibility over a variety of different disciplines it is easy for wires to become crossed even. We use a bunch of different communication tools here at PucaHQ to try to keep everyone on the same page, but even with our current tools we still have difficulty ensuring that information is accessible to everyone who might need it.

What we really need is one centralized place where everything could be written down and referenced by anyone at any time. To solve this we recently decided that we should begin building a company wiki to store all of our site rules, information on various tools, time off policies, and every other piece of related company into. As the Operations Lead, I got to be the one to figure out how to execute this idea.

This is the type of thing that I really love: figuring out how to accomplish something I’ve never tried before. Any time I’m faced with a project like this, the first thing I like to do is to sit down for a few afternoons and spend a some time reading anything I can find written by people who have done what I’m trying to do. I try to run down every rabbit hole I can find on the subject to become as familiar as possible with all the ins and outs. I can sometimes get so engrossed in a learning process like this that it’s hard for me to move from the “learning” phase to the “doing” phase. But I can’t lie: the doing is pretty fun too…

Anywho... What I quickly learned was that the most technical job had already been taken care of for me: Mitch had helpfully already set up MediaWiki, a popular open source wiki app, and it was waiting for me to start building. Just like a tub of so many Legos.

However another fascinating thing that I learned as I read through people’s documentation of their own wiki-experiences is that, unlike with Legos, one does not simply build a wiki from the ground up. I had this idea in mind that I would sit down, start typing, and that after some number of weeks I would have written down every piece of information about PucaTrade for us to use as a reference. Shockingly to my ego, I was learning that there was a better way to approach the creation of this reference tool, and that one person writing a million pieces of information in one central location actually wouldn’t solve most of the problems I was looking to fix.

I don't always use meme generator, but when I do...

For starters, who am I to assume that I would be able to accurately record every last detail? If the goal is to get our entire team using this tool, it’s going to need to have literally 100% coverage or it may as well not exist. The first time someone tries to use the wiki and finds that the information they’re looking for isn’t there, will likely be the last time they try to use it. Why would anyone waste time looking up an answer that might not be there when it’s so much easier to ask their coworker sitting at the next desk?

And that’s assuming that people use it at all. Blindly insisting that a tool be adopted is a great way to ensure that everyone ignores it completely. People are creatures of habit and it’s going to be hard to get them to even remember that the wiki exists if they already have well established routines for referencing information.

To top it all off, why would I even be the person to write it? After all, who knows better than our Marketing Director how to measure a successful campaign? Or knows better than our Case Admin how to handle a package that hasn’t been delivered after four weeks? This is the kind of info we need to have recorded, and THOSE are the people who should be writing them.

So if I’m not supposed to write all this stuff down, how is this thing ever going to come into existence? In planning on creating it all myself I was failing to acknowledge the core tenet of wikis, and completely overlooking the benefits of utilizing the entire Puca team.

What I was learning was that the best designed wikis aren’t built: they’re grown. Getting a team of dedicated and passionate individuals to collaboratively record the knowledge base is a cornerstone of wikis everywhere. Luckily for yours truly, passionate individuals are plentiful around PucaHQ!

In the collaborative environment where everyone is enfranchised to build and contribute to the project, dealing with information missing from the wiki changes from a disappointing defeat into an exciting new challenge. If someone can’t find what they’re looking for, they can add a new section themselves! And in building it themselves, everyone here at Puca will quickly become invested in this as a resource to use rather than some inconvenience being forced upon them. Finally, by giving everyone the responsibility for creating the PucaWiki, the content will be curated and edited by the people in the company who know it the best.

One of my (many) favorite things about working here at Puca, is being able to go deep on really interesting subjects in order to help improve the way we do things. Hopefully you all found something interesting in my departure from the normal topic of Future Site development; check back in two weeks when we will be on the eve of the Future Site preview release!