Client's Handbook

 

Problem statement

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. We want to set expectations appropriately so time is spent building software to solve problems, not training clients on PICUS' process.

Desired outcome

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 PICUS contributors are
  • Set expectations about their responsibilities

We'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.


Welcome

 

You are working with PICUS. This is your handbook. It details how you, your team, and PICUS 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.

 

Roles

Client

You are our product visionary and domain expert. It's your responsibility to clearly set desired outcomes, declare priorities, and share quality information.

Designer

Our designers are full-stack; meaning they make product decisions, wireframe and test. Designers lead the sprint process and work ahead of developers to prototype features and prepare them to be worked on by developers.

Developer

We split the developer role into Web (HTML/CSS, Javascript, Node.js, Database, etc.) and Mobile (iOS, Android). In common, the devs are experts at system design, iterative development, testing, and project management.

 

Documentation

Sales contract

Your sales contract will be put together by you and the managing director. Work doesn't begin until it's signed and agreed upon by both sides.

Project brief

This is the master document for the team. It will have your challenge statement which defines the purpose of the work at hand.

 

Communication

Slack

During all business hours, our entire team will be in Slack. We use it for talking about the project in an open-manner that anyone invited can catch up on.

Trello

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.

Email

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.

Reserve e-mail for private conversations that are unrelated to product development.

 

Meetings

Standup

Daily at 10AM (Lisbon, Portugal), 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.

Kickoff

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

Planning

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.

Retrospective

To wrap the week, gauge progress, and iterate on working together, we run an hour long retrospective with the entire team. We will discuss mile stones, what worked well, and what could have gone better.

 

How ideas get shipped

Conversations

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.

Feature request

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/Google Drive), 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.

Design

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. We like to think of this process as creative risk management, not moving forward to code until we're confident enough in a possible solution.

Tests

We write tests 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.

Backend code

The implementation of back-end code will allow the tests to pass. When the test suite passes and adheres to our development best practices, it's ready for peer review.

Code 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.

Acceptance

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.

Live

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.

 

Week over week delivery and momentum

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 Board

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

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 emphasise priority.

In-progress

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

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.