We’ve designed our own flavor of the “agile” development process which enables us to better parallelize work to achieve aggressive timelines.

The traditional agile sprint methodology doesn't work for the velocity move. This is a situation that’s somewhat unique to a consultancy like ours, which implements repeatable solutions. Our team members are coming on and off of projects, or get blocked on tasks they are working on for other customers. When this happens, using our methodology they can easily pick up slack in other areas. In certain situations, we may tap members with specific specializations to work on a Sprint.

We define sprints in terms of effort (man-hours) of either 1 or 2 weeks (40 – 80 hours). Sprints do not necessarily correspond to a calendar week, but they do have a calendar due date. In a given week, one sprint is the priority which is the one with the nearest delivery date.

As part of our process, when we write a Statement of Work, we decide upfront the deliverables for a given sprint. When a sprint grows beyond what we think we can achieve in a fixed amount of time, we split it off into a new Sprint.

Every sprint is thematic; that is, it speaks to some greater, overarching goal or milestone with a clear set of deliverables. At any given time, we may have multiple people working on different parts of a project across multiple different sprints. However, since we sometimes have extra resources on hand, we can frontload work. This is especially valuable on sprints which may require more research or involve more interrupts.

We log detailed time entries against our time accounting software (Harvest) which has a project allocated for each Sprint that corresponds to a Kanban board. This ensures that we have proper time accounting and everything lines up business-wise.