In the first two posts in this series, I explained some of the problems that we had with traditional Scrum and then laid out our new Agile process: Forge. In this post, I’m going to share a bit more about implementing Forge on our project and tell you about some of the benefits and challenges that we ran into.

The Benefits

Forge has solved a lot of problems for our team. Here are some of the most significant benefits we have seen.

• Getting rid of technical debt

  One of the biggest problems with any project is the accumulation of “technical debt” (TD). TD is simply bugs and complexity that get introduced as a project gets larger. Things get even worse if you aren’t starting from scratch and will be working with someone else’s code.

  The advantage of having a finisher (or many finishers towards the end of the iteration) is that you have a dedicated developer whose primary job is reducing TD. Few other processes even acknowledge that you accumulate TD, let alone insist on a mechanism for reducing it. Over time, the net result is a more stable, more maintainable project. Ideally the process will also result in a robust library of modules and/or open source components that you can tap for enhancements and future projects.

• Developer focus and ownership

  Since each new feature is assigned to a single developer, he/she develops a sense of ownership of that feature. There are several key benefits you get from this. First of all, since the implementation details are left entirely up to your developers, they are granted a level of autonomy and freedom of design that is very rewarding.

  Second, since each developer will begin an iteration as the sole person responsible for a new feature, by the time another developer is available to help carry it to completion, they will be very easily integrated into the task at hand. This dramatically reduces potential conflicts and improves productivity.

• Clearly defined release feature set

  After a final QA check at the end of each iteration, the product goes through a full release. This process gives the team the opportunity to roll out new features as part of a complete release that can be communicated to users and partners. This vastly improves transparency and gives the customer the opportunity to promote the new release and also alert users of potential downtime.

The Challenges

Despite these benefits, Forge is not a silver bullet. There are several challenges that we have run into and had to either work around or adjust our expectations.

• Delayed gratification

  One of the biggest roadblocks we faced was that our clients weren’t happy with the fact that they would need to wait for completed features. For example, if Sally completes a new feature four days into the iteration then it can be hard to explain why they have to wait another week for it to go to production. Over time the benefits of having a clear release announcement have outweighed this concern, but it can still be a hard sell for some organizations.

• Long-running features

  Some features can also be difficult to implement and thus take far too long to tie the delivery of an entire iteration on its completion. For example, if you have six features slated for an iteration and one of them is expected to take four weeks but the timelines for the others are measured in days, then it doesn’t make sense to have most of your development team acting as finishers for three weeks while you wait for the completion of the difficult feature.

  Features that are going to take a long time to complete should typically be known during the planning phases. When one of them is on the list, the simplest thing to do is to let it carry over multiple iterations. When the feature is finally completed, the developer working on it just becomes a finisher for the remainder of the iteration as they normally would.

• New projects

  Forge was created for a project that we inherited from another development company and so it came with a great deal of existing technical debt. In addition to simple code complexity, we had to deal with a large number of bugs from the first day on the project. This makes it easy to figure out what the finisher should be doing during that first iteration, but most projects aren’t “rescue” projects and the team will be starting from a blank canvas.

  Forge obviously still works in those situations, the only tricky thing is to figure out what the finisher should be doing early on. There are two different approaches that can be taken. First, you can leave off the finisher during the first iteration or two and only bring that role into play once you see yourself starting to accumulate technical debt. This can be risky because you may end up in a situation where the finisher never actually materializes, so we recommend that you explicitly limit the number of iterations without a finisher to one or two from the outset.

  The other possibility is to task the finisher early on with some of the infrastructure-oriented tasks. Configuring servers, deployment scripts, and continuous integration systems are all things that need to be done early on and may be a good place for the finisher.

• Small teams

  Forge assumes that you will always have one person dedicated to fixing bugs, but on projects with very small teams (e.g. 2-3 people) this can seem like a burden. The truth is that it probably is a burden for those projects. In these situations, you will need to tailor the process a bit to suit the circumstances.

  There are a number of ways to address the issue. Some ideas that pop to mind are only including the finisher role every other iteration or requiring that the first person to complete their task always becomes a finisher instead of rolling on to help with another feature. Each project should address these challenges in the way that suits the team and the client best without worrying about rigidly sticking to a process.

• Multi-finisher iterations and blitzes

  There were times on our project where we found ourselves falling behind on technical debt, even with a dedicated finisher on each iteration. This was most apparent when a new feature that we released turned out to have unforeseen consequences across the product. We found that sometimes we needed to run an iteration where we were less focused on features and more focused on finishing.

  These special iterations took one of two forms. The easiest form was simply to assign more than one person to the finisher role. When we might normally have five developers working features and one finisher, we would conduct an iteration with only two features and four finishers.

  The other form was what we called a blitz. We would designate an iteration length of a week and put the entire team on a finisher role. Blitzes also served an important planning role. The management team would spend blitzes reevaluating the whole feature wishlist and make sure that we were still on the right track. At the end of a blitz, we would have a fresh start with a renewed focus and direction for the product.

Conclusion

Forge has become a powerful weapon in Intridea’s arsenal. At the core, we are successful because we have extremely talented developers who can work miracles. But even the best developers in the world can run into roadblocks if the process they work under doesn’t help them get their jobs done. Forge helps our developers get the job done by making sure that the raw materials of a project, the ideas, are malleable enough to be worked into a finished product.