Choosing agility
A couple of years ago I was working with a team responsible for an eCommerce platform undergoing a platform migration. When I joined the project, it was already behind schedule and over budget.
For several months, the migration project was continually “80% done”. The new platform was getting closer and closer to “ready,” meanwhile the legacy platform was becoming harder and harder to maintain. What’s worse, every functionality change on the legacy platform had to be re-implemented on the new platform, too, so that the eventual switch wouldn’t represent a regression.
The project was using Scrum, but I had many times raised concerns about the de facto Water-Scrum-Fall we had in place.
One day the department director asked me out of frustration, “Jonathan, when can we finally start using the new platform in production?”
I was able to answer immediately, because I had already said the same a few times: “We just need to make the decision. No more feature work on the old platform. And all new features on the new platform need to be delivered to our customers immediately upon completion.”
Somehow he heard me this time. Within a day, our operations engineer had configured the load balancer to direct a small list of pages to the new platform, while continuing to serve every thing else on the old platform.
From then on, week by week we were putting new pages into production on the new platform. My recollection is that the entire mood of the organization changed from that point. We were able to celebrate small victories every sprint, rather than continuing the death march toward an eventual big-bang release.
Despite the common perception that software agility is mostly about technical practices, in my experience the biggest obstacle is almost always in the human part of the equation. A simple choice can be enough to make the difference.