We are constantly reviewing and modelling the way we organise who does what and when.
Currently, we have two basic ways we put work into packages: Shapes and Ship-Its.
We started with one feature at a time, and evolved this quite a bit since then.
Stolen from the guys at Basecamp, we have setup up our own way of describing problems along with a solution sketch, a team, and a time box. We deliberately took the parts that seemed useful to us from the original Basecamp idea, while ignoring the details that seems to be overkill, at least for now.
The approach fits nicely into our way of thinking about developing a product.
Small(ish) tasks, where we do know exactly what to do or what to find out. The definitions of these things are soft, and we are still experimenting with a lot of different forms for them. We discovered that writing Ship-its can be hard to get right, and understanding the ask can also be hard.
Some examples of things a Ship-It might be:
- a bug fix
- a technological spike to find out if an approach that seems risky is worth to follow
- supporting our colleagues with something that needs configuration
- one-off help on a business task
- designing a workflow
- writing some how-to or other smaller documentation chapters
As a rule of thumb, we want to have Ship-Its that one or two developers are able to ship within a normal work day. What needs to be done should be clear and no technological challenges are expected.
Push vs pull
First rule: at BetterDoc, we let people pull the work they need to do onto their todo list.
Second rule: Rule one has exceptions.
Almost always, Shapes (or, better, Projects based on Shapes) are work pushed onto people: the team leads choose who will work on which project. This has organisational reasons: Projects are handled by project teams that are made up from people all over BetterDoc (not just Product Development), so we need to coordinate who has time when and for how long.
Ship-Its are done differently. These tasks are kept in a list ordered by potentially earned value and priority, accessible for everybody in the team. When team members look for a task to work on, they take one of the first three items in the list.
It is the job of our Product Development lead to make sure items in the pull queue are ordered so that the most important tasks (those that bring the most value) are on top of the list.
Bugs are, by default, always top-level items in the pull queue.
When to use what
Our rule of thumb is as follows: if the Product Development team knows how to do something without deeper involvement of people outside of our team, we make it a ship it, except if we see that something is much bigger than one day of work.
If we need input and involvement from colleagues within other teams within BetterDoc, it must be a Shape.
Where to improve this
Like every system in use, our way of organising work has flaws. Lots of it. But: we learn and experiment. We improve, we own it.
Currently, we see these things as our most pressing problems:
- writing good Ship-Its
- making sure Ship-It scope is well defined and roughly matches our time expectations
- communicating upcoming projects based on shapes earlier to team members to allow team members to have a better understanding if they can be helpful for a project
- creating well-written Shapes
- making sure we never compromise on quality to gain more short-term throughput
- prioritising helping others on started Ship-Its over starting to work an a new ones