Last year our team almost tripled in size. We went from 6 people to 15 people including developers, designers and devops. While it was great to see the team grow we faced problems we never had as a small team.

The whole team is working on a single project (Skroutz) so partitioning the workload vertically is not a solution.

In the past we’ve tried various solutions to manage every day development, as well as the development of new features, but in vein. The problem was that we mainly focused on tools instead of focusing on the process.

Some while ago I stumbled on a blog post by Uservoice about their development process (15 minutes read but worth it). In this post they explained how they use Trello and Google Docs to further develop Uservoice.

We’ve used Trello before but since we were too focused on the tools we missed the whole point. So we decided to give it one more shot this time treating tools as only tools and focusing on the workflow.

The goals were simple:

• Improve communication within the team members
• Remove bottlenecks
• Help the team to self-organize

It is important to note here that every team has different needs and there is no one-size fits all solution. We experimented with UserVoice’s solution and ended up in a solution that fits our team’s needs.

How it works

Our process moves around 3 different boards (explained below). There are cases that we create new boards (e.g. for a long running feature), but these boards serve as a feeding mechanism for the Current Development board.

Backlog

This board is where every new request is added. List represent parts of our code base or infrastructure. Who ever adds a new card is responsible for adding a short description of the bug or feature request.

Planning

Every Friday we pick a list of cards from the BackLog and transfer them to the Inbox list of thePlanning board. Which cards get moved has to do with our roadmap and the severerness of the request. Planning has 4 lists: Inbox, Design, Spec ,Ready.

Inbox contains a list of the features/bugs we have decided we want to work on. Depending on the nature of the request and how well it is described it will hop to another list in the planning board.

Design holds cards that have a visual design phase. The creative team maintains a different board for their tasks but we keep cards in the design phase to maintain their progress status.

Spec holds cards that need a specification. This specification maybe as simple as a one liner fix or a whole description of a feature with wireframes, proposed object structures etc. Spec`ing is a task by itself in the sense that investigating solutions for bugs or designing new features is handled by the team as a “todo”.

Ready contains a list of cards that are spec’ed and ready to be moved to the Current Development's Next Up list. It’s just a matter of prioritization.

Current Development

This is where most of the magic happens. The workflow consists of five different stages: Next Up, In Progress, QA, LaunchPad, Live.

Next Up

Every card in the next up list is a fully speced -ready to be implemented- feature or bug. The card should contain enough information so that anyone from the team can pick it up and gradually deploy it.

Team members examine cards in the next up column and are encouraged to pick anything they feel comfortable with. Prioritization is not an issue here because priorities were set in the Planning phase.

Consider an analogy from a car factory: A card is a cardboard box containing an assembly manual and all the necessary parts required to assemble an engine component. The assembly manual compilation and the gathering of the engine parts happened earlier probably by another engineer (or the same one that will complete the task) in the Planning phase.

In progress

When someone picks a cards from the Next Up column he/she moves it to the In Progress column. Ideally there should only be one card from every member in the In Progress column. The card stays there until the task’s development phase is completed.

QA

When a team member finishes developing a task he/she adds a merge request (we’re using Gitlab ) to another team member. The merge request can be placed even before the task is finished in order to gain feedback from other team members.

After the team feedback the author will make any requested adjustments and make sure Kowalski is green. (Kowalski is our distributed CI tool). If all looks good the card is moved to the LaunchPad.

LaunchPad

A card in the LaunchPad list means that it can be deployed any time. In some cases deploying needs a little more effort than rap production deploy (rap is our capistrano janitor, more on that on a later post). Most of the time features/ bugs are deployed the same day (maintaining a project velocity is very important). There are days where we deploy 20 times or more.

Live

When a feature / bug has been deployed the card is moved to the Live list where it will stay until the author talks about it in the Monday morning daily standup.

The process

As mentioned earlier Trello (or Gitlab or any other tool we use) is just a facilitator for a set of actions and processes that enforce the desired workflow.

Daily StandUp

Every day first thing in the morning we do our Daily Standup meeting, only we remain seated due to office space limitations. In this meeting, which lasts 5 to 15 minutes depending on the day, each and every member of the team talks briefly about what they did yesterday and what they are going to do today.

The Daily StandUp is essential to keep the team well informed since one of the goals of the whole process is to distribute the knowledge among all team members.

The next day someone may throw a merge request at you and it helps if you are informed of what that someone is trying to achieve.

Also team members that have heard of a deployed featured or a clever hack or a well known problem are more likely to identify a similar situation when they come across it and take advantage of the already implemented solution.

If you’ve been around long enough you’ve surely seen a lot of reinvented wheels mostly caused due to poor team communication.

Monday morning high five

Every Monday morning the stand up takes a little longer than every other day and there is a reason for that.

We review the Live list in Current Development and team members speak for the tasks they completed, the problems they encountered and how they solved them. We usually talk about major bugs and features, minor stuff goes up in the Live column but we don’t talk about them.

Monday Mornings are causes for celebration. While the team was productive before, it’s easy to think you are doing nothing all week and lose morale. I’ve seen it happen with myself and I had to go back to my mind maps and strike things out to make sure I didn’t throw away a whole week.

Best Practices

The points listed below are a set of “unspoken” rules and best practices. Breaking them will not hurt the process but it’s a sign that something is wrong.

• All team members should provide help to other team members when asked. Whether it’s a merge request or pairing request or brain dumping, team members should be available.
• Team members are responsible for the tasks they pick. They should make sure it won’t block in QA or in the LaunchPad and that it will eventually get deployed on time (SEPs usually die waiting)
• Team members should respect each other’s time and use the tools provided for asychronous communication. Merge requests, mail, irc are there to avoid interrupting people when they are “In the Zone”.
• Break tasks into small chunks that should be completed within a week. Trello has a checklist feature that is quite handy for breaking the task into even smaller chunks.
• Be specific, vague tasks like “Improve performance” will probably be avoided.
• Tasks should not be assigned to certain members. There are cases where an issue can only be handled by a few people but that is usually the exception. Team members should have the freedom to pick any task they feel comfortable with.
• Provide tools that will allow any team member to follow the development line from inception to production. We have Gitlab for code collaboration, Jenkins for CI, Bufo for bootstrapping, Rap for deployment (more on those internal tools on a later post) and of course Trello.

Conclusion

It’s been about two months that we are actively following the described process and we’ve seen a big improvement in our daily work. Apart from having a fixed set of tools that we don’t have to worry about them all the time, we also had some huge gains:

• Anyone can do anything (almost, but we’re close)
• Team works as a whole.
• Developers can self manage their time.
• Reviewing deploys boosts morale. We no longer have this stall feeling.
• We now only have a few tasks that block due to someone being the only authority. We are working on that also.

BTW we are always hiring. If you like what we do here you can drop us an email at admin at skroutz gr.