Process is absolutely essential. It’s not a particularly exciting topic, but it’s necessary to understand for a number of reasons. In the interest of understanding as well as allowing us to be transparent, let’s talk about those reasons, process in general, and the process at Rekka Labs.

Very simply put, process is a set of rules governing interactions, both internally between team members and externally with users and stake-holders. Even in the absence of an explicitly designed process, an informal process will eventually develop. An informal process sometimes hits an optimum for a team, but more often than not, it ends up chaotic. Explicit design of a process staves off the chaos, makes the process easier to understand, and allows the process to be examined and improved.

The importance of examining and improving a process should be obvious, but why worry so much about managing chaos? If there’s a clear process, there’s a protocol for what to do and how to communicate. This means that wasted time and miscommunications become rare, and the process of figuring out what to do and how to communicate becomes automatic, saving valuable cognitive resources. Software, as with any other creative engineering endeavor, has plenty of chaos built in: an algorithm may turn out to be infeasible, a third-party API can change, feedback from users can drastically alter a product, or any of a host of other reasons. Managing chaos saves time, effort, and money. Since Rekka Labs is an R&D company, we also handle research projects like proofs of concept or data analysis. Research projects by definition involve uncertainty, meaning process becomes even more critical.

Process at Rekka Labs

I’ll explain the principles at work in our process, and then go into the details.

We’re very big fans of the Agile Manifesto. With good reason, most effective teams are: it’s an articulation of unspoken rules that have always governed good teams. (Its popularity has unfortunately turned it into a buzzword, getting “Agile” plastered on processes that are just repackagings of broken methodologies; that’s a topic for another time.)

At the very center of our process is communication and feedback. This is the only way to really understand what to build. We also lower the overhead of whatever tasks we can. Not only because a cumbersome process is a process that people ignore, but also so we can focus on the main task of building and shipping. This means automating and refining every step we can.

The Start of the Process: Understanding and Planning

When we get an email or an inquiry, we have an informal chat, in person whenever possible, at our office or a coffee shop, to talk about ideas and see if there’s a fit.

If there is mutual interest and our schedules align, we schedule the kick-off meeting. Although no code is written, this is where the real work starts. At the beginning, we offer an NDA if required. The agenda for this is to introduce the team, discuss the project goals and the business, learn about the users, build up domain knowledge, and produce a specification and estimates of time and cost for the project. We also brief you on our process, but since you are reading this, that briefing will take very little time.

Depending on the project, this meeting can take half a day, but usually takes close to a full day. This can sometimes be a tedious process, and you’ll be answering a lot of questions that may seem mundane to you, but a solid foundational understanding of the entire project means that we eliminate any mismatched assumptions and we fill in a lot of blanks that might have remained unknown. The plan can (and almost probably will) change over the life of all projects except the shortest, but there is no subsitute for understanding.

After we understand your needs and their context, we can start work the second that there’s ink on the contract.

Breaking Ground: Tools and Infrastructure

We’ll introduce you to the tools we use and get you set up, and we’ll explain the basic infrastructure to you. This takes very little time, and usually happens the morning of the first day of the project. The tools can change from time to time, but we don’t change them during the project if we can at all avoid it. For most projects, not all of these tools are necessary. (Of course, some of our clients are larger organizations that have their own tooling, which we’re happy to accommodate.)

• Source code management. Developers need to share code, examine the code’s history, and coordinate releases. We use git, a tool that became industry-standard almost overnight. Depending on the project, we may use our internally hosted git server, Github, or BitBucket.
• Project management. This enables you and our project manager to see at a glance what is done, what is in progress, and what’s expected this week, without waiting for an email response. It also let the team coordinate on tasks. You can think of it as a linear priority list and project schedule. For this task, we usually use Pivotal Tracker or something similar.
• Design and assets. Project management tools are about adding structure to the process, but for design, there’s a need for a more open-ended tool to share and discuss, and it’s also handy to have a central hub for high-resolution assets. Trello is usually the best fit for this.
• Issue Tracking. When there’s a bug, an improvement, or behavioral change to discuss, an issue tracker is the tool for the job. The ideal flow is that everyone weighs in on the issue, and when the correct course of action and the issue’s relative priority are identified, the lead developer or project manager creates a task in the project management tool. This is the tool that tends to vary most widely between projects, but for the most part, we use Github’s issue tracker or a Trello board.
• Knowledge Base. This becomes important for projects with a large scope or a large number of people involved. It acts as the central repository for documentation about the project. The ideal tool for this is either BaseCamp or a simple team wiki.
• Chat. Of course email is difficult to replace, but there is a need for a small tool to enable transient communications and quick discussions among team members. We have a preference for Flowdock or private IRC servers for this job. We use Slack as well.

There are also a few infrastructure pieces that are common to start with:

• Staging/QA server. This server holds the latest stable release or release candidate, and its role is for testing releases before they get to production. It replicates a production environment as closely as possible. Any errors or problems visible here should be treated as bugs, and added to the issue tracker. This is the server that QA testers should be watching closely.
• Development server. This server holds the latest development code. Think of it like a construction site. It’s useful for checking on new things as they’re built, verifying bug fixes, or talking about prototypes of new features. Errors here are not serious, as the development server’s code is always in flux and some features are likely to be only partially complete.

Roles

To keep communication seamless, everyone has to know what everyone else’s role is. A person will often have more than one role (for small teams, nearly everyone has more than one role). Multiple people will often share some roles, but other roles are not usually shared: for example, there is often more than one developer on a single project, but there is only one project manager. Roles may change, and some roles are not necessary for some projects. For example, an API does not need a visual designer as there is no visual component, but for every software project, there is at least one developer. The function of the role and who is filling it have to be clear for the team to operate, though!

• Product Owner. This role controls the project’s direction and requirements, andwatches the project’s progress. This is the person that makes the decisions, and the person to talk to if you have a suggestion. If you have hired us, this is you.
• Project Manager. This role handles communication and logistics. It’s the project manager’s job to keep track of the project as a whole, coordinate efforts, handle communication, anticipate roadblocks, and generally get things done. The project manager is the person with the answers, and is the first point of contact between the product owner and the rest of the team. Since the only way to tell if a project is being managed effectively is to notice the absence of problems, it’s an often underappreciated role.
• UI/UX Designer. This role designs the paths that users take through the application, optimizing paths that the user will likely take or that the product owner wants the user to take. This is the person that creates the wireframes and flowcharts.
• Visual Designer. The visual designer does the graphical work, planning the visuals across a product. Logo design fits in this role, too. This is the person with the Cintiq and a scary number of Photoshop macros.
• Developer. This is the role responsible for creating the code, designing the algorithms, fixing the bugs, and drinking the most coffee.
• Architect. The architect designs the internal structure of a system. A good architecture makes bugs rare, it keeps systems speedy and secure, and it makes code easy to write and understand. This is the role responsible for looking at the specification and the requirements and seeing a system, then describing the system’s components and dividing responsibilities between them.
• System Operations. This role carries out the care and feeding of servers. System administration may be manual, but nowadays is generally not (and we obviously believe in automating whatever can be automated). Ops carried out by automation is usually referred to as devops. Our tool of choice for server instrumentation is Ansible.
• QA Tester. This is the role that is responsible for discovering and describing bugs to the developers, adding them to the issue tracker, elaborating if the developer doesn’t understand, verifying fixes, and sometimes writing test code. QA is often carried out manually at least to some extent, but good developers and QA testers will use automated test suites as the first line of defense against bugs.

Low-Level Project Flow: Iterations

The project is organized around fixed-length iterations. At the start of each iteration, there is a brief planning meeting carried out by the project manager.

Throughout the iteration, there are very brief meetings (sometimes carried out over chat, especially with a remote team) with the goal of coordinating the day-to-day operations among the team members. These are called “standups” because the team is supposed to stand up for the duration, to make sure it stays short: only a handful of people are present, and the updates should all fit inside a tweet. If you start to get tired of standing in place and you’re shifting your weight between your legs, the meeting has gone on too long.

At the end of the iteration, the project manager talks about the status with the product owner and they prioritize tasks for the next iteration, which allows the

We work on one-week iterations, but have had no trouble accomodating two-week iterations in the past.

High-Level Project Flow: Releases

There are several schools of thought around releases, but really, releases end up optimized for the product being released and the structure of the team carrying out the release. Obviously, this doesn’t apply as cleanly to research projects or proofs of concept (cf. Einstein’s famous quote about why it’s called “research”).

• Big releases happen when a bundle of features is done. This is the usual case for big companies and initial releases, and it is the only possible case for some types of products. Operating systems, programming languages, and APIs often have to remain stable to give plenty of time to users that will be affected by changes, and projects that have a high overhead for a release (hardware products, mobile applications, etc.) often have to use this strategy. For smaller projects, it is often a mistake to hold off on releases for too long, as stagnation can cause a sharp drop-off when users have only recently adopted a product.
• Incremental releases are the normal case for web-based projects of any size. Sometimes they are designed to happen on a schedule, and sometimes per-feature. This is the typical case for a lot of projects, especially web-based projects. Scheduled releases map neatly to iterations, and continuous delivery can maintain stability by introducing only stable changes and introducing them gradually.
• Move fast and break things, a style articulated by Mark Zuckerberg, is a release style that fits startups: whenever something is done and there’s nominal signoff, push it to production, and if there are bugs or the users hate the changes, fix it and deploy again. This style is well known from the earlier days of Twitter and Facebook. (Facebook’s size has made stability a higher priority, so Zuckerberg has retracted it since those times.) Counterintuitively, it can actually drive user acquisition: early adopters are attracted to the lack of polish, looking small can make users feel attached and invested, and if they like what you are making, you’ll get free press when they complain on Twitter that this thing that they love so much is down or broken.

Project Completion: Party Time

We’ve finished a phase of development! Everyone’s super excited, we’re watching the server logs to see if anything is breaking with one eye and the analytics dashboard with the other to see users flock to the site. Assuming everything goes as planned, it’s a good time to take a break.

There You Have It

So, there’s the primer on working with us, and an explanation of the development process and how we view it. Now you know what to expect when you hire us.