Singlebrook is agile! We prefer to use an agile web development process whenever possible. It's a well-designed, flexible and efficient method that results in reliable, scalable and powerful web software. The agile method involves a lot of collaboration, and we often work in small teams to take advantage of the breadth of knowledge, experience and ideas from our different developers. Clients are involved in the process every step of the way to ensure that the application is meeting your needs. You’ll be able to use the site as early as two weeks into the development process, which allows you to give us early feedback and verify that we’re building the right solution for your needs. Agile development makes it easy to incorporate changes to a project midstream if your requirements or ideas move in a different direction. This flexibility is a key benefit!
Learn more about the agile process here.
Another method of developing software is known as the "waterfall" method. In it, each step is completed and then leads to the next: Requirements Gathering, Functional Specification, Design, Coding, Testing & Maintenance. With agile, we maintain greater flexibility by going through the steps in the waterfall method in a more iterative fashion with the project broken down into smaller pieces.
We use a web-based tool called Tracker to manage our projects. We will help orient you in how to use Tracker to help manage your project. Using this tool to collaborate with us results in a more efficient and more inexpensive process.
It's important to acknowledge at the beginning of a project that changes will happen throughout the process. Agile is a system for acknowledging that change is the norm, not the exception. Effectively managing change is the key to a successful project. For this reason, estimates start out broad and general and get more detailed and specific as the project progresses and as everyone's collective knowledge of the project is greater. If you spend a lot of time on very specific and detailed planning at the beginning of the project, then when things inevitably change, all that planning time has been wasted. It's more efficient to plan generally at first and do the more specific detailed work at the appropriate time, when you're tackling those features. We work in iterations and find that planning in increments results in better efficiency and accuracy.
Agile theory acknowledges that it is impossible to know everything there is to know about a project before you've even started it. The original estimate for a project is always just a broad starting place that includes the user stories that the client and developers think will be needed for the project. Inevitably, there will be additional user stories, chores and bugs that will be added throughout the course of the project by both the client and the developers. This can happen for a number of reasons including: 3rd party integration issues, technical debt on legacy code, unanticipated chores and bugs, additional necessary functionality that wasn't anticipated during the original estimating process, changes requested by beta testers and early product adopters, and more.
We send weekly status reports and have regular check in meetings that provide opportunities to review the budget and timeline and estimate and prioritize features for the next iteration. When user stories get added to a project, it often affects the budget and timeline. The client can decide on an ongoing basis whether or not to approve the budget and timeline changes resulting from the additional stories, or you can choose to eliminate or de-prioritize other stories by moving them back to the "icebox" in Pivotal Tracker. The lead developer, project team, and client all review the project status and can flag and discuss any questions or concerns.
The client should be in regular contact with their lead developer and respond to requests for approval of changes in a timely manner so the project is not delayed. Prompt approvals are key to keeping the project on track. If a client is out of town and can't monitor communication from the project team, they should provide another contact or communicate with their lead developer to work out an alternate plan.
When presented with changes in estimates or budget, you have three choices, known as CAPE:
- Choose to Approve the additional work and increase your budget.
- Postpone the additional work by putting it in the icebox and approving it later when you’re ready to increase your budget.
- Exchange the additional work for other items that have the same point value and keep your budget the same.