Voyage — Build-2-Learn Roadmap
A quick guide to making the most of your remote team dev experience
The B2L Roadmap visualized
The B2L Roadmap Explained (in brief remix)
Below I’ll provide the “gist” of each step on the above image. Later in this article there will be a much more detailed breakdown of each step.
Start button
The start button above the circle is all about signing up, signing the Builder’s Pledge, organizing teams, etc. Once your project team is set-up for you in the Voyage cohort, you’ll be officially started on the B2L project cycle.
#1
Team meeting/Setting tasks. Together the team defines and assigns tasks. This is usually done in a meeting with all team-members present, via video chat or text-chatting.
#2
Doing tasks. The team is either working on their tasks, learning what is needed to complete their tasks, or reaching out to the community to get help with their tasks.
PM (Project Manager)
Doing whatever it takes to get the project shipped. #1 & #2 never goes smoothy, the Project-Manager does everything needed to push the project to completion.
Mountain-top icon— Finished aka made it atop the mountain
Popping bottles of champagne, sending 5000 celebratory emojiis, and showcasing the project to the world. The team together performs the required showcase tasks and all is great in the universe!
The B2L Roadmap Explained (Detailed remix)
A detailed, step-by-step look at the B2L project roadmap. Courtesy of @fish94 (a B2L legend). Consider this a working roadmap that we’ll be all working together to continuously improve.
#1 — Meeting is held/ Project set-up
If 1st meeting for team:
Mandatory things:
* Decide who will take care of github (most likely PM)
* Create a github repository.
* Choose a stack.
* Find out if everyone knows the stack.
* If not: give time to learn it. (more or less a week). Finish the first
meeting. Schedule another one.
* If everyone knows the stack: plan the general way of building the app.
* Is some API needed? Do we need to find it?
* Plan the general layout of the project. It is crucial to identify the
most basic and important tasks — that is a must.
* Divide the tasks among the team.
* Finish the meeting.
Optional things:
* Talk to each other! Get to know one another!
* Choose the team name.
* Choose the app name.
* Decide on “secret sauce” and plan it.
* Choose different tools to use — like trello, google docs or skype.
* Plan the general layout of the project. — You can also plan more the
the must do things in the first meeting but it is not mandatory.
* Set soft due dates.
* Schedule next meeting.
If 2nd, 3rd, 4th (etc) meeting:
When tasks are done, schedule next meeting.
* Look at the code.
* Test everything.
* Look for bugs.
* If errors found — decide on who and how will fix them.
* Plan the next step(s).
* Divide the tasks and get to work.
#2 — Team is working on tasks
PM is making sure that everybody is doing what is needed, and is not disappearing (a message in team channel a few days after meeting “how’s the work going?”, DM to the ones that do not replay in a day or two).
It is a guarantee that a member will have to learn something new to complete the task. If a member gets stuck, that member should reach out to the community (the #help-with-code channel exists for this reason).
PM — Project Manager to the rescue!
In ideal scenario, just repeat the 2 and 3 steps. But since the world is not ideal, and the project momentum will fall, the PM needs to step in when it happens. Especially when one team member will disappear. So, what’s the PM to do:
* Forget about the meetings. Scheduling them becomes pointless at
this point.
Write the message to the team, in it include:
* The current state of the app. What is done. What is working.
* The grand shape of thigs, where the app is heading.
* Clear next steps.
* Specific tasks to do now. End of message.
* Decide what tasks would suit each team member.
* Write (still in the team channel) directly to him/her. Tag him/her and politely offer him/her to do the task (not an order, a nice polite offer, with the option to pass — with a reason — and choose a different task).
* When the tasks are finished, plan the next step, and offer new tasks directly to team members. If the momentum for the project comes back, they will be more active and can choose the tasks themselves (that never happened to me, I had to continue assigning tasks until the project finished).
Mountaintop icon — Showcase & The launch!
* Create a Screencast and at least one medium article/blog detailing the experience, the project, and what was learned. The screencast/project will be showcased in the Voyage News section, Central as well as the Chingu Weekly Update & github org list! Many party parrot emojis will be dropped.
