Agile Software Development

People who study processes know that you need a tight feedback loop to have a good process. Unfortunately the software industry has created much of its processes based on antiquated ideas of how to build software based on procedural thinking. To top that off, many “geeks” don't know how to communicate. Our object-oriented thinkers use the leading agile development methods, including eXtreme Programming (XP), to create lean, adaptable software. Our process is built around industry best practices that we have been pushing the envelope on for years. The results are refreshing. From the first week you engage with us, you'll have visibility into the progress with live working software. Tight feedback. No surprises. We help manage your software budget.

Gathering Requirements

We begin our project engagement by understanding your business and its objectives. We don't expect you to have detailed specifications, though we are glad to take these as input if you have them, knowing that they will change for all sorts of reasons. If all you have is a vague idea and want us to turn it into a working specification, we're happy to do that, too. Often, we'll sketch things out on paper or a whiteboard, or even build something before your eyes.

Our initial meeting(s) are used to figure out your desires and your risks, as well as your expected budget. We then bring this together to propose one or more options as to how we can engage. Typically, we'll outline a phased approach with clearly stated goals for each phase and budget parameters.

Iterative Development

We break the project into short iterations, tackling high-priority items first. This is highly visible to our clients. At the beginning of each iteration we identify ways to test whether goals are reached. Whenever possible, we write those tests in an executable (or potentially executable) form before we start crafting the software. Yes, we write tests before crafting the software. From that point forward, our goal is simple: deliver high-quality, streamlined and adaptable software that meets the requirements necessary to pass each test. We continue this cycle, maintaining open communications until all objectives are met. This allows us to build quality code, with a focus on functionality rather than fixing bugs.

What we do inside the iterations is typically less visible (though we have nothing to hide). We rely on the same principle of tight feedback to ensure quality all the way, working in pairs for more challenging pieces or where two parts of the system interact.s

Building the Right Team for Each Client Engagement

Once we understand your needs, we put together a plan which includes determining what the team should look like at various parts in the plan. It never ceases to amaze us how many people speak about software projects as if they have to have a large team of people who are dedicated to a specific role, or how there is a specific order of steps that must be followed. The reality is that each software project has its unique needs. Sometimes, user experience design is paramount and has many challenges. Other times, the user interface is trivial. Often a project is database intensive, but not always. Sometimes the volume of work requires a large team and a lot of coordination, but other projects are best tackled by one or two craftsmen with minimal communication overhead.

No matter what your needs, chances are that our Software Craftsteam™ has all the skills necessary. We have enough experience to know how to assemble a team that will deliver. Typically, that will have some core team members dedicated to a project and others that are brought on to tackle specific challenges, some which are predictable and some which are not.

We do our work in a highly-collaborative environment, so we're rarely held up by a technical challenge for very long.

Client Engagement

Our clients can participate as much or as little as they'd like... within reason. We have some clients who have a rich set of skills (such as user interaction design) that can contribute on a daily basis, and others who have never been a part of software development before, and don't want to be involved on a daily basis. We welcome either case.

We insist, however, that our clients do two things:

• Look at what we are producing on a regular basis to validate that we are building what they expect
• Be available on a predictable basis to answer questions that only they (or someone who works with them) can answer, so we can continue to deliver what they expect

Choosing the Right Tools for the Job

We use open source software tools whenever it makes sense to do so. These days, that is very frequently. When build vs. buy (or build vs. try) decisions come up, we typically include our clients in the process of making the decision as much as they would like to be. Our favorite tool for web applications is Rails, and we have found it is usually the most cost-effective choice, especially in the hands of skilled craftsmen. We have built many applications using Java and other tools such as Microsoft's .NET line of products. Martin Fowler's report on Ruby at ThoughtWorks resonates with our experience that it is typically twice as productive as other development environments such as Java and .NET, with many other benefits. But there are times when .NET or J2EE is a better solution. There are times when FLEX is the appropriate choice, or other tools depending upon the specifics of the domain and the expected platform of the end users.

As you will see in browsing the skills of our people, we've worked with many databases, languages, design tools, and deployment platforms.

More About Our Process(es)

There are books written about the processes we follow, and we've even written some of them. As alluded to above, we employ the best people and best processes available, depending on what we are being asked to do. We can provide many pointers, upon request.

The bottom line is that we are continuously pushing the envelope to be as lean as possible, providing the highest possible value with the lowest possible waste. Software is generally a process of continuous discovery. (That is not to be confused with continuous wild guesses). We quickly produce working software in a form that allows us to gather feedback that gets incorporated into whatever we build next to provide the highest quality software in the shortest amount of time.