[ ] Put signed contact in Dropbox [ ] Create Freshbooks invoice for first 2 weeks [ ] Create Freshbooks recurring invoice to start after week 3 (weekly) [ ] Create Campfire room [ ] Create Github Repo [ ] Create Trello Board (for Product Design Sprints or Rails MVPs, use Trello template) [ ] Create recurring calendar invites for weekly planning, retros, and daily standups [ ] Create project in Team [ ] Share Team project page with client [ ] Schedule thirty minute meeting with client to go over systems [ ] Create calendar invite for kickoff meeting (cc office manager for client service experience) [ ] Write warm introduction to office manager
Office manager onboarding *this should be specific to each office and is up to the individual office manager
[ ] Get client shirt sizes [ ] Prep welcome box with swag and mugs [ ] Setup snacks for kickoff meetings
Clients frequently are uncertain about what inputs are required for our software projects. In our latest feedback a "checklist of things to do before kickoff" was requested to maximize effective time. Our clients are sometimes uncertain as to interaction with our process and toolset. As a contributor to our client's projects, I want to set expectations appropriately so time is spent building software to solve problems, not training clients on thoughtbot's process.
When on-boarding a new client and their team, we should provide them with the following information:
- What the software process looks like
- How they contribute and control the process
- What the roles of thoughtbot contributors are
- Set expectations about their responsibilities
I'd like to deliver this as a < 15 minute to read document in .pdf form to prototype, this should be sent out after sales agreements are signed and encouraged to be shared with the client's entire team.
You are working with thoughtbot. This is your handbook. It details how you, your team, and thoughtbot can best work together. It is a living document we are continually revising as we experiment and discover new ways of communicating to build first-class products.
You are our product visionary and domain expert. It's your responsibility to clearly set desired outcomes, declare priorities, and share quality information.
Our designers are full-stack; meaning they make product decisions, wireframe, test, and write front-end code. Designers lead the sprint process and work ahead of developers to prototype features and prepare them to be worked on by developers.
We split the developer role into two platforms; web (Ruby, Javascript, Database) and iOS (Objective C). "we also do Android and OS X, plus Maya, Haskell, Clojure, Go, and whatever else people need and we want. In common, the devs are experts at system design, iterative development, testing, and project management." - via Mike Burns
Your project advisor is there to help give unbiased feedback to yourself and the team. Their duty is to keep projects on the rails, thus they oversee technical and design strategy without being involved in the day-to-day implementation.They are impartial allies in creating the delivering your vision. Communicate with your advisor by requesting their input in group chat or have a private conversation via email.
Your sales contract will be put together by you and the managing director of the office you are working with. Work doesn't begin until it's signed and agreed upon by both sides.
See an example here.
This is the master document for the team. It will have your challenge statement which defines the purpose of the work at hand,
During all business hours, our entire team will be in Campfire. We use it for talking about the project in an open-manner that anyone invited can catch up on.
Our task manager is Trello. You are in control of priorities and ordering of tasks. Trello is massively flexible and is meant to accurately portray the process of how ideas turn into production code. If certain steps are unclear or need to be added or removed, we can do so easily.
See here for an example of our typical workflow.
We prefer to avoid using e-mail due to it's closed nature. It's much preferred to share information in formats that are available to the entire team. As such any email you send us in regards to product will be posted and shared with the rest of the team on Trello or Campfire.
Reserve e-mail for private conversations that are unrelated to product development.
Daily at 12pm, we gather up in a circle for a quick update to talk about what we've learned and what we're working on. You are encouraged to join to share your progress and wins with the entire office.
When getting started, we do a kickoff to lay everything out on the table. This is when we build the "Project Brief" together. We want to know:
- Who is on your team
- How to get a hold of them
- Background on the project
- Accounts we need access to
- Process documentation
- Schedule of team
You can see a template here.
When starting our four day work week, we want to focus on what's most important for you and your business. Early Monday morning we do quick meetings to get on the same page and re-focus the entire team.
To wrap the week, gauge progress, and iterate on working together, we run an hour long retrospective with the entire team (including your advisor). We will discuss mile stones, what worked well, and what could have gone better.
You talk to us about what you want, we will want to discuss different strategies and pros/cons for the routes we can take to hit your business goals.
When writing a feature, it's best if designers and developers know as much as possible about the why. Include any research documents, conversations, or other information about the feature and desired outcome. We can only build as good of a solution as the information we are given.
We use Trello cards to keep track of files (that can be linked from Dropbox), conversations, and checklists of todos per feature request. You can track the progress of these features as they go through the process of idea => live code in the overview of the current board.
When a designer picks a feature up, there's infinite possibility. We create mocks, prototypes, sketch, and ideate to reduce risk in the final process. I like to think of this process as creative risk management, not moving forward to code until I'm confident enough in a possible solution.
Sketches quickly become the several screens that comprise the desired interaction. Before code is written hooking up the views to a backend, we like to run through the interaction as a team and discuss the end-result. When we are happy with how the interaction looks and feels, your designer will assign tasks to a developer.
We write tests first in the development process to give us a clear answer to know that our solutions are working correctly. It allows us to manage small or large codebases with the highest amount of confidence. Writing tests is not optional.
First our tests will be failing, the implementation of back-end code will allow them to pass. When the test suite passes and adheres to our development best practices, it's ready for peer review.
To get code merged into the master branch that is ready for customer use, code must be peer reviewed. Nothing gets into the code base without another developer being aware of the changes and approving that they meet code guidelines practices.
Once a feature has passed code and design review, it's ready to be approved by you. Before accepting a feature consider the following questions:
- Is it usable by customers?
- Does it fit the initial criteria?
- Are metrics in place to measure effectiveness?
If it's not ready, comment on the Trello card why. Features late in development take the highest priority to push through to completion.
When it's ready to go, give us the go ahead to be published to production. Do this by dragging the card to the "Ready for Production" column in Trello.
After approval, the feature is pushed live and is ready for customers to use. It's our combined responsibility to maintain the feature, gauge effectiveness using business metrics, and fix any unexpected bugs.
During the development cycle, productivity will ebb and flow. It's our duty to provide you transparency into the process and work together to remove any blockers.
We have two primary Trello boards, Planning and Current.
Current is for features that have been clearly defined and are planned to be added in that current week of work. This allows the team to focus on immediate wins and tangible product improvements. These are actionable features and requests.
Next-up is our weekly goals. Think of it like a task list. Priority is ordered from highest to lowest. If you want a feature or task done faster, move it to the top and write a comment to emphasize priority.
Each team member will move a feature or tasks to be in-progress once they start working on it. It's your top-down view of what's happening. We will comment as we go along, provide screenshots, and give as much transparency as possible into the process on each Trello card.
Planning Board is for any upcoming features farther out than the current week.
Due to the nature of building software, predicting output farther than a week in advance is quite difficult. This is the place you put all requests that are not ready to be implemented in the current week.