Scrum in a small team with multiple projects

Submitted by christophe on Sat, 01/10/2016 - 09:28
Trello as a Scrum board

 

Summer was inspiring! A really pragmatic talk on how to apply Scrum from dasjo at the Drupal Dev Days Milan acted as a kick-starter and we decided to apply it in our small Drupal dev team at Tilt Factory.
Our team is composed by 2 at the front end, 3 at the backend, with people combining responsibilities like PM and sysadmin. We have 5 to 10 concurrent projects with ~ 30 projects to maintain.

Where did we start from?

After 400+ pages reading about the Scrum theory, a few months ago, our first reaction was that it was not compatible with multiple projects (e.g. how to apply in sprints?) and urgent client requests that are most of the time perceived as intrusive.

This summer, we decided to give it another try, and began by re-reading the Agile manifesto. We were pleased to remember that we already applied most of the principles that were described here:

  • customer satisfaction with a preference for simplicity
  • self-organizing team that welcomes changes and communicates well
  • frequent delivery
  • constant refactoring for sustainability
  • ...

We wanted to keep our tools intact to get started. Most of the people from the dev team welcomes changes but it also involves clients and the management team that already have to handle a bunch of other tools. We also wanted to avoid several changes at a time and see if it was possible to adapt within the same infrastructure.

We were already using

  • Trello to allow every person to get easily into the Kanban (sales, product owner / client, scrum master, dev team). Jira looks more like a dev tool and we wanted everybody to feel comfortable with it.
  • GitHub for the Wiki

The main question was: how to improve our methodology? Even if we were iterating on each step, we tended to be really sequential (all the mockups, then all the layouts, then all the dev, ...).

The downsides of this approach are

  • Too much specifications, this does not reflect the reality of a web project that must welcome changes.
  • A delay on one step have consequences on the other, plannings are not well perceived and often it is interpreted as a lack of professionalism.
  • The website was still kind of broken a few weeks before the launch.
  • We tended to give too much detail on one step, consuming the budget and the time without a bird eye view of the priorities.
  • It was often driven by a single person (the project manager), that quickly became a bottleneck instead of a facilator.

Second, how to get a clean approach under our Kanban (Trello)?
The client have access to it and the granularity was not always the same, depending on the person. Also, the GitHub Wiki was a huge resource... but to be honest it was a bit chaotic,  due to the lack of contribution guidelines.

Scrum in the wild

Here is what we applied from what we learned, mostly taken from the ressources section at the end of this post but also with a taste of our culture.

Pleased to meet you

We always begin by an informal discussion with the client. It is really fundamental. We will work several months together on a project, the human relation have to match. If we agree on the big picture, we go on with basic questions over the client company and the project (mission, primary objectives of the project, current situation, audience, budget, ...).
This documentation is maintained on the GitHub Wiki during the project to get easy onboarding and refer to it at each stage.

The design sprint

This is the project kickstart, ideally the first sprint. The whole team (client included) is involved / empowered.

  • Discover the project: analytics if any, personas, user stories and flow
  • Free your mind: creative approach by throwing ideas, getting inspired by other cases, ...
  • Live mockups: quick sketch and prototyping
  • Roadmap: define user stories, estimate and retain what is for the next sprints and what is for the icebox (see later: Scrum board).  

User stories

For each user story (or issue at a later stage), we have a common structure, inspired from the Drupal community. What we really like is the problem/motivation + proposed resolution approach. Nothing really comes out of the blue (you know, the I-have-seen that-on-this-website-this-is-really-what-we-need syndrome). However, the creative and "stumble" approach part is still admitted in the product backlog (see later: Scrum board).

Here is the structure, taken from the Drupal issue summary template:

  • Problem / Motivation

  • Proposed resolution

  • Remaining tasks

  • User interface changes

  • API changes

  • Data model change

We also complete this by what is the acceptance test, so we know when we can move it from "In progress" to "Done" (see below).

Each issue is a Trello card, so everyone that takes part to the project can comment it. We can also use the Trello checklist to get a clear overview of remaining tasks. Most of the time, a task can reference a GitHub issue.

Every developer can

  • self-assign tasks and/or onboard on the issue card
  • review what was commited on GitHub because each commit references the issue.

Unit tests are implemented to be sure that it will continue to work after a change (CI).

Scrum board

The columns that we retained are

  • Product backlog: tolerance for different granularity, throw ideas that comes from meetings, observations, ...
  • Sprint planning: stories to estimate
  • Current sprint: what has to be done
  • In progress: what we are actually working on
  • Done: what has passed acceptance tests and is live
  • Icebox: ideas for next sprints

The issues naming convention for a user story is typically "As a {user type} I want to {action needed}". Here we replace the user type by Trello labels (front and backend developers in this case).

Trello user stories and labels for user types

 

Scrum ritual

The ritual was explained to the team and the client.

  • We have small to medium sized projects that takes from 2 months to 1 year, so sprints are short: one week. The former "project manager" became the product owner of the team, so he can define priorities between the clients.
  • The Scrum master reports, solves the dev team issues, coaches about the Scrum process, is the link between the dev team and the client (product owner). He protects the dev team planning. In our company, it is not a full time job.
  • We begin each day by standup meetings with the whole team (5 to 10 minutes): what has been done yesterday, what are we working on today and what are the blockers, so each person can help or assign the other, depending on the skills and the charge. We achieve the same goal.
  • We propose a backlog grooming and retrospective with the client, he can discuss with the whole team so he is part of it. We can review what has been done (deployed live after passing acceptance tests) and what was not. It also avoids interpretations from a single point of contact.
  • The poker planning is done for issues estimation. People that have differences must explain why. We use points instead of hours (that strongly depends on how fast a person is on a task). Points reflects what the team can accomplish.
  • We also have a weekly retrospectives of what worked well and what can be improved. The scope is within the dev team and the process with the client, so we can adapt quickly.
  • For urgent requests, we have a fastline, we foresee a day in the sprint for ticketing and helpdesk. SLA is defined with the client as well.

Tools improvement

We used Trello power ups to get the integration with GitHub and reference issues in the Trello cards. All the "dev only" discussion is in the GitHub issue tracker or Wiki. This last one is also used for new developers (freelancers, client team, ...) onboarding.
We also use the Scrum for Trello Chrome extension to have a clear overview of estimates.
Nowadays, we consider adopting GitLab, that have a global approach.

Getting inspired

When we decided to compare it to a practical case that worked, we observed how the Open Social distribution was built: user stories, roadmap, lo-fi prototype, style guide, ...
Once again, we were pleased to see that it was an improvement of what we already used.


Conclusion

I think that most of the teams are already applying Agile without knowing it, and there is very little effort to apply your own flavor and get the pleasure of doing things the "right" way.

I will repeat here the conclusions of dasjo about the benefits of Scrum:

  • More ownership - transparency

  • Less bottlenecks

  • Better quality - team members test each others, think differently about code

  • More motivation

  • Constant learning curve

Ressources

Tags

Add new comment

Restricted HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.