Different Stokes for Different Folks

My high school history teacher Mr. Hupert always used to say “different strokes for different folks.” He explained how under different circumstances in different times with different people, different forms of government were effective. So, too, I discovered, it is with effective software development methodologies.

When I joined IMVU, we were continuously deploying to our production websites about every 70 minutes. With some effort, we got down to being able to push fully tested changes to production every 7 minutes.

Though we had frequent incremental deployments we also employed various forms of Agile methodologies within development. At one point I had five different team using five different methodologies. How to approach software development, even within the company famous of it’s Lean Agile approach, differs from team to team.

One team was doing more green field work going into somewhat uncharted territories. They used new programing languages and/or system architectures. It was trickier to predict what would get accomplished within a two-week sprint. So, we used the Kan Ban approach where the completion of a phase of work was not bounded by time. Accomplishing a set of work pulled from a backlog of tasks was best. We did this until a set of functionality was completed. Those increments were in the form of a Minimally Viable Products. That allowed us to unleash on some of our customers to run experiments on how effective it was.

Other teams that were iterating with known technologies in known areas of the product. They made tweaks in hopes of improving customer experience were much more able to scope work into two week sprints. Variants evolved as we learned at the retrospectives what worked and didn’t work well for a particular team. Some teams used story point poker, others didn’t …

One team needed to release on iOS. They, unfortunately, have the luxury of continuous deployment. Apple’s review cycles at the time meant it could take two weeks before any customer would see a change. If we discovered something wasn’t working so well, it would take about two weeks to pull that change out again. Here continuous deployment and rapid experimenting didn’t work as easily. We had to target experiments to come in two week trial phases.

Another team experimented with using Extreme Agile. We did this experiment in conjunction with Pivotal Labs who also was very strict about their definition of pair programming.

At Twitch we also shipped releases on Xbox and PlayStation. Our processes had to be more akin to the water-fall days as the next release might be six months away. This required even more rigor in planning and validating what went into each release.

Finding what worked best for each team and set of circumstances proved not one size fits all.

We experimented with which product features were best for our customers. However, we alsoexperimented and evolved with our processes. We learned to tune them to the people and release vehicles, allowed us to continuously innovate in our approaches to software development as well.