Making Poetica: how we get stuff done
We’re a five-person startup who’ve been working together less than a year on Poetica, a tool to help you get great feedback on your writing.
Over the last few months, we’ve had lots of conversations with other teams about how we organise ourselves as a small company so we wanted to share what’s working for us right now.
In writing this (thanks to some great feedback from others in small teams!), we’ve realised that the different things we do to help us get stuff done is really varied: there are tools (Slack, Trello, Apo.io), activities (sprint planning, standups, retrospectives) and practices (working hours, taking time off). All of these are underpinned by the team culture we’re trying to create at Poetica to help us build a meaningful product and a company we can be proud of.
That’s a lot of stuff, so we’re going to kick off with just the activities we do — we’ll keep tools, practices and culture for a later post!
Standups
- A face-to-face catch up at 10.30am, every morning, for 10 minutes.
- We each share what we did the day before, what our plans are for the coming day and any blockers we have.
- We end with a check-in about bugs to allow any member of the team to flag anything broken in the live product.
- If there’s a team member missing at standup we each take 30 seconds to write up standup in our group chat app, Slack, so they can catch up later.
Why we do it:
We have found that talking face-to-face about what we’re doing for the day helps us coordinate our work easier than sharing online. Things change fast and we need to keep communicating about those changes. We also found bugs could linger longer than they should in our bug list — especially when some members of the team use the product more than others — and we needed a way to actively say “hey, I’m worried about X, can someone help me do something about it as soon as possible?”
Sprints, sprint planning and story writing
- We plan chunks of work in two week ‘sprints’ that start every other Wednesday.
- Work is split into ‘stories’, written in the form PERSON + WHAT THEY WANT TO DO + WHY THEY WANT TO DO IT. Each story has acceptance criteria — a list of things we’ll have to have done to satisfy the story.
- Sprint planning: Every other Wednesday, we plan the next sprint as a whole team. This simply involves talking through which stories we should be working on next and breaking down the stories we’ll be tackling immediately into individual tasks.
- Story writing: Two of us help prepare sprint planning by writing enough stories to keep us working for two weeks. What those stories are depends on the conversations we’ve had as a whole team in the last two weeks or what’s next in the roadmap (see below).
Why we do it
In a startup, we spend a lot of time figuring out how to balance basic planning ahead (which we’ve found we need to work effectively as a team) with being super responsive to users’ behaviour. We tried a week-long sprint and it felt like we were spending too much time planning and not enough time building. We also learnt about more heavy-weight development methodologies that are more prescriptive about elements of sprint planning/other processes and stripped them back to a very light-weight version that seems to be working for us now, without taking up lots of time. The story format really helps us focus on user need and having acceptance criteria stops feature creep. It’s also been really important that the whole team — not just the founders — contribute to deciding on what and how we work on something. This structure has helped make that happen.
Retrospectives
Before every sprint planning session, we have a retrospective with the whole team. Armed with a block of post-its, we have two minutes to each write down as many things we can think of firstly that we didn’t think went so well in the last sprint; then another two minutes for the things we thought were ‘meh’ and then two minutes for the stuff we think we did really well. In between each two minutes of writing, we go round the team and share what we’ve written, discussing what we all agree on, think differently about and what practically we can change to make our next sprint better.
Why we do it
At the moment, we think this has been by far and away the best thing we do as a team to help us work together! This has become the forum where we talk about how we work and we’ve actively changed lots of things based on these discussions. It’s also a great opportunity to recognise when we’ve done something really well and celebrate that too.
The Poetica Roadmap
We have a ‘roadmap’ that communicates what we think we’ll be working on over the next few months. This consists of A4 pieces of paper each representing a month with different coloured post-it notes on them, stuck on the office wall. The post-its represent either something we’ll be working on (green); a milestone we need to reach (yellow) and a general theme for each month (pink). The level of detail is something like “chat on documents” or “more notifications stuff”. The roadmap’s creation is led by James, Anna and Blaine, but discussed regularly by everyone.
Why we do it
We found that without a roadmap, we had no artefact that communicated across the team where we were headed — leading the team forward was hard. Without any clearly-communicated medium-term (a month in our time scale) to long-term (a few months) idea about where we might be, it’s difficult to make decisions on a day-to-day basis that feel like we’re all going in the same direction. This also feels like something that made a significant difference to how we work together; creating a shared understanding and making everyone feel a bit more certain about the future.
JAB, 1–1s and chat
There are a number of different ways we keep the team talking to one another:
- Slack is our prefered way of chatting as a team on a daily basis
- Every week the founders (James, Anna and Blaine) have lunch
- Every month, Anna has a 1–1 with Jono and Abby
Why we do it
It’s really important that we keep talking to each other. We’ve experimented with catch-ups over different time periods, but given the nature of what we’re doing, we’ve found more frequent is better. None of these conversations are structured: at the moment, it’s more important we create easy ways for people to talk to one another and this seems to do the job for now. We’ve discussed having more structured ‘feedback’ sessions for individual development, but we’re light on HR-type formalities for now.
Phew. Writing all that down makes it feel like there’s a lot going on behind something so apparently simple — surely we should just be focused on shipping high-quality code to address a user need?
We’ve learnt, however, that a startup doesn’t mean no structure. We are a temporary entity searching for a product that lots of people find meaningful. The way we work needs to make us really effective in that search. We are constantly trying to find a balance between being responsive yet focused; lightweight yet effective.
Broadly, we’ve found:
1.) This stuff is hard
2.) It should be organic and constantly improving
3.) It should be defined by the whole team
4.) It matters: without it, we wouldn’t get anything done
Thanks to Kath Hibbert, Oo Nwoye, Nicklas Persson and Emily Webber for their feedback on Poetica drafts of this.
Originally published at blog.poetica.com on September 23, 2014.
