A startup is an organization formed to search for a repeatable and scalable business model.
— Steve Blank
A ‘startup’ is a company that is confused about:
- What its product is.
- Who its customers are.
- How to make money.
As soon as it figures out all 3 things, it ceases being a startup and becomes a real business.
— Dave McClure
Regardless of the definition of a Startup that you may choose or you adhere to, one thing is common… Speed.
A startup (among others) runs a race with time to reach growth before the cash runs dry. Software development in a startup is equally influenced as a result. Speed to finish the current software development cycle. Focus on specific features and tasks. Fix what needs to be fixed.
Us, as a startup, have to work in such an environment. Some time ago I made a post with the “8 reasons that made us change from Trello to Targetprocess 3“. Today we will discuss how we actually work and a Hard Truth in the end…
A “Scrum-ish” Apirise.
When we started developing our product we wanted to adopt an agile methodology. We are 3 co-founders and we didn’t want to cause overhead in our work towards the product. As such, we do not use any specific method per se. I would describe it as “Scrum-ish”. We combine Scrum and Kanban principles inspired by talks and books of Henrik Kniberg.
In that spirit we use user stories, sprint planning, backlog, retrospectives and we have a Kanban board.
Our way of work.
1. The Backlog
We use a Product backlog, which contains the product features. It is a big bucket where we keep almost everything. We have large product features, user stories, user stories from feedback or requests, bugs and tech stories.
We analyze the features and split them in smaller user stories. Putting priorities and accessing them from the backlog becomes much easier this way. We do not split each feature in the backlog though. We only do the most important for the immediate development cycles.
Tech stories are tasks that we have to do and do not provide direct value to the customer e.g. “setup the CI server”.
2. The Planning
Every two weeks we have an iteration (that is a sprint cycle). Typically the story goes like this:
- On the first Monday of the Sprint we do a Planning meeting (Sprint Planning meeting). Though this is not the first meeting we do during the day, more on that later.
- We discuss and choose which backlog features/stories will go in this cycle.
- We estimate the size and the importance of these stories.
- We add all these user stories in the “Planned” column of our Kanban board. Basically, this is the Sprint backlog with all the user stories we are committing for this iteration.
Note on estimates: We estimate based on how many hours this task will take. We use 1,2,4,8h. If a task is over 8h we split it again.
3. The Flow
In Apirise we use Targetprocess 3 (TP3 in short) to visualize the development flow on a Kanban board. It is a simple flow and a user story “travels” like this:
Planned (committed work) -> In progress (w/ WIP limit) -> Ready for testing (used as a buffer and w/ a WIP limit) -> In testing (w/ WIP limit) -> Done!
TL;DR we choose User stories, put priorities, develop, test and launch.
4. The Bug
We keep track of the issues found in the TP3 Bug board.
- We evaluate the need and urgency of the bug right away.
- If it is a major issue we add it to the running iteration, at the “Planned” column.
- The developer pulls it whenever seems fit.
5. Daily Standups
Although we are only three, there are things that we may not communicate ccorrectly In our work we communicate daily, thus we do not need daily standups (yet). We schedule two timeboxed events (daily meetup) per week. We sync and resolve questions that may have arisen.
6. The Launch Button
On the second Friday of each iteration, we wrap up everything. Finish up testing, switch from development to production servers and Launch.
On the weekend we hope everything went well.
7. The Retrospective a.k.a. “Know Thyself”
We start each Monday of the new iteration with a “Retrospective meeting” of the previous round. We believe this is the most important meeting of all. We left it Mondays on purpose. It allows time during the weekend, to think over various issues.
At this meeting we discuss everything that we believe needs fixing or didn’t go that well.
If one meeting is the that you want to keep from “Scrum” then keep this. This is where all the learning goes.
We do it before our Planning meeting, which in turn is right away after the Retrospective.
8. CADENCE
|
WK1 |
WK2 |
WK3 |
WK4 |
|
|
Planning |
X |
X |
||
|
Daily Meetup |
XX |
XX |
XX |
XX |
|
Launch |
X |
X |
||
|
Retrospective |
X |
X |
9. METRICS
For our metrics we use the Cumulative Flow diagrams inside TP3.
10. THE HARD TRUTH
OK… the hard truth is that you may setup the best plan in the world on how to work, but as a startup, anything may break it. It could be our own human nature or a major change in the startup life. As a startup you are not prepared for everything or be that agile. Here are some of our own real cases:
- A Pivot: A big change in your product. Pivoting could make you throw away your whole Kanban board.
- A super urgent Bug: Who checks the formalities now…
- WIP Limits: In theory, we respect 100% the WIP limit. Keeping it in practice is a real challenge. But we try to get better at it.
- A sudden change of priorities: You may see that you need to focus on something else. Suddenly we had to deal for a long time only with the business aspect and little with the product. That means no Sprints, no Sprint planning not retrospectives. The trick is to get back on track to your plan.
- You may just forget to update something…
Concluding, this is just our way of work. You need to find what works for you best and try to experiment with different stuff – we do. But do not forget: Plans are nice, but many times you may have to run like hell for your startup.
Scrum and Kanban are both empirical in the sense that you are expected to experiment with the process and customize it to your environment. In fact, you have to experiment. Neither Scrum nor Kanban provide all the answers – they just give you a basic set of constraints to drive your own process improvement.
— Henrik Kniberg
