My Favorite Iterative Process
By now I’ve built dozens of products. And the ones that have worked well share one essential ingredient… an iterative process.
As a reminder, an iterative process is a process where you work with a team to accomplish small goals a little at a time always moving the project forward. Typically in a one or two-week iteration. Last week I discussed the idea of an iterative process vs. the concept of a waterfall process. With a waterfall, you get the whole product at the end.
This week I want to outline what my preferred process is so that you can be thinking about what your process should look like as you work with a developer. The following is an outline of the process that I’ve seen work well. I’m purposefully avoiding the buzz words so that we can look past that to the results of what can work well.
A quick note, this assumes that you’ve done all your prework to get to this point. A quick overview below…
Discovery
- What is this thing that we are building?
- How does it work?
- Who is it for?
- What do they want?
Design
- What does it look like?
- What does it feel like?
- What happens when I…?
- What do the users think of this thing?
Now, Development.
Assuming you know what you are building and have some ideas about how it should work, you will take the entire product and work with the team to design sprints. Each sprint will be a single feature. Depending on your velocity, or how fast you can get these ideas done, you’ll scope what you are doing to the length of time required.
For example, a todo app. You know you need the following:
- Account Creation
- Account Management
- Todo List View
- Todo Detail
- Todo Edit
- ToDo removal
- ToDo completed
There is more, but you get the basic ideas. Those are all of the functions that you need for a todo app to accomplish the goals of the project.
Depending on your team, you might look at that and say that each feature will take about one week. So then you might see the sprints setup like this:
Monday:
30-minute Kickoff — Who’s doing what and how will problems be handled
Start coding
Tuesday:
15-minute check-in — What are you working on, what is getting in your way. During the check-in, you just say those two things. You work out how to solve the roadblocks AFTER the check-in so everyone doesn’t get embroiled in the things that don’t matter to them.
Keep coding! Incorporate design for the feature, work with the designers to tweak the concepts based on what your team is discovering about the feature.
Wednesday:
CODE!
Thursday:
3 PM — Present The work for the week.
Everyone looks at it together and discusses changes that need to be made.
Friday:
Make the changes!
Monday:
Ship day. Ship the previous weeks work then…
30 Minute kickoff of the next feature.
You can tweak that to 2 weeks, but beyond that, I think you need to rethink what the scope of sprints are or do you have the team that can build this quickly enough. With this appraochm, that todo app can be built in 7 weeks.
One note, you’ll notice that I didn’t suggest shipping on a Friday. This is my personal preference, but I hate shipping on a Friday. There are two reasons for this.
You should have a life
I think that you should have a life. And at the very least, you shouldn’t work on the weekends. I have the benefit of being a little older, and I can tell you that, in the long view, working on the weekends produces marginally better results than if you execute properly during the week. At least with product development. I know this flies in the face of conventional wisdom, but I’m just not seeing the benefit when you compare it to the cost. Then you can have time off, and you can get rested.
Weekends are hard to get help if something is broken
It’s harder to get help on weekends. If you ship something that is broken and you need to fix it right away, and you need help, good luck. At least if you ship on a weekday, you can respond quickly, and your team will be available to help.
