Agile development at HSTRY
In a previous post, I wrote about the deployment process that the HSTRY development team follows, i.e. the flow of the implementation of a feature from local development to the live application. In this post, I will stay in the realm of agile development and explain more about our development process. Read on if you want to hear about Scrum, Trello boards and daily standups!
Scrum is a popular agile methodology to manage product development. Its main advantage is that it offers a set of processes that have already been defined, refined and used by many teams around the world. Therefore, when we adopted Scrum, we didn’t have to invent our own processes as we simply started following the best practices and guidelines dictated by Scrum. If you want to know more about it, I highly recommend you watch the Scrum Training Series.
We work with sprints of two weeks. This means that the work to be done during a sprint is defined at the start and is closed off at its end. At the end of every sprint, we do a sprint review meeting. During a sprint review meeting, the development team presents to the rest of the team the progress that has been made on the product during the sprint. This is the opportunity for everyone to be kept up-to-date with the advancements on the application and to give her or his feedback.
One centerpiece of our process is the Trello board, which you can see below. Every member of HSTRY has access to this board as besides being a work-in-progress management tool for the development team, it is also a great visual communication tool between the development team and the other members of HSTRY. With one look, anyone can see what the progress is for the current sprint.
It consists of five columns. A story (i.e. a Trello card) always travels from left to right:
- Backlog: the backlog of all the user stories to implement at some point.
- Planned: the stories that will be implemented during the current 2-week sprint.
- Doing: when a developer starts working on a story, he adds his name to the story and drags it to this column.
- Code Review: when a developer has finished the implementation of a story (which means all the tests on the continuous integration server are green), it is ready for the other developers to review the code.
- Done: a story is considered done if and only if it has been pushed live.
Before we started using Trello, we tried more dedicated tools before such as Pivotal Tracker. However, we found out that although they were more powerful and more feature-rich than Trello (e.g. Pivotal Tracker allows you to assign a complexity to a story), it also made them more bulky and less easy to use. Feature-wise Trello is so simple (to the Trello people, please keep it that way!) and that’s what is so good about it. It is very easy to use, and enables us to focus on the actual work at hand.
Daily standups are another Scrum practice that are very important for our process. Every morning at 10.30am, the development team gets together (generally on Hangout as we’re a distributed team) and each member explains:
- what he’s been working on the previous day
- what he’s going to work on today
- what difficulties or problems he’s facing
This is the opportunity to know what the others are working on and to discuss issues. Because we do them daily, issues do not drag along but are handled early. Also, it brings a sense of accountability to each team member. We all trust each other (if you don’t trust your co-workers then you’ve made a wrong hire) but knowing that you need to tell your progress on a daily basis forces you to frequently self-reflect on the work you’re doing.
Distribute power and knowledge amongst all developers
No one should be allowed to be indispensable. No single person should be the sole person who knows how a specific part of the application works, or that has specific privileges such as the ability to restart the server. We have two mechanisms in place to prevent this from happening.
Every developer has equal power
From an intern to myself, every developer has the ability to deploy to production, to restart a server, to merge into the master branch… We believe in trust rather than restriction. Like I mentioned previously, if we can’t trust someone, we shouldn’t have hired that person in the first place.
In my eyes, code reviews serve two purposes. First, they improve code quality. Furthermore, and maybe more importantly, they allow all team developers to be familiar with the entire codebase, even with parts that they haven’t written themselves. This makes sure that there are no “magic boxes” where only one person knows how that part of the application works.
Bug-fixing Friday afternoons
We file all our bugs in BitBucket‘s issue tracking system. At one point, we noticed that we never got around to fix the trivial, low-priority bugs. There was always something more important to do and some bugs simply never go fixed.
To remedy this problem, we introduced “bug-fixing Friday afternoons”. Every second Friday afternoon (when we don’t do a sprint review meeting), we stop working on the stories planned for the sprint and work on the list of bugs, starting from the oldest. We’ve been doing this for four sprints now and it’s been working very well. Reflecting back on your process and seeking constant improvement is one of the corollaries of working in an agile manner.
What Scrum has brought us
If you’re familiar with Scrum, you may have noticed that we don’t follow all the practices enforced by the methodology. For instance, we don’t keep track of our velocity, nor do we have backlog refinement meetings as we merged these into the sprint review meetings.
We do believe that we have put in place a set of important practices that greatly improve the quality of our development and thus the application. I think the biggest consequence of working in small sprints, doing daily standups and having a two-weekly sprint review is that problems are identified and tackled early. This can be a technical problem that arises during a daily standup, or a problem with the application that was identified during a sprint review meeting. Our team resources are limited so we need to iterate quickly.
I hope you enjoyed reading this post about our development process. We are continuously improving our process and I’m pretty sure there will be a follow-up to this post at some point in the future.
Please feel free to contact me at email@example.com if you have any comments or questions!
This post originally appeared on the HSTRY company blog.