Author Archive

How we do it

Agile, XP, and SCRUM
We use programming and project management techniques that are derived from Agile, Extreme Programming (XP), and SCRUM.

Realtime Visibility and Control
We offer client tools that allow you to monitor and control your project in realtime. Projects are broken down into “user stories” and then progress against these stories is updated continually by our engineers. You’ll always know exactly where things stand. You can also add, remove, change, or rearrange stories at any point. You have up-to-the-minute control over what features end up in the final release and in what order they get done.

Sprint-based Iterations
A sprint is a one week release cycle. By keeping the interval short, we maintain a tight focus on the most critical features. The end result of a Sprint is functioning, error-free, releasable product. This gives the stakeholders a chance to actually use the product which, in turn, influences the features and functionality of subsequent Sprints.

Continuos Deployment
During the Sprint, user stories are deployed to a test environment immediately upon their completion. This gives stakeholders a chance to see features in action before the end of the Sprint. This serves two purposes: First, the project owner can adjust the remainder of the Sprint based on hands-on experience, and Second, with new features appearing everyday, excitement about, and engagement in, the project remains high.

Test Driven Development
The first step in User Story development, is the creation of automated unit tests that validate the feature. After the tests are written, engineers then write the code that implements the feature. Test Driven Development has been shown to be more responsive to rapid changes in requirements while generating more reliable code.

Pair Programming
The concept is simple. Two engineers sit side-by-side and work together on the same code. With two minds continually refining, discussing, and working on the same problem set, fewer mistakes are made, difficult problems become easy, and designs are generally simpler and easier to maintain. Simply put, Pair Programming generates better code, faster.

Team Scalability
The smallest team is one pair of engineers but our approach lends itself to near linear increases in productivity as more pairs are added. Engineers often switch programing partners and the more sets of eyes on a given problem the easier it becomes. With more than three sets of pairs on a given Sprint, productivity gains become less linear due to the increased inability to parallelize. As business requirements change, team size can be quickly ramped up, or down, depending on output needs of the specific Sprint.

Built to Transfer
At the end of the engagement, the project will be transitioned to your internal team. Because our methodology requires that all work be readable by all members of the team, code tends to be more elegant, easier to understand, and have both clear in-line comments and user documentation. In addition, our engagement process gives you real-time access to all features, documentation, and code as it’s checked in.