“How do we get started?” This is a question we hear from clients all the time, often it’s the first question they ask after signing a contract. Most clients are familiar with the concepts of Agile at that point, including the processes and artifacts that will make a project a success but they are stuck wondering what to do first. At AgilityFeat, we utilize a two step process, the Kick-off and Sprint Zero to ensure that our projects get off to the right start.
The Kick-off
The first step of getting started on a project is what we call the Kick-off. The primary purposes of the Kick-off are to build trust and to transfer knowledge. Up until the Kick-off meeting, the client has likely only met with a small group of the AgilityFeat team (and possibly just the person who brought the client in). The length of the Kick-off can be as short as a few meetings over a couple of days and as long as a week. During this time, we’re working to develop trust by exploring and validating the project’s objectives. Specifically, we want to develop a very lightweight document that states;
- The Client’s Goals- what is the purpose of the project, what are we trying to solve or enable for the client?
- Stating the biggest technical risks- what technology challenges do we need to overcome for the project (see more below)?
- Stating the biggest business risks- what are the assumptions that have been made about the project, have they been validated and how and if they have not been validated, how can we validate them?
Sprint Zero
The concept of Sprint Zero is a controversial one in the Agile world. Some practitioners define Sprint Zero as a time for team building where physical spaces are put together (not important at AgilityFeat as our team works in a distributed fashion) while others define Sprint Zero as a time to define the user stories and estimate. Some critics of Sprint Zero rightfully claim that the team’s often spend so much time planning and validating in Sprint Zero that the project falls victim to BDF (Big Design Upfront). As such, we have evolved our thinking over time to define Sprint Zero in the following 4 Activities and deliverables (happening in parallel through Sprint Zero);
- Epic Creation- Once the knowledge sharing from the client has occurred, the product owner (client designated), scrum master and UX lead work to loosely define the Epic or high level features for the project. The Epic may include some initial user stories that make up the epic but definition is very light at this point.
- Branding and Visual Design- Some projects can skip this step or modify it to be very light if there is an existing set of brand guidelines for a project. If not, our designer will work with the client to start to define the visual language for the project (colors, logo etc).
- Information Architecture- Based on the Kick-off meeting(s) and follow-on interviews with the client and customers, our UX lead will build a document (usually a flow chart) to map out the way users and data will flow in the application. This document, along with the Epics for the project enable the UX lead to create the wireframes for the first few user-stories in the product backlog.
- Walking Skeleton- We’ve talked about project management, design and ux. So what are the developers doing? Our development team will build a functional but barely functional (read: very ugly) walking skeleton that proves that the project can be technically achieved. In this phase, the developers are connecting to the required data sources for a project (APIs, internal dbs etc) and prove that we can connect all of the necessary building blocks for the project. One good way to think about the Walking Skeleton is to imagine the technical plumbing of a project being established so that the connection framework for building out the project exists once we start working on user stories in the backlog.
All of this points towards having everything in place to start working on the backlog at the end of Sprint Zero. What makes our process a little different is that we will show working code (for the Walking Skeleton) at the end of Sprint Zero. By focusing on the biggest technical risks up front and proving a thin, vertical slice of functionality across the entire application, we not only address this biggest technical challenges for the project, but we demo working software to the client in Sprint Zero. This goes a long way to establishing trust while also getting all of the players on the team working together.
Have more questions or suggestions about starting a project with AgilityFeat. Drop me a line!
