Agile for Startups
This article is part of a series which discusses the lessons we have learned while developing our startup. We hope that passing this knowledge onto you will accelerate your decision making process and provide insights into how other startups are tackling problems. The last two articles in this series can be found here:
Crushing Your Competition With No Money
Surprise! You have competition.hackernoon.com
In the startup world, there are endless ideas. Ideas are a dime a dozen. They matter very little when compared to the effort required to execute an idea. The execution aspect is often lost in the mix. This article focuses on a way to execute through an effective process. This process is agile.
The best process for a startup is one which allows for quick decisions, streamlined work flow, and consensus on how things should be done. As the business scales, it would also be convenient to have a process that can easily be reproduced for each new team. This allows for consistent execution with predictable results. A which point, translating goals into results simply becomes a logistical issue. Planning when to tackle different problems, lay out feature timelines, and expanding the team.
First, a quick story.
A few weeks ago, I got a message from a stranger on LinkedIn.
“Hi, I work for *****. Can we set up a call to discuss how I can help you meet your annual marketing goals?”
“No.”
“Don’t you have annual marketing goals you want to accomplish?”
No, we hardly have monthly marketing goals. We don’t think in terms of months or years, we think in terms of minutes and hours.
We don’t have time to make decisions on a year scale. It would be a massive waste of time and impossible to predict. Large corporations tend to misunderstand this notion. They are disconnected from the rapid pace that is required to remain competitive as a startup. The timescale of execution and planning is an order of magnitude smaller for us. Planning a year of marketing and development, then executing it to the letter is not an accomplishment, that’s a failed startup. The team needs to be constantly taking feedback, iterating on their ideas, and making better decisions based on new information.
Don’t run a startup like a corporation. It’s a startup. The only advantage you have is the ability to move fast and deliberately make decisions that quickly adjust your position.
How Agile Helps
Agile helps by framing important questions in a clear context. Once everyone on the team understands the format for answering these questions, the process becomes predictable and systematic. As long as each person follows the process, it’s easy to have a hands-off approach to development. The expectations are clear and the results are measurable. Examples of some questions agile answers are:
When should a task be done?
What is the priority of a task?
How does a task fit into the bigger picture?
Who should be doing this task?
The result is the ability to make quicker decisions, execute on a shorter time period, and incorporate short feedback loops. Instead of worrying about months or years of development, every problem is broken down into small shrimp sized bites. Every developer can then have a defined scope of work that they are required to complete on a specific timeline.
Without this context, schedules can drift wildly, miscommunication will arise throughout the team, and everyone becomes less effective at executing. That isn’t to say agile is the only way to help your team become a well oiled machine, but it’s the way we have found is best.
Mindset
In the corporate world, people despise the agile development cycle. Our team has experienced this first-hand at a number of large companies which use agile. It’s not enjoyable when everyone is on a different page. It creates friction between the team members. Those who are proponents of the methodologies come into conflict with the opponents of this development style.
To prevent this conflict, everyone needs to understand and welcome the agile process. This can only be done by clarifying the purpose of agile to the team. Explain the reasons behind the process. Everything has a very specific reason for why it’s done a certain way. These reasons should not be dismissed before they are understood. Agile only works if everyone is committed to the process. Without everyone being committed, the process simply falls apart. Once everyone understands the process, there will be less confusion and a greater sense of team as everyone will be on the same page.
We believe that once you get into the mindset of agile, you will feel more full-filled as you work better with your team, accomplish more throughout the week, and have structure around your work life.
Key Concepts
Agile uses a number of concepts which are important to understand. Before starting with agile, these concepts should be thoroughly discussed so your team can make the decisions on how to effectively incorporate them into your development process.
Sprints
Sprints are a 1 or 2 week work segment. The purpose of sprints is to define how much time is appropriate to accomplish an amount of work that can be easily planned, executed, and consistent. Larger companies may utilize a 2 week sprint, but startups are more than capable of running a 1 week sprint. Startups should be able to make decisions faster and implement solutions quicker. This requires fewer meetings, less planning, and a streamlined development process. Sprints are a simple way to segment work. They allow for a repeated expectation or flow of progress throughout your timeline. Instead of chaos, the sprint allows for a rigid structure that the team can adhere to.
Considerations
Choose which days your sprint begins and ends based on the work habits of your startup. We chose a simple Monday to Sunday sprint cycle since we work through the weekends. However, you can also base it off your pay cycle or any other criteria that makes sense for your team.
Select the shortest sprint possible. A 2 month sprint is completely unacceptable. A 1 week sprint should be good for most software startups.
Story
A story is generally the smallest unit of work for a startup. Large companies tend to implement additional ways to break down stories, but this quickly becomes a process of it’s own that takes up a significant amount of time. As a result, our team does not break down tasks any further than stories.
Description
When creating a story, be extremely specific. Do not skimp on details. Write a description that anyone on the team can read and quickly understand what work will be done in this story. The details may not seem important, but they save a significant amount of time. This eliminates confusion on the expectations for a task and frames the problem in a way that it can be completed without the need for additional information.
Example: Your application has a bug that is preventing a few users from logging in. Instead of simply putting “Users can’t log in” as a story description, be more specific. Say something like, “On Monday morning we got an email to our ‘support’ email from ‘someone@something.com’ saying he wasn’t able to log in. I started debugging the issue because I thought it might be a critical issue preventing everyone from logging in, but I found that our login specifically says if your email is ‘someone@something.com’ that you are not allowed to log in. Jim, Joe, and Jake discussed the issue and we agreed to push this story out because it only affects one user.”
In this example, we see how providing details and explaining the problem makes the situation easier to understand. Someone reviewing this story a week or two later will have sufficient information to revisit the problem, ask questions, and resolve the issue quickly. Since the person discovering a bug or writing the description for a feature isn’t necessarily the person who implements the solution, this also provides a way to increase communication and clarity to the team. A person who is new to the story can then quickly get up to speed and resolve the issue with little aid.
Length
Since stories are the shortest unit of work for startups, they should be broken down into reasonably small units. Make it as specific as possible, so you can close out items and show that there is progress being made.
Example: Instead of a single story to “implement the website”, break down the tasks further. Separate tasks for each page, feature, and task which will take more than a day or so. The more stories can be segmented, the easier it is to understand the scope of work.
There may be cases where large stories can’t be broken down further. Let’s say, you have a task where someone needs to manually type 1,000,000 usernames into excel that were originally carved onto a stone tablet. Unfortunately, this would be a single story that would take a very long time. The reason is because it’s all the same thing. Breaking it down by how many you do at a time may be possible, but it’s also arbitrary and doesn’t add much value.
Priority
Every story should receive a priority. If there is a story that has an unknown priority, it should be decided at the next daily or weekly planning meeting. This allows everyone to have discussions about high priority items as early as possible. The scale we personally use to assign priority is 1–5. Where 5 is the highest priority and 1 is the lowest. A story which receives a 5 priority should be addressed immediately. It needs to be brought into the sprint and completed as soon as possible. Everything else should be put on hold until this problem is solved. This priority is reserved for stories that are critical to the functioning of the product. A 4 priority should be pushed out until the next sprint (even if there are lower priority items in the current sprint, you already finalized the sprint, so don’t change it now). A 3 priority means it should be done sometime this month, but not necessarily next sprint. A 2 prioritymeans it’s a long term goal, maybe in the next few months it should be implemented. A 1 priority means it is something that can be considered, but you don’t know if you even want to do it. An example of a 1 priority is a user request for a feature you don’t plan on implementing. It can still be recorded as a 1 priority item until a definitive decision can be made regarding whether or not is should be implemented.
Epic
An epic is a group of stories. Each story should be a component of the epic which builds towards a larger feature or development.
Example: You are implementing your website for the first time. You may have a “Home” page, a “Blog” page, a “News” page, and a “Team” page. Instead of creating one single story that requires the completion of the entire website, create stories for each component. This could be one story for each page or even reducing each page into smaller stories by adding multiple stories for each individual page. The epic is then the entire static website and the stories are each task required to accomplish the completion of the website.
Whatever you decide, it should be easy to visualize how the epics are structured so you can take stories from any epic as you develop. Say you want to improve the “Home” page next sprint. You can quickly pull a specific feature from that epic into the sprint by filtering what options there are for improvements on the “Home” tab.
Capacity
Capacity is the amount of work that can be completed in a specific time frame. In agile, this is typically the amount of work that can be completed within a sprint. Since this is a definite value, the capacity of work cannot change throughout the sprint. As a result, no new work should be brought into the sprint once the sprint has started (the exception of course being critical bugs).
In a startup, the amount of work assigned in each sprint should be as close to 100% capacity as possible. This essentially means that 100% of the work that will be completed in that sprint is assigned at the start of the sprint. Even if critical bugs surface, the team should do everything they can to finish every story that was allocated that sprint. Allocating less than 100% does leave room for popups and critical bug fixes. However, this also reduces the clarity of what work should be completed if development is ahead of schedule.
The capacity typically has two different components. The team capacity as well as individual capacity. The individual capacities between each member on the team do not need to be the same. In fact, it’s unlikely. Different people are able to get different amounts of work done. Where one person may take 2 hours to complete a story, another person may take 6 hours to complete the same story. This should be considered when evaluating the capacity for each sprint.
Standup
Standup typically happens at the start of the day. If most people get to work at 9am, standup can happen at 9am. Standup should never be more than 15 minutes. Focus on brevity for standup. Answer the following 3 questions in less than 60 seconds per person:
What did I do yesterday.
What am I doing today.
What is blocking me from completing any of my work.
This is not the time to talk through problems. It’s intentionally short to reduce the amount of wasted time and maximize the quantity of information disseminated to the team. If necessary, this can also be the time to make brief announcements that are relevant to everyone.
Planning (Daily, Weekly, Monthly, Quarterly, Yearly)
The direction of your startup will change. As you adapt to the needs of your customers and continue to develop an understanding of the market, you will need to adjust your strategy quickly when the right opportunity presents itself. This requires frequent, but brief, planning. Instead of lengthy meetings every few weeks or months, meetings should be quick and often. This keeps the direction of development on point and allows for quick adjustments to the company strategy.
Daily
Every day there should be a quick “what is happening tomorrow” meeting. If you elect to have this brief meeting during standup, it turns into a “what are we doing today” meeting. This should be a quick 5–10 minute meeting that addresses any updates or changes to the plan, discuss what is happening the next work day, and if there are any expected results from that development. At Shrimpy, we do our daily planning meeting at 9pm to kick off our night work. It generally only takes a few minutes, so the rest of the time can be spent on other work.
Weekly
Each week there should be a weekly planning meeting to start the next sprint and end the previous sprint. This meeting is slightly longer as it will include a retrospective, story planning, work allocation, and planning everything that needs to get done in the next week. During this time, it should also be evaluated if the current direction is fitting into the monthly plan and everything is on track to get completed.
Things come up during the sprint week. That’s okay. However, they should not be done during this week’s sprint. The weekly plan is set in stone. When new things come up during the sprint, create a story and push it out into the next sprint. The only time a new story should be brought into the current sprint is if it’s absolutely critical to the functioning of the application.
The plan should be that 100% of time should be allocated in the sprint. This means it’s unlikely everything will get done, because critical things come up, but it gives the flexibility that if 100% can get one, there are still items available in the sprint to get done, so new items don’t need to be brought in.
Monthly
It’s okay if more important things come up, the month plan is more flexible than the weekly plan. Every month there should be a “what are we doing this month” meeting. This may be a little longer as the high level items are decided for the month. When thinking about how much work to put into the month, think about the amount of work that can generally get done in a month and then plan for about 60-75% of that work to get done. The other 25–40% of the work will come from new tasks that come up.
Quarterly & Yearly
The quarterly and yearly meetings should be rare in a startup. Everyone should know the general direction the company is moving. This should include a general sense of how everyone would like the company to look in 3, 6, and 12 months. However, planning this far in the future is nearly impossible. New opportunities arise, things don’t go as planned, and discoveries are made though iteration. Don’t decide every story you will implement for the next 3 months. Discuss options and how each of these will fit into the vision for the company. Keep everyone up to date frequently on changes in direction and when new things come up that drastically change the course of the company.
Retrospective (Retro)
Retro happens before every weekly planning. Everyone should quickly go over their items, how they went, what went well, what things didn’t go well, and what changes can be made for the next sprint to make it better. This is the time to go over the previous sprint, close out stories, and figure out why certain items didn’t get completed.
Product Owner
In most agile environments, there are a number of roles that teams usually enforce. In agile for startups, we find it unnecessary and inconvenient for the whole team to have individual roles. Instead, we only implement a single role, the “product owner” role. This person is responsible for allocating stories, starting / ending the sprint, bringing items into the sprint, and enforcing the process.
Process
The process we recommend is one which is straight forward and allows for the optimization of development time. Our team uses a one week sprint. This allows us to plan every week, segment our work into tasks that can easily be completed, and close out work items quickly.
Week in Review
Now that we have a general understanding of the concepts for how agile works, let’s take a look at how our typical work week looks.
Monday — Friday
One way we optimized our process early on was by separating our day into two distinct segments that differ by function. The hours of 9–6pm are restricted to working on items in the sprint. This generally means not answering emails, no popup work, and following the sprint schedule. If you are working on something that is not in the sprint, you are doing something wrong. Either the item should be brought into the sprint or you should stop working on it. In order to bring something into the sprint, there should be a discussion with the product owner or other engineering team members to clarify why new items will be brought into the sprint. This ensures everyone agrees on the priority of the item and the importance of completing it immediately.
In order to allow for the completion of work outside the sprint, we have allotted time at night from 9pm — 12am. During this time we work through the design for new features, discuss user feedback from the day, respond to emails, and quickly plan the next day. The nightly meetings are far more discussion based and focus on relaying information.
Saturday
There is a lot to do, so we work on Saturdays. Generally, this is a more flexible day to work, so we decide later in the week what time we will start. On most occasions, we work from around 2pm to 10pm. If all of our work has been completed for the week, this time is generally small items we can get done that will make the next sprint easier, or just things we haven’t had time to do. As much as possible, they should be smaller things so they don’t carry over to the next sprint.
Sunday
Sunday is a free day. Besides meeting at 9pm for the weekly planning and retrospective, we generally try to rest and relax a bit before the start of the next sprint.
At the weekly planning meeting, we go over the items that were completed the previous week, discuss what work we will be carrying over into the next week, and allocate the work for the next sprint. Holding this meeting from 9pm to 12am on a Sunday allows us to start fresh on Monday with a clear vision for the week. Conducting this meeting on a Friday or Thursday would generally result in lost time trying to remember what we discussed the previous week. Since the planning doesn’t necessarily take the entire time, the rest of the time can be spent going through other items that need to get done for the week.
On the Sunday before the 1st of every month, we have a monthly meeting. This decides the direction for the next month, what high level features we want to implement, and reviews the last month. During this meeting, everyone should discuss if they feel the team is on track to accomplish the long term goals. Think about the features that should be implemented this month that will help accomplish these long term goals.
Follow the Process
I’ve said it before and I’ll say it again: work on items in the sprint. Everyone decides as a group what work needs to be done during each sprint. In order to accomplish the business goals, the team decided that those things need to get done this week. That means everyone should only be working on those things and not bring unnecessary items into the sprint.
Be aggressive about pushing out items. When something comes up, it is not added to the sprint. That work is pushed out into next week. This is intentional to improve focus and understanding for the expectations in each week. Every person should be 100% full on tasks, so more tasks will result in items not getting closed. Understanding this ensures no unnecessary work is brought into the sprint.
Closing the Deal
Development is like a business deal. Imagine every story in the sprint is a car and you’re a car salesman who gets paid on commission. Unless you sell a car, you get nothing. Not a single dime. You failed. This is how everyone should think about development. If something is not done, you get nothing. If every sprint ends with “well, we almost finished our items, but nothing is complete”. That means you did nothing. You completed nothing.
When working throughout the week. CLOSE ITEMS. Don’t wait to finish them. Finish a story to completion before you start another item. 1 completed story is better than 10 stories that are 25% done. This may sound counter intuitive, but it ensures things actually get done. It’s impossible to manage a long list of partially completed tasks. It’s far easier to finish one item to completion and get into the mindset that you can’t move on until you complete this story.
As you gain experience with agile, you will start to see opportunities to optimize this process. There may be times when it’s necessary to start two stories to optimize your work schedule. However, this foresight doesn’t come naturally. It comes with practice.
Creating Stories
New stories should be made all the time. Whenever something comes up, make a story. When a user suggests a new feature, make a story. When you find a bug, make a story. Creating a story is not a contract to complete the story. It’s simply a way to keep track of things that will, may, and could get done.
Philosophy / Mindset
When you are thinking about developing in the agile framework for startups, the goal is a streamlined way to develop. Optimizing not only the sequence of work, but also the way people work.
Meetings
All meetings should be as short as possible. They should also be focused around accomplishing things. Working together to solve problems and discussing things that are actually important for the company. Only the necessary people should be included in each meeting.
Focus
Everything moves quickly in a startup. It’s easy to lose track of the direction. In order to keep on point, you need a dedication to focus. Intensely enforce the process to provide inherent focus. Don’t deviate from the weekly plan unless absolutely necessary. If you find yourself always doing things other than those tasks that are in the sprint, there is something wrong. Spend some time to evaluate the problem, discuss with the team, and get back on track.
Communication
People can easily get lost in the shuffle. Ideas get buried, team members will wander, and problems will get overlooked at times. Reducing the occurrence of these issues is often a communication problem. The more communication, the easier it is to keep everyone honest, ensure everyone is aware of problems, and tackle them as a team. It’s better to address a problem together than to let someone slowly burn out for weeks because they got lost in the muck trying to solve a problem that is over their head.
Close
Seriously, close stories. Don’t move onto another task unless the previous task is finished to completion. Multitasking is not productive. Jumping from story to story has a context switching cost. This has been extensively studied and the results have consistently demonstrated that trying to multitask reduces productivity.
Push Out
It’s not your problem today, let future you handle it. Just write a backlog and come back to it later. You have work to finish in this sprint.
Tools
There are a number of tools you can use to manage your agile process. At Shrimpy, we primarily use the tools provided by Atlassian. This has helped us manage our entire process through a single platform. The two most important tools we use from Atlassian are Jira and Bitbucket. We use Jira to manage our sprints, track stories, allocate work, and much more. Bitbucket is used for code management. Since both of these tools are provided on the same platform, they work well together to ensure you can enforce your process from the moment a task is completed, to the time it is merged onto your release branch.
Additional Good Reads
Achieve Greatness By Forming Your Pack
How Our Crypto App Went From Managing $0 To $1,000,000 In 1 Month Flat
How We Grew Our Crypto App To 150k+ Daily Trades
Cryptocurrency Trading Bots - The Complete Guide
Conclusion
There are a lot of things to consider when designing a process that works for your team. While this might not be the optimal process for your team, I would encourage you to explore agile as a way to organize the development process. Some of the topics discussed above may work for you, but some of them may not. Iterate on your process to find what works best for your team. If this is your first time trying agile, you will not get it right the first time. This is why you have retrospectives. Discuss the things that aren’t working each sprint and adjust your process for the next sprint.
Don’t forget to check out the Shrimpy website, follow us on Twitter and Facebook for updates, and ask any questions to our amazing, active communities on Telegram & Discord.
The Shrimpy Team