Agile Adoption Equals Mental Shift

0

Agile Adoption Equals Mental Shift

The adoption of Agile software development principles requires serious adjustments to the mental models we employ in approaching projects and understanding real business value.  Too often Agile adoption efforts begin with a focus on the mechanics of Agile (i.e., formation of a Scrum team, learning how to build a burn down chart, how to hold a daily scrum meeting and how to engage in sprint planning) rather than focusing on the principles of Agile.  Yet it is embracing the principles of Agile that will lead to success.

When assessing whether an Agile approach to a project will be successful, the first question we have to ask regardless of the size and scope of the project is whether the business is ready for an Agile implementation.  Agile does not just impact the IT organization.  It must be embraced by the entire enterprise.  We cannot for instance just create Scrum teams in an IT vacuum and expect to be successful.  We have to teach the business owners, stakeholders and IT folks alike the value of Agile and thereby change the way they think, act and measure success.  If they are unable or unwilling to accept these changes then you are probably better off with a more traditional model.  For instance, a mental shift must occur in how the business develops a project’s charter, scope, plan and budget.  In order for Agile to work successfully, we must stop asking the following question:

We have all of these needs and wants for the new system that have yet to be defined in detail but can you tell me precisely how long it will take and how much it will cost?(Traditional fixed-price model).

Instead, businesses looking to adopt an Agile software model must shift their thinking and begin rephrasing their question as follows:

“I can afford to spend $1,000,000 of my budget this year on the development of new software that will add value to my business.  How much real business value can I deliver this year for that level of expenditure?”

When operating according to the first question, an Agile software project (or perhaps any software project) is set up for disappointment and possible failure.  Inherent in the first question is the compilation of a list of needs and wants that have varying degrees of business value and that will ALL be included in a project plan, ALL be elaborated, ALL be designed and ALL be deployed regardless of real value.  What you then have is a project that drained $1,000,000 and is delivering a collection of functionality that runs the spectrum of business value; from unnecessary, to marginal, to great value.

In contrast, when operating in conjunction with the second question, the business can stand up and accept the challenge of prioritizing all of the perceived needs and wants, and deliver the most valuable business components possible for the $1,000,000 budget. Agile seeks to deliver only those things that are directly tied to real business value.  A well-known statistic in the industry is that 45% to 60% of the features and/or functions manifested in source code in a development project are rarely or never used.  In Agile, we seek to eliminate those features and functions that do not return true value to the business.  Many business and IT people have a real problem with this concept and have learned to believe that the project is not complete until all of the requirements that were specified up front have been coded.  But in reality, for most software projects anyway, many of the features and functions specified up front really do not contribute to TRUE business value and are in fact a waste of time and money.

A second Agile adoption principle that must be embraced requires businesses to stop thinking about software projects with defined beginnings and endings, and think instead of software applications as living, breathing, business-value delivery systems.  Businesses must understand that business value delivery through software is evolutionary.  As the business changes, so does the definition of business value and so must the software applications that deliver that business value.  One reason that most organizations have many applications that are developed, supported and then completely rewritten or replaced is that the system was typically conceived, built and implemented in a big bang approach that only served the needs of the moment.   But what if our mindset at the beginning of a project focused on organic growth and “evolutionary, business value delivery” instead?  If the software application was built from the beginning to accommodate growth and changes in the business then perhaps the need to completely rewrite applications in the future would disappear.

An Agile approach drives us to break down our software development into short phases or sprints which maximize the amount of business value (by way of features and functions) that can be delivered in a set period of time for a set budget.  We view it as a continuous process of:

  • Looking at how much we can afford this year (or in some prescribed time frame) on software that will deliver real business value,
  • Identifying those things that will deliver the greatest value within the budgeted dollars,
  • Elaborating, designing and building (just-in-time) in short iterations only those things with the greatest value,
  • Demonstrating that value to all stakeholders in working software (meaning it is potentially production ready) every 30-45 days (we use 30-day iterations typically),
  • Learning from each iteration to improve the process and product,
  • Testing for quality from day one (continuous integration, daily builds, test plans/scripts, automation, etc)
  • Reprioritizing features and functions every 30 days based on changing business needs.

Taking shortcuts, or believing that you can create some type of hybrid methodology at the expense of the key principles of Agile will simply lead to frustration and failure.  Agile software adoption MUST focus on the PRINCIPLES rather than just the practices if it is to be successful.

Follow me on Twitter at www.twitter.com/peterdeyoe

Share.

About Author

Comments are closed.