FRENDS R&D development process

Hi,

This time I decided to post something not so technical as some of the latest posts have been. While this post does not directly deal with our products, it’s about how we develop them, meaning our processes.

Like many teams in software engineering industry, we also adopt agile methodologies in our work. We do not use any specific methodology as they are written, but with some modifications to fit our needs and ways of work better. The easiest way to describe our process is to say it’s a Scrum-like-process. Probably our work as a team resembles that of Scrum teams quite a bit. To an outsider it most likely will look like that we are a Scrum team: we have daily meetings in which we discuss the situation of issues in progress and possible obstacles that we have encountered. In addition to that, we have a planning meeting each Monday and set a goal for the work week we’re facing. We have internal demo sessions every 2-3 weeks where we present where we are going with the development and what can be expected to be done in near future. We also have retrospectives every once in a while, trying to have them at least somewhat regular interval of 4-6 weeks. Retrospectives can be pushed forward, especially if we are on the verge of a new product release. Products come first, after all. All these are practices familiar to Scrum people. What is not-so-Scrum in our process are roles and wallboard. First let’s take a look into our roles.

Our roles are not as “fixed” as they are in Scrum. Roles contain same responsibilities as Scrum roles except we do not consider Scrum roles as separate roles in our process. Some responsibilities assigned to ScrumMaster and to Product Owner in Scrum are combined for Lead Designer role within our team. That is subject to change, making the roles kind of “floating”, meaning responsibilities can be reassigned to different roles and/or persons as needed. One change from Scrum in comparison to our process relates to our process retrospectives. As mentioned earlier, we have them like a Scrum teams have, except organizing them is not on the Lead Designer’s (which holds the ScrumMaster responsibilities) responsibility, but instead another person takes care of them. So basically it was thought that combining roles brings more responsibilities to one person and therefore some responsibilities could be given to someone else.

We use a Kanban board as our team room’s wallboard to visualize work in progress. For us this means that we have limited the number of issues that can be in the implementation queue waiting to be implemented. We don’t have fixed sprint backlogs and new issues can be added to queue as needed, an idea familiar in Lean processes as well. This ideology will ensure that there will always be something that developer can do, once currently developed issue is finished. In the past when we did not use a Queue where we put issues ready to be implemented, our wallboard got bloated with issues that were supposed to be in the development queue. Eventually we noticed – over and over again – that there were tons of issues with no hope of actually getting to be implemented for the next release version. From time to time we did cleanup the wallboard of all tasks there were, but ended up with the same situation again which led us to use an implementation queue for issues with a limit on the amount of issues. Using a queue requires us to do prioritization to make sure that only the most relevant issues are on the queue to avoid the issue bloat effect experienced in the past.

We use code reviews, a practice used in Extreme Programming (XP), on regular basis in our process. Each commit must be reviewed by another member of the team before commit is allowed to be pushed in to version control, which in our case, is Git. Code reviews have proved to be very valuable and useful. As can be expected, the reviewer may see some problematic areas in the code that need to be addressed before pushing the code to version control. What we have already noticed is that, reviews are also good for the presenter as the presenter may see some issues with the code that may have slipped by unnoticed during the development. Sometimes it helps to say it out loud.

We are currently testing Git branch workflow in all our work with the goal to maintain the process similar no matter where our team members are physically located. At first, it changed our review practice a bit, adding a new step to review process. We also ended up adding a Ready For Review column to our Kanban table to reflect the change in our process. At the same time we decided to remove Done column from the table since it didn’t really add any value to our day-to-day process. The column also got bloated with finished issues because we don’t do releases every 2-3 weeks like in Scrum. We’ll see how this process will work for us in the long run. I’m guessing we’ll get used to it just fine. Changes probably are to be expected at some point in the future, but isn’t that the goal of having process retrospects after all: changing AND improving processes?

Currently our Kanban board looks as follows:

In order to create high quality products and to maintain the quality level, quality assurance is something that cannot be omitted. In our team, quality assurance is done internally. With implementation tasks, we write unit tests and integration tests as well. Having a Continuous Integration (CI) server running the unit tests and integration tests automatically is a very efficient way to ensure code base remains stable and nothing gets broken. Occasionally that happens, but that’s the CI server’s task to alert of such cases to get the code back on track before the product release. For web applications there are even some relatively nice tools to test the user interface functionalities, but we have found out that they are a bit unreliable. We’ve tried WatiN and Selenium, both have good and bad sides. Some things are done better in Selenium and vice versa. If we were to decide now, what to use for web user interface testing, we’d go for Selenium, mainly because of its much more active development community. Unfortunately it is not perfect either, but guess it’s the best there is.

So, that’s how we get things done in the FRENDS R&D.

-Jouko