In the first post in this series, I talked about some of the challenges that we faced trying to implement Scrum on one of our large client projects. After failing to reap the benefits from Scrum, I designed a new process that was better suited to our project and our team. Thus Intridea Forge was born.

On the weekends, I help out at a local non-profit educational dairy farm doing blacksmithing. In the blacksmith’s workshop, you start with raw materials and put them in the forge to heat up. The forge heats up the metal to the point where it’s soft enough to be worked with tools like hammers and anvils.

This new process serves as a forge for ideas about the product. We use the process to take the ideas from cold, bare metal to a point where they are hot and maleable for the developers to work them into a finished product.

Intridea Forge in 200 words or less

In case you don’t care about some of the details, here’s the tl;dr version of Forge.

Forge is centered around three key concepts: release iterations, feature ownership, and the finisher.

Release iterations are variable-length, feature-based iterations that correspond to a full production release of the product. Iterations aren’t tied to a fixed timeline and they only end when the last of the features is completed. Every iteration is a release iteration.

Feature ownership is the result of starting each iteration with a single developer being assigned to a single feature, even if it’s huge and complex. As developers finish the easier features, they roll over and help on the bigger ones or work on code improvement.

The finisher is a role on each iteration filled by a single developer who is not tied to a specific feature. Instead they are dedicated to fixing bugs, code improvement, and reduction of technical debt (or any other task that makes it more of a finished product). The developer assigned to this role changes every iteration.

Intridea Forge in Detail

Since a picture is worth a thousand words, here’s a graphical overview of how an iteration progresses.

• Release Iterations

  Iterations in Forge don’t have a fixed length. Instead, iterations are tied to the completion of all of the features slotted for that iteration, regardless of how long it takes. This means that iterations will rarely be the same duration as they are pegged to functionality, not a specific schedule. At the end of each iteration you do a full production release, complete with feature announcements and all of the other fanfare.

  This is a bit unconventional in the Agile world and it may sound more like traditional waterfall, but I promise that it’s not waterfall and brings quite a few benefits with it.

• Developer Ownership

  At the beginning of the iteration, all but one of the developers on the team are assigned to work exactly one feature each and to work it alone. The developers will then own the feature they start on for the duration of the iteration.

  Since not every feature in an iteration will require the same amount of time to complete, there will be developers who finish their features “early” (it’s not really early and shouldn’t be regarded that way; some features will be more complex and will take longer and no judgement should be placed on how long it takes to complete). When a developer finishes their feature (and all supporting test and documentation), then one of two things happen.

  If all of the other features are progressing without any issues, then the recently freed up developer simply gets added to the finisher pool (see below). If any of the features are lagging, complicated, tedious, or otherwise in need of help, then the project manager will reassign the developer to help with that feature.

  Let’s say Sally is working on a difficult feature and John completes his feature early and shifts over to help Sally finish. One of the advantages of this process is that by the time John comes in to help Sally she will have already have gotten started on the feature and should be able to easily guide John. At this point Sally will know what needs to be done and how it needs to be done and can make effective use of the additional help.

• Finishers

  Most of the development team is assigned a specific feature to work on for the iteration. The extra developer is assigned to a rotating role called the finisher.

  The primary responsibility of the finisher is to respond to critical popup issues. Such issues might include bugs that were recently introduced and missed during QA, a minor but critical new feature, or other similar items. Any time that the finisher isn’t working on these popups he or she can work on anything that they think needs to be done to make the project better. Examples may include:

  • Fixing old bugs
  • Adding documentation
  • Improving test coverage
  • Refactoring difficult code
  • Modularizing features into components that can be reused and/or released as open source

  Each iteration, the finisher should be a different member of the development team. The rotation of this role is essential and provides a few advantages. First, it keeps developers from getting stove-piped into a single part of the system or a single type of development. It gives everyone the opportunity to dig into other parts of the project. It also ensures that everyone has a chance to clean up or rework some piece of code they may have run across on a previous iteration.

Key Events

During the iteration, the management team has a responsibility to be setting up the next iteration for the team. This is handled by several important meetings.

• Iteration Kickoff
  Who: Development team, project manager

  At the start of the iteration, the project manager meets with the development team and describes the features for the upcoming iteration. During this meeting, the team members are assigned to the various features and the finisher is identified. This is also an opportunity for the development team to get details on the new features and clarify any questions they may have.

  At this meeting, the development team will also give their estimates for how long the features will take. This will be relayed back to the management team and other stakeholders so that they know when to expect the end of the iteration.

• Release announcement
  Who: Management team/stakeholders, project manager

  After all of the work from the previous iteration is complete, the management team meets to schedule the release and plan any downtime. They will review the new features, prepare newsletters, blog posts, etc. at this meeting. After the release is planned, the deployment team will perform the production deploy.

• Mid-Iteration Review
  Who: Management team/stakeholders, project manager

  Based on daily reports from the development team, at this point the project manager informs the management team of the status of the iteration so far. The estimate for completion will be updated and any features that are available on staging can be demonstrated. This meeting can occur multiple times during the iteration.

• Initial Planning Review
  Who: Management team/stakeholders, project manager

  Throughout the iteration, informal planning for the next iteration should be ongoing. The initial planning review is the first occasion where the management team meets to formalize plans for the next iteration. At this meeting, the project manager will collect inputs and rank upcoming features. He or she will also start to flesh out the feature requirements so that estimates can be made and dependencies can be addressed.

• Dependency Review
  Who: Project manager, technical management, lead developers

  After the first pass at defining the next iteration is completed, a dependency review is held. This is the opportunity for the various inter-dependent teams to ensure that everyone will be accommodating any upcoming changes. For example, if the web site team will be making a change or adding a feature that will affect an API used by the desktop application, then this meeting should be where the project managers for the two teams meet to discuss the implications and deployment strategies.

• Final Planning Review
  Who: Management team/stakeholders, project manager

  Leading up to the final planning review, the project manager should have placed initial estimates on all of the features and thoroughly fleshed out the requirements. The final planning review meeting gives the management team one last opportunity to change course on the next iteration before it is locked it. Timeline estimates are reviewed and everything is agreed upon.

Throughout the iteration, informal planning should be happening to lay out upcoming iterations. As the iteration progresses the management team will also be able to see previews of some of the new features as they are made available for testing on staging. This helps ensure that the capability is implemented as intended and satisfies the curiosity of the management team to see what is being built.

Conclusion

This post has given you an overview of Intridea Forge. In the final post in the series, we’ll tell you about why it has worked well for our team and we’ll share some of the challenges that we faced implementing it. We’ll also give some tips and lessons learned about how to implement it on other projects.