Our Discovery Process
We begin any substantial project with a discovery phase, the first step in the agile process we use. This is a quick exercise to define the problem, solution, and expected benefits so we can focus succeeding efforts. Once we understand the problem we perform a high level technical analysis to guide implementation.
A little time spent on discovery activities can save lots of time later in the project. The benefits include:
- Uncovering unknowns that could adversely affect the project
- Clarifying scope with prioritized requirements
- Establishing a clear understanding of desired benefits
- Building a working relationship between client and vendor
Our discovery process typically consists of the following phases.
Research
Discovery starts off with meetings, interviews, and data gathering. We will assemble and digest any available written materials, meet with and interview stakeholders, and work with the client to understand goals and requirements. We often include a site visit during which we hold a kickoff meeting with all stakeholders, plus other in-person meetings, interviews and brainstorming sessions. Examples of the types of information we collect include:
- Project goals and scope
- Functional requirements and priorities
- Expected usage and audiences
- Definitions of key project data and metadata
- Existing IT infrastructure
- Integration points with other systems
User Stories
The research phase results in a large amount of information which must be organized into a usable form. That usable form is a collection of user stories, the fundamental unit of development in an agile project. We work with the client to develop user stories that describe the functionality required for the new website or web application. In the process the client learns what makes a good user story, a skill they will use throughout the rest of the project. If the system we are developing will be complex, this is the time to bring in a user experience designer to ensure that the final system is easy to use.
After the user stories have been defined, the team of developers who will be working on the project will estimate them by playing "planning poker" - a consensus-based technique for estimating. Planning poker requires an extended discussion and Q&A session between the developers and the client. In the process the developers gain an understanding of the work to be done, and the client gains an understanding of the development tradeoffs - why some stories are easy and some are hard. Once the user stories are written and estimated, the client has the information they need to prioritize them. During the course of the project, stories may change and priorities may shift, but by organizing our work this way we are able to always be working on the highest priority items.
Technical Architecture
Informed by the information we have gathered, we will research alternatives and recommend a technical platform and system architecture that will meet site requirements. We will cover system components, system integration, content migration strategy, and hosting. Typical questions that would be addressed by the technical architecture might include:
- How Salesforce.com data will be synchronized with the website or web application
- What add-on packages will be used
- How to implement landing pages or other specialized layouts
- How to integrate a state of the art search engine such as Solr or Elasticsearch.
Plan and Schedule
When the technical architecture and user stories are complete, we will create a work plan for the project. This includes the schedule of development iterations, testing activities, data or content migration, and final deployment.