Like most organizations that have given agile development a serious try, Genius.com Engineering has found it to be a boon to our efficiency, transparency, and productivity. The process we use didn’t come from an instruction sheet, wasn’t imparted upon us by an agile prophet consultant, and it isn’t written about in a book—it grew organically. That’s not to say we are revolutionaries in software development, or that we ignored all of the aforementioned sources of information when creating the process that Genius.com Engineering uses. Rather, our methods are picked piece by piece from those sources. When we have a problem that could be solved by changing the way we work, the team is open to making changes to our process and trying something new.
Scrum as a Basis
At a high level, our process employs a lot of the concepts of the Scrum framework. We have a product owner who keeps a backlog of desired functionality that need to be done—everything from “develop moneybag delivery system for customers” to “move this icon to the left a little bit”. With few exceptions, any work we do goes through our product owner so that he can properly align the scarce developer time available with the needs of the business.
The one thing that falls outside our product owner’s domain is our own engineering backlog. Like any development organization, we have tasks that may not have any direct business utility, but are important for our own sanity or efficacy. Our engineering backlog contains items that fit into three broad categories:
- Old areas of the code that don’t fit well in our current architecture, should be updated, or are difficult to change (technical debt)
- New language or library features that would simplify existing code
- Testing enhancements that will help us write better code more quickly
Working with our product owner to collate the two backlogs, we try to work one or two of the tasks from the engineering backlog into each sprint.
Keeping Things Lean
From elsewhere in the world of agile, we take the the practice of lean software development. The main tenet of lean is to eliminate waste. Waste exists in many different forms and can be addressed through viewing your development process as a system and applying some fundamental concepts:
- Delay development of features until needed
- Eliminate unnecessary code & functionality
- Eliminating bottlenecks (related to Scrum impediments)
- Building quality in rather than testing defects out
- One-piece flow (queueing theory)
Code that is not used is waste. By waiting to produce code until it is actually needed, our team is sure to be writing the code that is needed, not something that mostly gets the job done or has to be hacked to fit our current problem. Eliminating unnecessary code allows the team to reduce the amount that we must maintain, thereby reducing the risk of regressions when altering existing code.
When we develop new features at Genius, we keep a tight focus on what is required to make that feature happen. There is often a temptation to expand the scope of a story, getting related work out of the way with the thought that it will be useful in the future. The problem with such enlargement in development is that what we perceive to be a future extension of a feature may turn out not to be necessary, once again introducing waste. By remaining faithful to what is defined in a user story we ensure that valuable development time gets spent building the highest value features and no work goes to waste because of changes in future plans.
Though our engineering team is made up of multi-talented individuals, and we practice collective code ownership, inevitably everyone has areas of the code that they prefer, or are on which they are more effective at working. When we choose user stories to work on during a sprint, we take into account the makeup of our team in relation to the work that needs to be done to complete a story. If one of our front-end folks is going to be on vacation part of the sprint, we will try to choose stories that are lighter on front-end work.
In order to reduce our dependence upon any one team member, the Genius engineering team engages in a lot of pair programming. This practice, taken from Kent Beck‘s Extreme Programming is wonderful not only for tackling complicated problems or areas that require fresh design, but also helping team members work on areas of the code that they wouldn’t venture into alone.
Continuous Improvement (Inspect and Adapt)
An over-used and often misattributed quote applies here: “Nothing endures but change.”
The most important lesson we’ve learned about our agile process is that the process itself should be agile—there is no reason to be married to a particular style of development if it doesn’t work with the team, or doesn’t help solve your problems effectively. In light of this, the way Genius.com Engineering works changes all the time; from the way that we run our daily standups, to the manner in which we breakdown stories, to the way we validate the completion of stories. Whenever inefficiencies are found, we change the way we work.