I’ve written a bit about the technical side of building a serverless CMS product called Koi CMS, but I thought it might be nice to talk about the other side of things: the side that involves Sharpies and Post-It® Notes.
Oh yes, this is going to be a Product blog. Or something like that. I probably haven’t even experienced real Kanban, so this is just a good way to capture my experiences so far.
To prove this is a real product blog, here’s a selection of Post-It® Notes:
This is a selection of some of the tasks in the “done” column, more on that later.
Some Product Aims
Everything needs an aim and since I was developing a new product for a handful of clients, this is where I started.
I started out basic, with a bit of humour thrown in. Things work out better that way. My aims were simple:
- Build a Serverless CMS
Measurable aims? Sure! I could say it’s built. Is it profitable? Hell no. But what would a profit look like? That’s probably a whole ‘nother discussion right there. In short: it’s not about the dollars, it’s about the experience. Anyways…
Every product has a backlog
I think that’s how it works in Product-land. Together with a backlog, I had a bit of a process going on which involved writing a few Post-It® Notes and then moving them across a wall. The backlog is such a key device to work out where to spend your effort and also acknowledge effort spent over time.
A few Post-It® notes (actually, quite a few) later and we have the need to have columns/statuses/sections/what-have-you. A simple system using 3 states is enough for one person and a bunch of tasks, so I started with that about a year ago. It hasn’t really changed a lot since.
This is a list of everything that people have asked for, bugs that have been found or new things which sound cool. It’s also a list of tech-debt improvements and other things which just seem like “good things” to do. There is no real order to these, but they sometimes group together into who would benefit most by implementing the item. I like to pick up the next thing that sparks my interest (or causes the most drama if it’s a bug!).
As work starts, notes are placed into this column.
Hopefully this is kept to only a couple of tasks, particularly when one task is waiting on some external thing to happen and you don’t want to lose it in the sea of “To Do’s”. I think I’ve run to a maximum of about 3 at once. Maybe that’s wrong by the rule-book, but I found that it was quite reasonable to manage 3 different pieces of work myself.
The best section! Woo it’s done. Sometimes things creep in here a bit too early and need to be dragged back, but this doesn’t happen too often. I don’t write a new Post-It® for that, I just keep the same old one. Checkout that fro man!
This section is now mammothly huge and might need culling at some stage. The more it grows, the better the couple of lone “To Do” tasks look. I’m not really sure what to do with this at the moment.
One More Thing
I did revise tasks as I went along. Most of the time I just cut out work which I figured wasn’t really that essential, or was holding things back. The focus was really to get things through as quickly as I could, so any super-complicated piece of work which was overloaded with a small piece of work really deserved it’s own ticket, so I went with that plan.
Things I didn’t bother with
Ordering by priority
Everything is just a cluster of things and I only worked on the things that seemed to take priority at the time. I didn’t spend any time moving things around to get the priority sorted.
You know what, it’ll get done when it’s done! But I didn’t even bother with this. What was I going to do with the information anyway?
Turns out, the team I’m in (in real life) just decided that estimation wasn’t a useful activity. So that’s quite interesting.
The pack of Post-It® Notes that I used were some sort of “New York Subway” colour theme - pleasant on the eyes - but I had gotten so far into writing notes that I didn’t see a need to use the colours for anything specific.
This didn’t happen either. About the only thing I did do however was write “bug” on the things which were bugs. But even then, does it matter? It’s a list of things to do, so it didn’t matter if they were new features, migrations, bugs or tech debt.
The process of deciding what next to work on is quite interesting. It’s really value-effort driven to the point where some tasks stay on the wall in the “To Do” column for many months, glaring at you in the face like the guilt trip from a child.
This process is really natural: You have a brilliant idea, so you throw on a Post-It® note. Up on the wall it goes. It hangs around for ages because it’s a “good thing” but is difficult. You can’t bear to remove it from the wall to make the “To Do” list look a bit better because it really should be done one day, but just not today. Nobody is asking for it, so why bother right now?
Another example is something which starts off as a great idea, so work begins, but you quickly become bored of the task if it takes more than a couple of days. So then it hovers in the “Doing” section for far too long, and you drag it back up to “To Do” again. It’s a feature nobody asked for (such as A/B test experiments) but is a common thing to do. I think this is OK: you can always park it and come back to it later on when it does become important.
Over time, you are pretty much left with just ratty huge tasks that nobody has asked for but might be good things to do. Actually, a lot of it might be tech debt can be tricky to solve but worth it in the long run. I guess I should press myself to work on more of these items to tackle them one at a time, rather than letting them build up to a completely unmanageable level some stage in the future.
A CMS. Woo!
Also, not much left on the wall now. Perhaps I need to start an opportunity canvas? Or I could just go back to refactoring… Oh look, there’s Amazon Rekognition, I wonder what that does and how I can use it in Koi CMS?