Agile Development
Agile is a loaded term, frequently confused and abused by many. For us, it is a state of mind and can be summed up simply as:
- Doing the best things possible to reach your development goals given the resources and constraints you have.
- Being nimble and being able to move quickly and easily.
We break down our Agile techniques in a simple manner, tailoring it as we go based on our client’s needs and each unique engagement. A typical project might look something like this:
- Requirements Workshop
- Technical Workshop
- Release Planning
- Iteration Development
Requirements Workshop
You do not need to gather all of the requirements in the first go. That is, we do not need volumes of written requirements to start. We need to have enough information to make an initial stab at what the basic application needs to be, how we might architect it, and approximately what season it might be near completion (given a certain team size and make-up). Usually, the business wants a ballpark cost estimate, or wants to know what can be done for a specific budget.
Technical Workshop
Many times, there are a external systems that we have to integrate with, so we need to have an opportunity to factor in these external influencers. We also use this time to put forth potential architectural solutions. The technical team meets to hash out various ideas, ultimately producing a working thin slice to represent the design.
In some cases, we have assigned a core team to explicityle investigate the architecture to ensure we can meet the needs of the business. For example, sometimes we may need to accommodate high throughput or large numbers of concurrent users. If there are any such technical challenges, we hit them right up front to ensure we don’t get surprised downstream.
Release Planning
For the initial “Phase 0” or “Release Planning” effort, we want to arrive at enough of a plan to give the business some idea as to the approximate schedule and cost for what the business wants built. Normally, we use this up-front planning time to iterate with the business on just what will constitute a good first product release. That is, the business might have some ideas for features that cost more than they are worth. Conversely, the development team might have an approach in mind that makes other business value attainable. The point is that we like to work at a “level up” from the intended product. To understand the business environment and drivers surrounding the specific project is invaluable. This often allows us to come up with spectacular game-changing solutions because we aren’t simply boxed in with an a priori idea of product shape (which naturally was formed within a set context).
We also let the business know that this is an “early-stage” plan, that we will continuously update with each iteration. Progress will be very visible to all participants throughout, allowing for adjustments along the way.
Iteration Development
Whether every two weeks, three weeks, or once a month… the development team will peel off a set of tasks from the top of the Release Plan based on the latest business priorities. These tasks are then re-evaluated by the developers, discussions with the business happen as required, and deeper sets of subtasks are created to enable the development team to begin.
There is a balancing act between what the business hopes to have done in a given iteration, and what the Dev team says they can accomplish. So, at the outset of the planning process, the Business is armed with their set of priorities, and the deveopers seek to understand.
The business helps to define the functional behavior (a.k.a. Acceptance Tests), and the developers write code to satisfy those behaviors, with tests in between the two. Business and QA and development all work together to ensure the most effective delivery of well-tested features as possible.
Deployment
Early on, we will establish an infrastructure that automates deployment and relies on Continuous Integration. We typically set up a Test environment that mimics the Production environment.