Our Process
Our goal at RAC is to give clients the best possible product within their specified timeframe. To do that, we team up the best coders worldwide and empower them to code as fast as possible by putting decisions in their hands.
When you work with RAC, you get three things:
- Good communication
- Technological expertise
- Speedy work
A dedicated project manager liaises with each client, explaining to you the technical details and relaying your needs to the development team. This provides for fast, frequent communication and fewer misunderstandings.
After an initial consultation to learn exactly what clients need and want from their project, our team gets right to work. Because we use an Agile methodology for development, we start coding immediately. We engage in a constant review cycle to keep on track, but we don’t need weeks to analyze requirements before ramping up.
Our teams work in “sprints.” Just like in running, a coding sprint is a short, fast burst of development. RAC sprints are one to two weeks in length, and they let coders work as fast as they can until the sprint is over. Then, coders take a break and review their performance.
How do sprints save you money? With RAC, you pay by the sprint rather than by the project. Assess our work after each sprint. Modify requirements along the way to stay within budget and on time.
Contact us to discuss how RAC’s process can help you reach your business goals!
One of the many ways that RAC achieves higher velocity development than the competition is to eliminate the bureaucracy and redundancy that cripples the typical development process. Our agile development methodology compacts the 'analyze, design, build, test' process down to a size that can be repeated many times throughout development, as opposed to just once. This compressed process allows the RAC team to get down to coding faster than the competition. While traditional teams are still talking, in general terms, about requirements and design scenarios, the RAC team is building real functionality so that users can decide what's really required. This not only allows us to have many more iterations, feedback points, and testing sessions, but it gives the ability to dive right in and start problem solving. There are only two ways to solve problems: 1) to talk about solving them 2) to begin solving them. The sooner you get to the second, the better. We happen to start there.
Short releases win. At RAC, we've been around the block enough to know that the longer the 'release-cycle,' the more risk there is that the development team is falling out of alignment with the product owners. Further, the longer the release-cycle, the fewer times that a product can receive REAL user feedback before being launched to the public. As such, we've built our development methodology around 'bite-sized chunks of functionality' and maximizing the number of releases before a potential piece of software is launched. Further, we don't presume that we're going to predict the best possible usability and use case scenarios. So we aim to get feedback and guidance from real users and product stakeholders early and often. With this strategy, not only do we show more progress along the way, but we launch products that are already proven in the user community.
Open Communication drives happiness. Happiness drives results.
There are two ways to communicate with a development team:
Our team believes firmly in the second. Happy clients are ones that are kept in the loop on the progress of development. Happy clients have properly set expectations. Happy clients are probed for their opinions when developers are confused and need guidance. Happy clients make good decisions, and lead projects effectively.
But this isn't a one way street. Happy developers have a clear sense of what clients are looking for. Happy developers can ask questions whenever they want, without having to feel intimidated. Happy developers know that their technical recommendations are heard. Happy developers write good code, and work harder to get things done.
Happy developers and happy clients come together to make successful projects.
Around the clock work enables very high velocity
The more people there are on a project, the more overhead there is that needs to be managed. Having more developers does not necessarily mean faster results (it often doesn't). Why? Because more people have to be involved in every little decision, and more code needs to be integrated and tested, and tasks need to be managed much more carefully.
A simple thought experiment proves this concept further: Say you have an 8,000 hour project that takes one developer 1000 days to complete. You decide to crash the timeline by adding two more developers. Now you have three developers, completing the project in 333 days. Well, why stop there? Why not go up to six developers, and drop the timeline to 151.5 days? Might as well keep going, and go up to 10 developers and do it in 100 days. How about 20 developers, getting the whole thing done in 50 days. How about 40 developers, doing it in 25 days? Eighty developers in 12.5 days? Better yet, 160 developers in 6.25 days!
The idea of cranking up the development team to 160 people, and getting the entire project done in less than a week is completely unrealistic, and most of us know this intrinsically just at hearing the concept.
RAC enables many of the advantages of adding more developers to a project without the disadvantages associated with having people working at the same time. Our team is global, and as such, we are able to work around the clock. Instead of having 9 developers butting heads for 8 hours a day, we can have 3 sets of 3 developers, each working a different shift, being more productive in smaller teams.
Those of use that know software development best know that it can be described in one powerfully simple word: unpredictable. Software development is a complex pursuit that requires discipline, teamwork, and lots of effective communication to get done right.
Here at RAC, we refer to the unpredictable nature of software development as the 'iceberg' principle. An iceberg is a strong parallel to the development process because so much of development lies below the surface. When approaching a new project, all we can see is the tip of the iceberg. We can't truly see all of the complexities, use cases, and requirements of the software until we have truly taken the plunge into the project.
The traditional 'corporate view' of teamwork is not what we at RAC call real teamwork. Dividing tasks among a number of people and getting them done in parallel is simply 'divide and conquer' management. This 'multi-threaded process' of getting things done is great for CPU's and other mechanical systems, but humans are much more complex.
The best outcomes are sought through the collision of different points of view. That's why we here at RAC focus on continuous teamwork and communication in our development and design teams. Further, that's why there are no silos here. Our teams are cross-functional, and have everything they need to see a project through to completion. That includes an 'open-door' to our clients. We don't believe in shielding the people who are actually getting things done from the people who are making on-the-fly decisions.
Most importantly, RAC team members are empowered to make decisions and to get things done without the typical bureaucratic decision change. We believe that the best people, and thereby the best teams, can make great decisions on their own.
True innovation can't be attained with an inflexible process. Product visionaries, engineering teams, and marketing experts must be prepared to evolve their concepts, ideas, and scope. Most of the greatest innovations of our time turned out to be something very different (and much more useful) than what was originally intended.
RAC excels at innovation because our culture is deeply permeated with empowerment and agility. We know that ending up exactly where you set out to go is probably a bad thing, and our development processes are all built around accommodating change. That's why, when our clients ask to take a project in a different direction, we don't give them a hassle about a 'change order' or a 'contract breakage.' We evolve the software right along with the vision, to ensure that our clients can win in the marketplace. It's that attitude that's earned us our reputation in the marketplace as a leader in innovation.
Velocity matters (First to market wins)
RAC is no stranger to high-growth, high-innovation companies and products. These are the kinds of clients that seek us out, and this is the kind of work we get the most excited about. In our experience with working with such companies, we've seen the same truism time and time again in the web application development space: velocity matters.
Everyone in a high-growth business is dealing with an opportunity of some kind. And if you wait long enough, that opportunity will go away. We call this the 'innovation window.' Just about as soon as the innovation window opens, it begins to close. No space has a shorter window than Web 2.0.
The sooner our clients get to market, the higher the likelihood that they are going to succeed. That's why we take high-velocity development seriously. Our clients don't have time to wait for the typical delays and overages associated with software development, and we get that.
