Customers are always asking “how will you get our project done, what is your approach?” In truth, it very often has to do with intangibles like our flexibility and desire to make the customer successful, but a decent methodology doesn't hurt.
The Principals
Agile Development is a term that gets tossed around quite a bit these days. What does it really mean? At its core, Agile Development is based on 4 key principals.
Individuals and interactions over processes and tools
The most important component of any application is the user and this principle is about keeping the communication open between all parties. With open communication we can focus on the strengths of each individual and reduce the time and cost of making an application available.
Working software over comprehensive documentation
Ever feel like you spend more time writing designs, specifications, requirements and who knows what other documents than you do seeing your project get developed? We know this feeling and actively strive to keep the scale of our documentation in check. We know that once all that documentation is produced it ages quickly and is soon out of date. So what do we do? We focus on getting to a running application that will perform in the traditional role of documentation as the communication basis for interacting with our team. The clients see the running application and can visualize the incremental change to the next features. The developers can see the code for the running application and easily meet the client’s requests for change.
Customer collaboration over contract negotiation
Contracts are important but we believe that contracts and software requirements have no business being in the same document. Our contracts define the relationship we want with our clients. From there, we use manageable Statements of Work to agree on what the next iterations will consist of. These SoW's make working with our clients easy by ensuring the current work is on task and relevant. After all the customer is the only one who can tells us what the application needs to do and that needs to be flexible.
Responding to change over following a plan
Client requirements change fast, usually faster than it takes to build them. Because of this pace, detailed specifications and development plans are often outdated after only three months. By keeping the iterations small, we focus on the immediate needs of our clients. When changes come up, they are incorporated based on the client’s priorities and business needs not where they fit in a dated "master plan". Just like documentation, plans can get out of date quickly.
The Approach
Guided by the agile principals, Xcarab takes the following approach to each project
Build the Team
We start each project by putting together the team of individuals both from the client side and ours. Not just the decision makers per se, but also those people who will be using what it is we are building.
User Stories
This is where most of the magic happens. The team gets together and simply talks about what they want the application to do. We talk about things from nuts and bolts all the way to blue sky, but it's our skill in listening that gets us narrowed down to the bits of work we call "User Stories". Now here’s the secret, success in a project is all about right-sizing these bits of work. If these bits are too big, not everyone can grasp the impact. If they are too small, some detail of the functionality might have been missed. Getting them just right means, both us and the client can see the evolution of the project happening in near real-time.
Short Iterative Cycles
We strive to deliver working software every 1-2 weeks. We take the User Stories the client has decided upon for the current cycle and get them done and get the working code into the client’s hands.
Acceptance Test
It doesn't work until the client says it works. Sometimes acceptance is an automated script running on some server somewhere, sometimes it is "The Demo" in front of the CEO and board members. In either case, Acceptance is defined by the client. What does that definition look like? The result of the iteration is the culmination of the User Stories already worked out by the team before the iteration even started. We use actual development to evaluate and improve the design as the project progresses. This means we can eliminate unnecessary steps or features and identify gaps early in the process, dramatically reducing overall cost.
Repeat.
Now that the loop is in place we go back to more user stories and do the whole thing over again.
The Result
This process allows us to react quickly to our customers needs.
Rapid Development and Deployment
Getting our customers involved in the process early helps us keep the project on track and makes sure the effort is always supporting the company's vision. With iterative cycles and rapid development we work to expose the foundational framework of even the largest projects to our customer as soon as we can. This way our customer is part of each build and release and is actively involved in the project. In a sense we pull back the curtain on development and encourage the customer to participate and comment on the whole process.