This week I don’t have a solid retro — I’m putting together a brand spanking new website, and I’m going to spend some time putting together content for the site before I launch it to the public. In the meantime I figured I would put together a post regarding what my development cycle usually looks like when I’m working on my own projects.
My first development job was at Wunderman working on Best Buy’s weekly deals site. Every Monday I would come into work sit down and get a list of 10 – 20 custom development widgets that I would have to crank out by Friday. I was the only developer on the production team, and even more surprising the only developer in the entire Minneapolis branch of the agency. The production team was on a quick weekly turn-around.
Weekly turn-arounds don’t account for things called “Best-practices” the first time around.
Fortunately at Wunderman I was able to build off of each week, and while the first couple of weeks had some extremely tight deadlines, I was able to build off of the previous week which allowed me to complete the work in a fraction of the amount of time. Eventually when I left Wunderman I had automated a large chunk of the work I was doing.
Before the concept of Google Design Sprints had received main stream traction I was running a version of my own.
Sprint duration is always a touchy topic. One, Two, Three…Four?! Every organization has a different idea of what the ideal duration is to build a chunk of work. None of these organizations are wrong, but sometimes it’s hard for a team of producers ( developers, designers, user experience, content ) when each of the projects have a different cadence.
This is also a challenge for the organizations when asking themselves what is the volume of work that they can produce, because the measuring sticks are never the same.
So what measuring stick do I use for myself?
Three weeks is too long for my own uses. I’ve seen it benefit teams that are transitioning from Waterfall practices, and do not have the DevOps support that they need — so the developers who are building the product also need to estimate deployment activities every sprint — which cuts into actual build time.
Two weeks is about the right time, but what ends up happening is my weekly rituals are never the same — so it’s harder for me to get into a long-term groove. In addition the type of work that you can complete in two weeks can be fairly large — and for myself completing a larger amount of work allows me to think that I have earned some “downtime”
One week increments of work is my sweet spot. I’ve been formed by it in my career — working within Google Design Sprints and just the way that I worked at Best Buy and U.S. Bank.
Slicing things out into one week increments also allows for better work habits. I do the same thing every week so I can confidently select what work that I can successfully build in a week.
The important part of Monday with week long sprints is to understand the work that I’ll be finishing over the rest of the week. If there’s an item that gets revealed during the design / research sessions than I’ll prioritize it in a later sprint. This allows me to keep it in the back of my mind and mull it over when I’m biking or doing something else.
Tuesday is the real preparation day for the rest of the week. For example, usually I have most of the User Interface roughed out — all the divs and classes are in place but things may not be responsive.
Wednesday is the day that I get the bulk of the work done — prioritizing functionality over micro interactions. If I’ve done everything right at the end of the day I will have a good idea if I will be able to complete the main value proposition.
One thing that you may note about the above is that there usually isn’t any steps for “Review” — that’s because when I’m working with partners they always have access to what I’m working on, either by having access to my git repo or if we’re on the same network they usually have access to my localhost site.
And there you have it! What my week looks like as of August 2018. My weekly ritual has been continuously updated over the years, and I’m sure that it will continue to be updated in the future as I start leaning more heavily into content driven work.
Mathias Rechtzigel is a web creator, his skills range from development, design, user experience and sometimes content creation.
He lives in Minneapolis, Minnesota with his partner (Ellen), dog (Bard), and two cats ( Pippi & Misti ).