This Is How We Do: Agile For Small Distributed Teams

In some of my earlier blog posts I have already touched the topic of using Scrum as a project management framework and me becoming a Certified Scrum Master this summer.

Scrum is an extremely popular tool for managing software development projects and provides great guidelines for becoming more organised in your work. However, it was orignially tailored for collocated development teams with a minimum headcount of 5–7 people.

As you know Barouh & Partners works remotely, currently with six people in total. In spite of this, we are dedicated to use agile methods to keep our workflow organised. Let’s see how Scrum can work great for a small distributed team, like ours.

1. We talk a lot

B&P starts every day with a morning call, where everyone shares their working plans for the day and gets in sync with the rest of the team. The morning call usually happens on Skype and most recently on Google Hangouts. We try to limit the timeframe of the morning call to approximately 15 minutes and don’t get too much into details.

During the day we video chat regularly. Even on the most passive day we do at least 4–5 calls/person. It is always expected to ask for a second opinion when you’re not sure about something, need clarification about a new feature or the direction of development. However, we try hard not to disturb someone when he is in deep concentration.

We use Slack for water cooler talk and discussion about our projects. Also a clever little setup allows us to follow the developer’s commits for deployment in a chatroom (i.e. we see in real time what was the latest feature or fix added to an application or website).

2. We formulate great user stories

User stories capture the essence of a feautre in one or two sentences written in everyday language. They have become a standard in software development, as user stories are great to define the scope of a project and describe each and every feature very specifically.

How does a user story look like? Something like this:

As a [role], I want [goal/desire].

Simple as that. Let’s see a real life example from a simple backend/CMS:

As an admin, I want to be able to create news stories from the backend.

Of course a user story like the above could be and should be broken down into smaller chunks. Something like:

As an admin, I want to give a title to a news story.
As an admin, I want to give an annotation to a news story.
As an admin I want to publish a news story by clicking on the ‘Create News’ button.

And this list should go on and on until you’ve detailed each and every bit of the feature you want to create. The more user stories you write the better. Anyway, user stories are great to get the entire team on the same page and to bridge the technical knowledge gap between developers and project managers.

3. We know our story points

We give a each user story a so-called story point, that determines the effort required to complete the feature. A great advantage of having a small team is really knowing the weight of story points.

For instance I know that for our Mirko 1 story point means approximately 30 minutes. This means if he assigns 8 story points for a user story, developing that feature will cost him around 4 hours. This is great for estimating workload and planning ahead.

4. We use the hell out of Basecamp

Basecamp is a great collaboration platform we use on a daily basis to manage our projects. The core of the application are to-dos: to-dos are assignments with due dates and a person responsible for them. The best part about Basecamp is it’s simplicity, however, it might be too simple to use for agile development.

Anyway, we sort of found a way to effectively manage a project with user stories on basecamp. This is how it looks:

We make big (theme) user stories to-do lists and we break down that user story into smaller chunks and add them as to-dos. This way it is easy to follow responsibilities and timeframes, while everybody is aware of the direction of development.

5. We make nice spreadsheets

Besides Basecamp, we keep tabs on the user stories and progress of the project on a shared spreadsheet. This gets a little bit of confusing from time to time, but it’s worth the effort to have a nice documentation of everything we’ve done.

You can find great templates for Scrum Boards and Product burndown charts in spreadsheet format. Never forget, google is your friend.

6. We log everything in Harvest

Harvest is a great tool we use for time tracking. This means we log all of our working hours, so eventhough we work remotelty, everything is quite transparent.

We can also set time budgets for projects and receive e-mail notification if the hours are getting out of hand. This is a great way to plan ahead and keep track of things.

Also if I see someone’s currently busy with some taks, I’m definately not going to bother him with some little problem of mine.

7. We are always trying improve

We keep looking into ways to improve and experimenting with tools that might help us grow professionally, such as Trello, Blossom or Kerika. We are testing some new and interesting stuff as this blogpost is being written.

Who knows what’s next, new applications appear on the horizon every day and we are willing to drop our best practices and create new ones. Change is great if you ask me.