My high school history teacher Mr. Hupert always used to say “different strokes fo different folks” in explaining 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 40 minutes. With some effort, we got down to being able to push fully tested changes to production every 9 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 you best approach software development, even within the company famous of it’s Lean Agile approach, differs from team to team.
For a team that was doing more green field work going into somewhat uncharted territories of 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 is not bounded by time but rather by accomplishing a set of work that we would pull from a backlog of tasks until a set of functionality was completed in the form of a Minimally Viable Product we could unleash on some of our customers to run experiments on how effective it was.
Other teams that were iterating with know technologies in known areas of the product to make tweaks in hopes of improving customer experience were much more able to scope work into two week sprints. Here to there were variants 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 …
Our team that ventured into releasing an iOS version of our product didn’t, unfortunately, have the luxury of continuous deployment as Apple’s review cycles at the time meant it could take two weeks before any customer would see a change. That too meant 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.
We also had a team that experimented with using Extreme Agile as per our experience in working with Pivotal Labs who also was very strict about their definition of pair programming.
When I went to Twitch and, in addition to web and mobile, we shipped changes that were integrated with the releases of 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 circustances once again proved it’s best not to assume one size fits all.
Experimenting not only with which product features were best for our customers but also with our processes, to tune them to the people and release vehicles, allowed us to continuously innovate in our approaches to software development as well.
