Lessons Learned from Agile Transformations: Part 2

Second in a Fifteen Part Series
By Chad Greenslade

I have often been asked about my lessons learned in delivering Agile transformations.  Below is the second in a fifteen part series examining my lessons learned while instituting Agile concepts & practices.  I hope that these lessons help you on your journey to Agile nirvana.

Lesson 2: Understand Common Reasons for Moving to Agile

I believe there are three (3) common reasons for moving to an agile delivery methodology.  These reasons have nothing to do with IT specifically, but rather align themselves more generally with the common goals of product delivery.  These are timely delivery, resolving quality deficiencies, and speed to market.

In the traditional waterfall model, an IT project could have a duration of several months or years and not produce anything of value for the business, if it produces anything at all.  A common stakeholder complaint is that they rarely, if ever, know when anything will be delivered.  Sponsors and stakeholders become reluctant to allow the project to continue when there is no end date or discernible deliverables in sight.  An obvious and common risk is that a new opportunity or project will present itself resulting in the original project being cancelled, ending the work before anything of value is delivered.  An agile delivery methodology alleviates concerns related to timely delivery by producing incremental product units on a pre-defined timescale.

Today’s business environment is constantly changing.  Whether it’s new products being developed, old products being retired, competitors being acquired, divestitures, market expansions, new legislation or regulations, the only constant is change.  This has an overwhelming and obvious effect on the information needs of the organization required to make accurate business decisions.  Furthermore, a business is often willing to invest in building a solution to meet these information needs before all of the needs are fully known or understood.  The traditional waterfall model is not conducive to the ebbs and flows of today’s business environment.  It creates a situation in which a project team attempts to collect all requirements at the beginning of the software development effort, even though they may be unknown at the time of collection.  The project team then takes the requirements as defined (or undefined) and attempts to build the solution over the course of months or years while discouraging changes to the requirements during the development process.  This invariably breeds an environment in which the product delivered not only fails to meet the initial requirements, but also fails to address the changes in business conditions that occurred since the original requirements were collected.  Stakeholders regard these as quality deficiencies even though the system may be coded exactly as the requirements specified.  An agile delivery methodology alleviates quality concerns by continuously engaging the consumers of the information system throughout the development lifecycle and embracing the inherent changing requirements of today’s business environment. 

A key theme of a successful business is continuous innovation.  A common complaint from an executive whose business is failing to innovate could be, “our competitors are consistently beating us to market with new products or features.”   An agile delivery methodology keeps the organization focused on product release milestones via the inherent cadence that accompanies the methodology.  It also seeks to discontinue the use of non-value add activities such as unnecessary documentation or process which further refines the focus of the product delivery team.