Project on-boarding is key to success
Step two is always a question mark. It’s one of my favorite meme’s on the internet. Some joker on a message board will say they have a great idea, and their business plan usually goes something like the image on the left.
It’s a light hearted way to poke fun at other people on the internet when they act like they have a great idea that will make them millions, but no idea of how to implement it. Or this meme is used when you want to mock someone else when they clearly have a hare-brained idea.
Coming up with ideas is easy. I have a folder full of them on my laptop. I’m not saying they are all profitable ideas, but if you pay attention to the world around you then coming up with ideas is the easy part.
Step 2 is the hard part.
How do you take that great idea and make a profit with it?
This is the part where companies like AgilityFeat make a big difference. You probably have the idea, and you may have a good plan to make it profitable, but you need someone to implement it for you. And you are probably looking at outsourcing the implementation of this idea because it’s not your goal to become a software development company. You just need us to design and develop your product so that it will turn a profit.
Don’t miss the big picture
The problem with our process to-date at AgilityFeat is that we’ve realized we were paying too much attention to the day-to-day part of our agile process (stand ups, planning sessions, demos, retrospectives, etc), but not enough attention to the kick-off process.
One of our current customers helped highlight this problem to me last year when he said that “You guys have missed part of the big picture of why we are doing this.” That hurt a little bit, but I’m really glad he said it.
When we gathered our team in Tamarindo Costa Rica for our DareToBeLean workshop, fixing this on boarding problem was one of our main goals.
For us, Step 2 of making a profit really has a couple of sub-parts. We’re getting the 2nd half right. It was the first part that needed some help, where we make sure the whole team understands the customer’s needs. It’s not good enough to be really efficient at building the wrong thing!
Our process for new projects
We spent some time drawing out what an agile on-boarding process looks like for us. Here’s the sketch we made on a white board, which like all good processes ends in profit: for us and for our customers.
After we revised and agreed on the sketch, the whole team signed it. That’s not to indicate that this is set in stone however. Like all good processes, we expect this one to change and adapt over time as we continue to improve. But this is an excellent start.
Here’s a walk through of our new project on-boarding process…
Sales process
During this pre-project phase, generally just the AgilityFeat executive leadership is involved. Either myself (Arin), David, or Ford probably brought in the project as a lead, and once it seems to be a “warm lead” we will let the others know about it and decide if it’s a potentially good project for us.
As part of this vetting process, we are interviewing the client as much as they are interviewing us. We want to know that it’s a good fit for us technically, financially, and contractually. Ford, David and I comparing the prospect to our typical customer segments. This segmentation drives how we will structure and price the project.
Once we have a contract in place, we move onto the kickoff process…
Kickoff process
The goals of the kickoff process are twofold:
1) Build the Team
2) Build Confidence with the Client
The kickoff process is where we start to bring in other members of the AgilityFeat team. Mariana, Gabriel, or Daniel might start to look at the project from a User Experience, Visual Design, or Marketing/Branding perspective. David or I might start to look at the client’s existing code or technical architecture along with one of our senior developers.
The key thing in this kickoff process is knowledge transfer. Up to this point, Ford, David, or I have been the only ones talking to the client. Even among the three of us, it’s probably just one of us who has been responsible for nurturing that prospect into a customer.
Now we have to start transferring that knowledge to the rest of the team, as well as validating to the client that we understood their needs. This is one are we agreed that we have fallen short in the past.
To build confidence with the client, we validate our understanding of the project through a lightweight Agile Project Charter. This document is based on interviews with the client to make sure we understand the true pain point that is being solved.
The document must be lightweight and to the point – this document only serves as a way to validate conversation and in itself delivers no other value. The point is to get to writing code very soon.
An Agile Project Charter
In our Agile Project Charter, we focus on these areas:
1) Restating the client’s goals for this project, and the pain point that we are trying to solve
2) Stating the biggest technical risks that need to be addressed (this could affect how we staff the project, or it could address which features we need to work on first)
3) Stating the biggest business risks that need to be addressed (this is basically the first round of a lean startup process. What assumptions have been made about their customers or the product? What can we do to validate those assumptions, and then quickly test proposed solutions?)
4) What constraint is most important in this project? In any project, the contractor and the client have to balance three things: Budget, Scope, and Timelines. We validate with the customer which one of these things is most important, and cannot be violated. There can only be one answer, because the other two may have to adjust to accommodate it. This decision is very important, because it guides how the contract is structured and will help us to know what the most important success criteria is for this project.
Sprint 0
At the end of the kickoff phase (which can be anywhere from a couple days to a few weeks depending on the project), we are ready to move into Sprint 0.
Agile teams work in time-boxed iterations called “Sprints”, which are typically 2-4 weeks in length. We actually prefer to work in very short 1-week sprints. This forces us to divide the work into smaller pieces and to demo to our customers more often, both of which are good things when dealing with startups and distributed teams.
Sprint 0 is an exception for us. In our experience this phase of work takes 2 weeks, but it positions us to work efficiently in 1 week sprints afterwards.
During Sprint 0 there are as many as 5 different things going on in parallel:
1. Epic Creation
The UX lead and/or the Scrummaster are working with the client to define the “Epics” to be worked on in this project. These are the high-level user stories, or feature descriptions, that the team needs to work on.
This is done in close coordination with the client because this list must be prioritized. By the end of Sprint 0 we should have a complete and prioritized list of Epics.
The highest priority epics on that list will also be broken down into smaller stories for the first development sprint.
2. Branding and Design Language
The Visual design lead is also preparing for the first round of development. We prefer for our developers to start each sprint with all the visual design artifacts that they need.
This includes mockups, cut up graphics, and often also the CSS/HTML layout. For that to happen, the UX and Design have to get ahead of the development team.
As part of those first designs and mockups, the Visual design lead is also working with the customer to come up with a consistent “look and feel”, or brand, to the website. Any logo and theme designs are worked on and approved with the customer during this phase.
3. Information Architecture
The UX lead(s) are also working on something called the “Information Architecture” for the application.
In traditional projects this can be a very laborious process, but we emphasize doing it in the most lightweight way possible.
This architecture will define the overall flow of the application, how users and data will traverse the system. This architecture is another way for us to confirm that we understand the customers’ needs, and it also serves as a guide to the upcoming design and development.
The Information Architecture is the “big picture” in flow chart form.
Based on the information architecture and the priority of epics and user stories, the wireframes for the first sprint of development will be created.
4. Walking Skeleton
Remember how in the project charter we identified the biggest technical risks to the project? These could be things like interacting with a client’s existing API’s, web services, or databases. It might be integration with a third party application.
The development team will identify a “thin vertical slice” of functionality with the customer that can be developed which will prove the project is technically feasible.
The end result of this is not something which is pretty or even usable by the end customer. But it shows that we know how to connect the key blocks together, and it also helps us get the technical plumbing in place for the actual development to start.
5. Testing Plan
Agile teams don’t create heavyweight testing plans or uber-detailed testing scripts.
But nonetheless we do need to identify the main functionality to be tested.
Our testers will be going over the user stories and epics as they are created, and will begin to do some lightweight and part-time planning for how to test the code.
Co-located or virtual?
Most of the AgilityFeat team is in Costa Rica. Most of our clients are in the US. And the vast majority of our projects will be conducted virtually. The Sprint 0 phase is an ideal time to get at least part of the team together.
The client can come visit us in Costa Rica for a week or two, or we can send one or two team members up to the client’s location.
Either way, we find this to be invaluable and a strong predictor of project success. The chance to get to know the team in person, build up personal relationships, and have very efficient conversations about the project vision is well worth the cost of a couple airline tickets.
We’ll be glad to make sure you see some of the beauty and “pura vida” of Costa Rica while you’re here!
Estamos Listos – “We are ready!”
At the end of this two-week Sprint 0, the team has a solid understanding of the project and how our customer is going to judge if we’ve been successful.
We have a common vision, we’ve built the team, we’ve prepared the first wireframes and created a product backlog of epics and user stories. We’re now ready to start running short agile sprints or lots of lean startup experiments for your product.
What are you waiting for? Let’s jump into “Step 2” and kick this project off!
