Back on the Front Line of Agile Software Development.
Tuesday, August 9, 2011
We’re at what I perceive to be a major “transition point” in our Agile transformation. Most of our Agile pilot teams and projects have successfully completed and we are rolling out internal Scrum training throughout the Product Group. We’re on the cusp of taking a big step forward with Scrum adoption within our 500 person organization. It’s at transition points like this when I find myself reevaluating our direction: “Why are we doing this? Are we ready for this next big step?” Our existing processes do, in fact, lead to shipping product and generating revenue, so: “Why Agile?” Our original goal, defined we began this transformation, still rings true:
The goal is not to release things faster for the sake of it. It is to achieve nimbleness and agility to deliver on the company’s strategy as it moves forward and/or tactically changes. It is about creating more business opportunities for ourselves rather than being cased into a model that requires our resource commitment for a time window that is longer than what the market we’re competing in requires.
Specifically, the software development group’s reason for moving from Waterfall to Agile is to achieve nimbleness and agility to deliver on the company’s strategy as it moves forward and/or tactically changes. We want the ability to efficiently deliver strategic products to market in a timely manner. Today we have challenges delivering on this goal. As a mature software organizations our development practices have been hardened over many years of delivering software to tens of thousands of customers. Our processes have been tempered with the successes (and often, the failures) of the past. Because of this, it’s difficult to change the current way of doing things. This is an understandable, and completely human, reaction - but it can dangerous over the long-term. Fortifying the walls, via policies and procedures as well as organizational divisions, has the result of business being less reactive to change, less agile, which ultimately impacts corporate revenue. New software releases often take longer to get out the door and may not fully meet customer needs. Entering new markets in a timely manner becomes difficult, allowing younger more nimble companies a market advantage. It is for these reasons that we’ve embarked on our development process transformation. As part of our migration from Waterfall to Agile software development, we need to build a new way of working, including a new corporate culture: one that is nimble and responsive to ever changing business conditions. A culture that values responding to change over following a plan. One that regularly inspects and adapts, and becomes better over time. Scrum, with its “inspect and adapt” framework, is one of the catalysts that can greatly assist us in this journey.