Agile Development Process
We practice agile development methods because they work. In the rough and tumble world of custom software development, we need to be able to create software to support a business process that you just invented -- or that you're still inventing. Rapidly evolving product requirements of the internet age demand adaptive and flexible behaviors from development teams. We work to foster real and nearly real-time involvment between our developers and the client.
Nimble Development Teams
Our lead developers have worked together for over ten years, in different combinations and on different projects. Like many other lean, nimble teams, we've adapted to new technologies, and new paradigms several times. Along the way we noticed a pattern. High quality software which delivers real value to the customer tends to be created by teams that buck the established industry practice. Like other teams, we decided to revolt against long-cycle development.
We've been using our own Agile or "lightweight" development methodology since the early nineties, refining and adapting our management and development practices continually. Our motto was "Do The Right Thing", and pretty often that included throwing somebody's expensive methodology out the window, and working to implement practices that support efficient software development.
When other teams began formalizing and publishing their methodologies (Scrum, Crystal, XP) we adopted terminology from the Agile development movement, to bring our efforts into alignment with the emerging movement. We generally agree with the Agile Manifesto, crafted in the spring of 2001, by the Agile Alliance. It succinctly describes the core values of a nimble, productive development team.
Agile Practices
We employ a variety of Agile practices, which together give us the ability to respond quickly to your changing requirements, adding features according to your priorities, even if your priorities can't be predicted months or years in advance. These practices help us build and deliver software that's useful to you, early and often.
Frequent Opportunity for Customer Review
You get frequent opportunity for customer review, a transparent view into the development process -- and control over your project. We don't press a pen into your hand and make you swear that you know everything that will happen to your company in the next two years, and that you won't ever change your mind about anything you currently want or need. Instead, we deliver functioning software and new features on a regular and frequent basis. You get direct access to the development team working on your project, including email and phone contact information. You get a private customer area on our web site where all of your project materials are available -- including the latest build of your software.
Iterative Development ("Short Cycle Development")
Different projects have different natural rhythms, but we haven't found a project yet where the natural rhythm looked much like the typical 18 month waterfall project plan. Generally we deliver a proof of concept within three weeks of project start, by which time major components of the system architecture (database, framework, transports, interface platform) are identified and standing up together. After that, some iterations are as short as a day, some are as long as a few weeks, most are about a week.
Automated Unit Testing
All projects are instrumented with automated unit tests. These tests execute automatically during the build process, so that defects are detected and corrected as early in the development cycle as possible. We use popular, well-documented, and open source frameworks in support of that effort, including httpUnit, JUnit, and OCUnit. Your software is easier to maintain and enhance over the project lifecycle as a result.
Continuous Integration
All components required to produce a functioning product are archived, and delivered releases are tagged so that any given release can be reproduced at any time during the lifecycle of the project or product. The current product can be built at essentially any time, and may often be built several times each day during active development. This practice eliminates the overhead associated with the "integration" phase of typical waterfall projects, where weeks or months of overlapping coding efforts must be reconciled. As a result, the development team can turn on a dime. If your priorities change, it's often relatively easy to shuffle the features on deck to align with your new business needs.
Self-Organizing Teams
Everybody knows a story about three developers making a great product in their garage, or spare bedroom, that kicks the butt of some giant company -- and launches them off to success. Most of the large consulting companies find it difficult to employ the practice of self organizing teams, since "human resources" on a given project are allocated often times on the basis of availability or other arbitrary criteria. Unlike the large "body shops" we have the luxury employing only highly motivated developers (we won't have it any other way). Our developers help project managers allocate projects and tasks among themselves in various combinations, employing the principle of self-organization down to the task level. Very small teams can be remarkably productive this way -- it's basically the "three guys in a garage" story, formalized in a process. Self-organizing teams build better software than you can get from a team of random strangers, and they build it faster.
Pair Programming
This is a technique common among the Agile methodologies, where two developers work together at the same keyboard to implement a new feature in the software product, for example. It can result in better design, and fewer defects. We employ pair programming selectively, by task. We find that certain tasks benefit more than others from pair programming. (For the arm-chair methodologists reading this, we suspect that this may be an artifact of a tightly integrated team, where each member is familiar with the capabilities of the other members, skill sets are complementary, and tasks are often self-assigned. We suspect that as we grow, and add new developers to the mix, pair programming will prove to be more useful on a wider spectrum of development tasks.)
Integrated API Documentation
Every project is thoroughly documented using modern techniques and supporting tools like JavaDoc . The complete API documentation for your project can be viewed easily with a Web browser. This helps us during the development of your project, and it helps you if you want to move product maintenance in-house at some point during the project lifecycle.
|
