As we head into Q2, let’s build a better “workbench” and online scrum board for Webmaker.

TLDR version:

• Check out the freshly udpated Webmaker Wiki. It’s one-stop shopping for key roadmaps, planning documents, tickets, and scrums. And will help provide more transparency and co-ordination across teams going forward.
• It clearly lays out Webmaker’s key components. And how they all fit together. From teaching kits and training to localization, badges, and Maker Party. These will provide the main tracks for our scrum board as we go forward.
• Shifting to real time production, instead of static documentation. The new wiki is a production document. The main goal is to provide a clear view of *what we’re building now.* Week by week, quarter by quarter. Instead of a static repository for documentation that quickly goes out of date.
• Project scrum boards. To that end, each individual project page will lead with a virtual scrum board at the top of the page. We’ll embed Bugzilla tickets to do this, and use Bugzilla components and whiteboard tags to do it in a smart, automated way. (If you don’t use Bugzilla, just include links to wherever you’re tracking the work.)

Why are we doing this?

• This past quarter, we’ve clarified Webmaker’s scope, component pieces, and team roles. The new wiki reflects that progress.
• Fewer “status updates,” more transparent agility. If we do this right, it’ll mean we no longer need to do “status updates” in our weekly Webmaker.org calls. The wiki pages will take care of that. Instead, we can focus more on the brainy stuff: coordinating moving pieces, clearing blockers, and refining our strategy and tactics.
• One link to rule them all. No more URL spaghetti — if it’s important to your work, it should be intuitive and findable from your wiki page. This solves for a key challenge we’ve faced to date: co-ordinating often requires a confusing jumble of  etherpads, blog posts, Google Docs, Bugzilla tickets, and stand-alone wiki pages that live in someone’s head. No more.

This is all a work in progress

• And not even close to “done.” There’s stuff missing. It needs your love, missing links and co-ownership. This post is about signalling the intention and getting your help.

The Webmaker Wiki: a scrum that never stops

Everybody loved the last Webmaker work week. Why? Because:

1. We broke the project into key tracks. Webmaker is a complex product. You need to carve it up in smart ways to tackle and make sense of it.
2. We sorted our roles and leadership for each track. Prepping for the work week forced us to get our RACI (Responsible, Accountable, Consulted, Informed) together for each track, and attack fuzziness.
3. We worked well across teams. Dividing things up into smart functional components (like “Engagement Ladder”) forced us to work across teams, instead of sticking in our little org chart boxes. This drives a holistic view of the product.
4. We scoped, documented and ticketed well. The prep work we did laid out the groundwork and scope. And because we tied all the work to Bugzilla and shareable online artefacts, it was easier to keep momentum after everyone went home.
5. The scrum board provided clear visual progress. We moved a huge number of individual tasks across the board, from “to make” to “making” and “made.”

Together, these things sent a larger signal:

All that matters is scoping clear, achievable pieces of work — and then moving them across the line together.

So let’s keep working that way

That worked well — and led to a lot of completed work in Q1. So let’s do it more intentionally as we head into Q2. And build a Webmaker scrum board that never stops!

That’s what your project wiki page should lead with going forward: a scrum board that updates as you go. Along with the handful of key links, context or artifacts your colleagues need to help you push those well-defined tasks to completion.

Laying out Webmaker’s key components

Webmaker is an open source product with a dozen or so key component pieces. The main Webmaker Wiki page is visual and navigational — it lays out these key components. This in itself is useful — think of it as an X-Ray of the projects major bones, muscles and heart. And our key scrum tracks going forward.

In addition, the updated landing page includes links to:

• The high-level roadmap. Each individual component has their own goals and deliverables — but this is the one roadmap to rule them all, tying it all together.
• Our story. What are we doing in 2014? What’s the larger goal?
• Our contributor dashboard (NEW). Our #1 goal is growing 10,000 contributors this year. This new dashboard prototype will track that in real time.

Here’s a rough template to follow for each page:

1) Your scrum board
2) Key links
3) All else

Each component has their own page. Going forward, we’ll strive for each of the pages to follow the same basic template:

1. Lead with your scrum board. This will provide the most up to date view of what’s happening, right at the top of your page.
2. Include links to key documentation. It doesn’t have to be perfect — and links are fine. You *don’t* have to duplicate or copy / paste stuff, or wrestle with wiki mark-up, or whatever — just paste in the links. If your page contains *nothing* other than one or two links to wherever you’re documenting or tracking the work, that’s just fine.
3. All else. Push the static, evergreen copy down the page, or move it to sub-pages. These are production pages — they’re meant for busy people to quickly grok what’s up now. And not public-facing pages that need to be pretty, rhetorical or overly polished.

Who’s all this for?

Who’s the main target audience for this new Webmaker wiki? Builders and production people.

Who are these wiki pages primarily for? The answer: builders. The people planning and building Webmaker on a daily basis. The kind of people who show up to the weekly Webmaker.org call. Or colleagues and hardcore contributors who’ve been at this a while, and already have a good level of familiarity with what we’re doing.

This is a bit different. In the past, we’ve used our wiki primarily for contributors, and contributor documentation. We’ve now mostly outgrown that. Our contributor documentation and platforms now live in other, more polished places —  on Webmaker.org, on SUMO,  in our updated even guides, new training pages, Git Hub, etc.  That’s a good thing. Contributors shouldn’t have to dig through a wiki to find what they need — we should be serving them in more polished ways on the web.

That frees our wiki to focus on production and co-building. That means: less context and explaining, more diving into the work.

More to come

This post will be the first in a series on “Working Open with Webmaker.” In the mean time, let’s hack and update the new wiki together.