How We Work

Our goal in developing software products is to help our customers turn their ideas into products as fast as possible. Living in this high-paced world, our customers want to validate their business assumptions quickly, and cost-effectively. We help by rapidly iterating software using the latest techniques and technologies. There is nothing more powerful than real customer feedback and we aim to capture it all in real-time, incorporating all the new great ideas along the way.

How Do We Do This? We use great people, great technology and great process.

We use a modified Agile methodology that we believe balances process doctrine with product output. We've taken what we think is best about Agile, and dispensed with the rest. We want to release software products, so if we need to spend weeks training our customers on project processes, we're not developing software.

With our customers, our projects start with a clean slate. We capture all of their ideas in a Master Product Backlog, which contains "User Stories" written in the classic Agile style. User Stories are written in clear, concise language that includes a specific output. The key to a good Agile User Story is that it is easy to understand and has a clear deliverable. It should be obvious when a User Story is done or not, plain and simple. An example User Story would be:
"As a User, I want to login to the website."

The strength of Agile is that non-technologists are not required to understand the solution. Software Developers are the implementers of customer ideas, and they understand that with a well written User Story, they are expected to design, develop and deliver the solution. Our strength is we hire experienced people skilled in building software. Our resources have done this many times before, and know what pitfalls to avoid. Using a highly collaborative process our staff and our customers work together to define the User Stories, address all expectations, uncover all assumptions and note everything in the Master Product Backlog.

From here, customers will have a clearer understanding of the work required, and will begin the prioritization process. A cornerstone of Agile is to build a feature when it's needed, not when it's wanted or "discovered". This focus, and the explicit exercise of prioritizing User Stories, makes sure that only the highest priority tasks are tackled.

Once we have a prioritized list of User Stories from our customer we generate a Timings Estimate. Timings Estimates capture all the underlying activities required to meet the objectives of each user story. We start with the highest priority stories and identify all web pages, business objects, database schema changes, application code etc... etc... that needs to be developed. For each of these, we assign an estimate and assess our level of confidence in our estimate. Fairly quickly we start to get an idea of the amount of time and resources that will be needed to complete each user story. At some point in this process a logical feature set for our customer emerges. The feature set is what we call a Sprint, and it's a set of user stories that form a logical group of application features. A Sprint may be a week, a month or more, and generally constitutes a release. Our development process is comprised of many, many Sprints where we're releasing production ready software to our customer. Sprint by Sprint, the complete product takes form.

The benefit of this process is three-fold.

First, our customers do not need to wait to see all Sprints completed to see their product. Every Sprint gives them an opportunity to incrementally see their product evolve. The major advantage of such an iterative process is that things change, and if their needs or priorities change, so can our next Sprint.

The second advantage is that the end of a Sprint is not the first time our customers get to see their product. We integrate Quality Assurance into our software development process, and per-customer extranets so our customers can navigate their application on our hosted QA environments in real-time. Feature by feature, Sprint by Sprint, our customers participate in our development process.

Third, no more surprises. Visibility into what we're developing is just the beginning. We also use sophisticated tracking methods to make sure we're on-schedule. Work performed to-date is tracked against work remaining so we always know what our time horizon is. We really don't like surprises, and neither do our customers, so we work hard to make sure we're measuring and managing our progress throughout.

Ready to build something new? Contact us!