Recently on Hacker News, a non-technical startup founder was struggling to figure out whether or not his team was productive. The CTO had left unexpectedly, and his developers were learning Node and Angular as they went. Opinion differed; some thought the developers were just padding their resumes; others thought that they were doing their best. What’s a founder to do?
What kills me is that this sort of mystery about progress is not in any way necessary. The planning methods from, e.g., Extreme Programming, are 15 years old. So that nobody else has to suffer like this, here’s my quick intro to a basic version:
The first time
To start out, everybody should sit down at a table with a large stack of 3x5 index cards, all of one color that isn’t white (I like blue or green), and n+1 sharpies.
Talk about the product. As you go, every time something buildable is mentioned, write it on an index card with a sharpie. 3-7 words is usually enough. The cards aren’t documentation; they’re just tokens representing conversations. Every card should describe business value that is visible to all stakeholders. No “set up the IDE”, no “learn Node”, just business value cards. They can be very small. My first card is often, “Visitor sees home page with logo.”
After 30-60 minutes, put the cards in strict linear order of business desire, ignoring technical dependencies. Now take a bunch of cards, write “RELEASE” on them, and insert them into the order every time deploying something is necessary, including investor demos, user tests, private betas, and the like.
Next, look at the top 10-20 cards. Ask the developers if each card will take a week or more. No wizardry needed, just gut-level estimates. If the answer is yes, tear up the card and replace it with cards that are all smaller than a week of effort. Feel free to reorder them; often splitting a card leads people to discover things that can be left for later.
Congrats! Now you have a plan that is enough for developers to get started. Make a permanent home for the cards on a table or wall with three columns: backlog, working, done.
As you work
When people start on a card, move it from “backlog” to “working”. When everybody agrees that it is completely done and the business value is has been demonstrated, move it to “done”. Work hard to minimize the number of things in “working”. Some tips:
- Definitely don’t have more “working” things than developers. The more people collaborate, the more resilient your team will be.
- Don’t move things from working back to the backlog.
- Try to pull only from the top of the backlog. That encourages broad understanding and collaboration. It’s ok to say, “Oh, I don’t understand how to the back-end stuff on this card. Will somebody help me with that?”
- If something ends up too big, look for ways to split it. Find something useful that can be finished quickly, create new cards for the rest, and put them in the backlog.
- Be firm about “done”. It should mean “released” or “will go out at the next scheduled release”. It must not mean “mostly done”, “still buggy”, or “I’m tired of working on this”.
- Bugs in things that are already done are written up as new cards and prioritized like everything else.
If you’re used to working with specifications, it can feel weird to grab a card with only a few words: you don’t know quite what to do with it. But that’s exactly how it should go. Startups move too fast to be endlessly writing and rewriting specifications. When you grab a card off the top of the backlog, you’re now holding the most important thing not yet in progress. It’s time to go and discuss what the card really means.
That conversation will have a lot in common with the one had before the card moves from “working” to “done”. It’s much easier to agree that the card is done if the conversation starting it happened just a few days before. That recency keeps the focus on whether what’s built is what the startup needs, not on conformance to something written down weeks ago in a meeting nobody remembers very well.
Each week, each day
Each week on Monday morning, everybody should sit together, look at the backlog, and take an hour or less to discuss everything that will likely get worked on. Collectively make a guess about where you’ll be by Friday afternoon.
Each day take 5-15 minutes for everybody to quickly chat about status. Make sure the board is up to date. If cards are sticking too long in the “working” column, chat briefly about why. If somebody needs something from someone else, make sure it gets discussed here. Anything that threatens to take the meeting longer should be scheduled as a separate thing.
And the end of the week, sit down together again, review how it went, count the cards completed. (This is also a good time to talk a bit about process. What’s working? What’s not? Does the board correctly represent the state things? Should you be shooting for smaller cards or more frequent releases? Do people feel productive? What could you try changing next week to see if you can make things better?)
Why this works
After a few weeks, the business stakeholder can look at the number of cards completed each week, look at the backlog, and make reasonable guesses as to how long things will take. And after a few weeks seeing the team deliver business value each week, they’ll have a good notion of how effective their team is.
Conversely, if the team really is in trouble, it should be obvious. Common warning signs:
- Cards sticking in “working”.
- Repeated failures when trying to move something from “working” to “done”.
- Too many items in “working” at once.
- A week goes by with no business value delivered.
- Lots of fighting, blaming, or excuse-making.
The nice thing about working collaboratively like this is that failures are quickly apparent to everybody. If the team starts out the week thinking that they’ll get the top 5 cards done and they end up getting 0, nobody has to yell at anybody. Everybody feels the failure. (At this point, some teams will dump the process, but that’s a mistake. The main value in processes like this is exposing problems. Work through the pain.) They’ll be eager to do better next week.
There’s more (but start now regardless)
This simple version is enough to get people going. I’ve built entire products this way, so I know it works. But the key to success is improving your process every week. As you notice an issue cropping up repeatedly, try to find a process fix for it. Experiment and see if the change makes things better. (If you have a choice between removing something and adding something, favor removal.)
To make next week a little better, you have to get started this week. You can read endlessly trying to figure out a perfect process. But there is no perfect process, just the right one for you and your team at the moment. The real trick to a perfect working rhythm is to get started with some simple process now.
Feel free to ask me questions via email, but if the question is, “What happens if we have a problem with X,” I encourage you to wait until you actually have the problem. If you ever have the problem, having a habit of regular small process improvements will mean you will probably know the answer better than any outsider.
Originally published on Agile Focus.