How we develop client projects
Camplight is a multi-faceted organization in that everything we do is not constrained to a single source of income. For example, our main stream of revenue is the work we do with clients, but we also have our own products, consulting services and the potential for each Camplighter to branch the organization in another direction. We believe that’s the way for an organization to thrive for hundreds of years and be adaptable to whatever change comes ahead. However, in this post we’re going to talk about the thing we currently do best — creating value through developing software products with clients and partners.
What’s valuable?
We consider our client work valuable if it satisfies the following criteria:
- The Camplighters involved in it are happy
- The clients we partner with are happy
- The end-users of the developed product are happy
In order to fulfill the first criterion, each project request we receive is evaluated by the people at Camplight. Most projects don’t usually match our values or interests. The rest have the potential of being worked on. The one project that gets chosen receives full dedication and attention from us up to the point where the client does their job, where “the client does their job” means:
- Acquiring money to finance the project development
- Making proper marketing so the project starts building user base
- Being transparent to us as we are to them
- Testing and giving feedback on a daily-basis
From these points the remaining two criteria are easy to be fulfilled. In order to make the client happy, we try to help them with advice on what’s most important from a development, design and business point of view. We ensure that there’s almost no managerial or communication overhead. Also, we seek daily feedback by doing frequent releases or at least sharing wireframes, user journeys and screenshots of developed features.
Finally, how do we make the end-users happy? Well, if the client does their job and we do ours, the amount of bugs, downtime, useless features and technical debt is going to be quite low. If that is so, the end-users will be satisfied because the product they’re using will exceed their expectations.
How do we start a project?
After the initial evaluation of the project, we send the so-called “Initial project offer” to the client. If they agree with it, we proceed with making our first two-week contract and receiving a 50% advance payment for it. This way both the client and us can be sure that if we don’t like each other after the first two-weeks of development, we can stop working without too much spent resources. We usually proceed with several more two-week contracts until we establish a relationship and trust with the client. After that, we proceed depending on the circumstances.
How do we achieve it?
Enough abstract concepts. Let’s dig into concrete and useful stuff :)
First of all, communication and transparency are key. We aim for our tools to enhance that. That’s why we currently use Trello and Slack.
At the start of each project, we create a Trello board and a Slack channel for the project. Every feature, issue, non-functional requirement and documentation is organized in Trello via cards. Usually, we start with six columns: “Info”, “Backlog”, “Next”, “In progress”, “For review / merge“ and “Staging”. “Info” is for all of our documentation-related cards. In “Backlog“ we put everything that should be done. In “Next“ we put our current focus. When a card goes from “Next” to “In progress” that’s an indicator that it’s being worked on. In “For review / merge” we put the tasks that have to be reviewed and either merged or returned to “Next” for more work. Finally, in “Staging” we put all the released tasks for the current week.
Indicating work
We work in rounds and iterations, but the main thing is we have focus that resides in “Next” trello column. Usually we organize that focus at the beginning of each week via an informal client-development team meeting. At the start of a project these meetings are longer, but we aim to shorten them to less than 30 minutes after several weeks into the project. Sometimes we even skip the meeting if we find it unnecessary. Speaking of meetings, we don’t have daily standups. The way we use Trello shows what every team member is upto right now, what they struggle with and, with the help of Trello comments and Slack, what they want to improve. Of course, we can always add or remove tasks from “Next” if we need to respond to a change.
Each team member indicates whether they work on a task by moving their card to and from “Next”. If a card goes to “In progress” we see that someone is working on it. If it moves back to “Next”, we know that they have switched to something else. After a feature is finished it goes to “For review / merge” and if it’s approved and merged we try to release it as soon as possible.
Releases
Releases give you feedback about whether your software is working the way it’s supposed to. In a real environment clients have something more than wireframes and user journeys. They have an actual system with actual data, they can play and interact with. Thus, we try to do daily staging releases when it’s possible. With them, we give the clients a short summary of what are the newest features. In return, we expect feedback. Feedback leads to change of focus.
We do only staging releases up to the point we’ve implemented the general use case of the system. After that we try to convince our clients that it’s perfectly okay to go live.
The general use case
The general use case of a system (Basecamp are calling this core concept), is the feature without which the system will be useless. Slack’s general use case is team chat, Trello’s is real time Kanban boards, Facebook’s is having a place where people can enjoy being served personalized ads. After we define the general use case of the product we’re going to work on, our aim is to implement it and everything that it can’t live without. Everything else is irrelevant. Implementing the general use case means the product is ready for production use. Usually this takes us 2 to 4 weeks.
Chat and conferencing
As a remote organization, Slack is our main tool where people have fun and have a sense of belonging. The other thing we use it for is posting urgent issues. We try to move every other discussion to Trello where people can have context around the discussion and easily ignore stuff they don’t feel about participating in. Again, Basecamp have a really good article about the perils of group chat.
Of course, sometimes the need for a face-to-face meetup arises. When the team can’t meet in one place, we use Google Hangouts as a tool for video calls.
The team
Everything of the above is useless if the right people ain’t there. Vitaliy has written about how new people come around the Camplight fire. By following this process, we ensure that our clients work with people who are:
- Self-motivated;
- Self-managed;
- Self-organized;
- Competent in their field, and
- Always improving their skills
Usually, we’re growing our projects’ teams while the product evolves, but sometimes it happens so that a team member wants to switch projects or go on an entirely different path within or without Camplight. Each team member is responsible enough to notify both the clients and the developers about their intention and then provide a solid plan to make it easy for the rest to handle the situation. Usually this plan consists of finding a Camplighter to replace them or even onboarding a friend into the cooperative.
A real-world example
Of course, talk is cheap, so here’s an example Trello board where you can see how we structure our development flow. Come on, take a look ;)
We’d be happy to hear from you, so just send us an email to team@camplight.net
Originally published by Tsvetan from Camplight :)
