![\"Step2\"](\"https:\/\/agilityfeat.com\/wp-content\/uploads\/2013\/02\/Step2.png\")
<\/a>Step two is always a question mark. It\u2019s one of my favorite meme\u2019s 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.<\/p>\nIt\u2019s 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.<\/p>\n
Coming up with ideas is easy.<\/strong> I have a folder full of them on my laptop. I\u2019m 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.<\/p>\n How do you take that great idea and make a profit with it?<\/strong><\/p>\n 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\u2019s 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.<\/p>\n One of our current customers helped highlight this problem to me last year when he said that \u201cYou guys have missed part of the big picture of why we are doing this.\u201d<\/em> That hurt a little bit, but I\u2019m really glad he said it.<\/p>\n When we gathered our team in Tamarindo Costa Rica for our DareToBeLean<\/a> workshop, fixing this on boarding problem was one of our main goals.<\/p>\n For us, Step 2 of making a profit really has a couple of sub-parts. We\u2019re getting the 2nd half right. It was the first part that needed some help, where we make sure the whole team understands the customer\u2019s needs. It\u2019s not good enough to be really efficient at building the wrong thing!<\/strong><\/p>\n After we revised and agreed on the sketch, the whole team signed it. That\u2019s 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.<\/p>\n Here\u2019s a walk through of our new project on-boarding process\u2026<\/p>\n 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 \u201cwarm lead\u201d we will let the others know about it and decide if it\u2019s a potentially good project for us.<\/p>\n As part of this vetting process, we are interviewing the client as much as they are interviewing us.<\/strong> We want to know that it\u2019s 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.<\/p>\n Once we have a contract in place, we move onto the kickoff process\u2026<\/p>\n The goals of the kickoff process are twofold: 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\u2019s existing code or technical architecture along with one of our senior developers.<\/p>\n The key thing in this kickoff process is knowledge transfer.<\/strong> Up to this point, Ford, David, or I have been the only ones talking to the client. Even among the three of us, it\u2019s probably just one of us who has been responsible for nurturing that prospect into a customer.<\/p>\n 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.<\/p>\n To build confidence with the client, we validate our understanding of the project through a lightweight Agile Project Charter.<\/strong> This document is based on interviews with the client to make sure we understand the true pain point that is being solved.<\/p>\n The document must be lightweight<\/strong> and to the point \u2013 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.<\/p>\n 1) Restating the client\u2019s goals<\/strong> for this project, and the pain point that we are trying to solve<\/p>\n 2) Stating the biggest technical risks<\/strong> 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)<\/p>\n 3) Stating the biggest business risks<\/strong> 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?)<\/p>\n 4) What constraint is most important in this project?<\/strong> 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.<\/p>\n 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.<\/p>\n Agile teams work in time-boxed iterations called \u201cSprints\u201d, 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.<\/p>\n 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.<\/strong><\/p>\n During Sprint 0 there are as many as 5 different things going on in parallel:<\/strong><\/p>\n 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.<\/p>\n The highest priority epics on that list will also be broken down into smaller stories for the first development sprint.<\/p>\n 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.<\/p>\n As part of those first designs and mockups, the Visual design lead is also working with the customer to come up with a consistent \u201clook and feel\u201d, or brand, to the website. Any logo and theme designs are worked on and approved with the customer during this phase.<\/p>\n In traditional projects this can be a very laborious process, but we emphasize doing it in the most lightweight way possible.<\/p>\n 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\u2019 needs, and it also serves as a guide to the upcoming design and development.<\/p>\n The Information Architecture is the \u201cbig picture\u201d in flow chart form.<\/strong><\/p>\n Based on the information architecture and the priority of epics and user stories, the wireframes for the first sprint of development will be created.<\/p>\n The development team will identify a \u201cthin vertical slice\u201d of functionality with the customer that can be developed which will prove the project is technically feasible.<\/p>\n 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<\/strong>, and it also helps us get the technical plumbing in place for the actual development to start.<\/p>\n But nonetheless we do need to identify the main functionality to be tested.<\/p>\n 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.<\/p>\n 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.<\/strong><\/p>\n 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\u2019s location.<\/p>\nStep 2 is the hard part.<\/h2>\n
Don\u2019t miss the big picture<\/h2>\n
<\/a>The problem with our process to-date at AgilityFeat is that we\u2019ve 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.<\/strong><\/p>\nOur process for new projects<\/h2>\n
<\/a>We spent some time drawing out what an agile on-boarding process looks like for us. Here\u2019s the sketch we made on a white board, which like all good processes ends in profit: for us and for our customers.<\/p>\nSales process<\/h2>\n
Kickoff process<\/h2>\n
<\/a><\/p>\n
\n1) Build the Team<\/strong>
\n 2) Build Confidence with the Client<\/strong><\/p>\nAn Agile Project Charter<\/h2>\n
<\/a>In our Agile Project Charter, we focus on these areas:<\/p>\nSprint 0<\/h2>\n
1. Epic Creation<\/h2>\n
<\/a>The UX lead and\/or the Scrummaster are working with the client to define the \u201cEpics\u201d to be worked on in this project. These are the high-level user stories, or feature descriptions, that the team needs to work on.<\/p>\n2. Branding and Design Language<\/h2>\n
<\/a>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.<\/p>\n3. Information Architecture<\/h2>\n
<\/a>The UX lead(s) are also working on something called the \u201cInformation Architecture\u201d for the application.<\/p>\n4. Walking Skeleton<\/h2>\n
<\/a>Remember how in the project charter we identified the biggest technical risks to the project?\u00a0These could be things like interacting with a client\u2019s existing API\u2019s, web services, or databases. It might be integration with a third party application.<\/p>\n5. Testing Plan<\/h2>\n
<\/a>Agile teams don\u2019t create heavyweight testing plans or uber-detailed testing scripts.<\/p>\nCo-located or virtual?<\/h2>\n