The Case for Feature Driven Development

Despite the best efforts of architects, engineers, planners and CIOs there continue to be an uncomfortably high rate of systems development flops and failures.  According to recent research by Oxford University and McKinsey 87% of IT projects with an investment of more than $15 million fail and 23% of IT projects run more than 80% over budget[1].

As recent data in the Insurance Industry from Forrester shows there is little consensus on what to do.  Of the respondents almost half have either no defined approach to systems development or are using waterfall, which was forward thinking in the 1970’s.  Encouragingly, half the industry is trying to control the scope of efforts, keep failures scope-boxed and time-boxed through some version of Agile or Iterative development. There are many versions of either.

Forrester bar chart

In the Insurance industry the challenge tends to be implementing a functionally rich “core systems” solution managing the relationship from policy issuance through claims; similar in scope to an LOS in mortgage or an ERP in manufacturing and distribution. In an attempt to be responsive and modern, nearly all of the insurance solution providers will state that their implementation methodology is based on Agile.  Some are more “pure” Agile than others.  Regardless of their orthodoxy the challenges can consist of the following:

  • Failure to recognize the business users commitment levels required for true agile development.  “Product Owner” means something critical.
  • Missing requirements due to not understanding the entire insurance value chain. An example is defining a unique, strategic distribution channel but not understanding the need and role of CRM in it.
  • Called what occurs with core systems “development” is a challenge. Clients are licensing commercially available solutions that have significant functionality. The task is configuring, feature selection, enhancing with add-ons.  It is not “green fields.”
  • Cost – These implementations are expensive.  It is not unusual for regional players to spend $6m to implement a claims module.  Mortgage originators spend similar amounts on POS and LOS solutions.  As a share of revenue or equity these are substantive efforts.
  • But, due to the perspectives of the teams doing the work and the lack of proper business participation the requirements are not aligned to business and projects all too often fail.

For these reasons we find it imperative to work from an Agile Feature-Driven Development “AFDD” Approach. Key elements include:

  • Stringent alignment of business processes to system requirements.

You need a process driven approach to requirements identification and prioritization.  Inherent to this are dynamic reusable business process models that drive the identification of services, appropriate flexibility and reusability, alignment with enterprise business process management systems, and the identification of tangible benefits and requirement prioritization

  • Focus on the features of the solution – the prioritize requirements are then assess to the base features of the solution.  Gap analysis and development dependencies are identified and estimated
  • Testing of features are driven by the business processes / requirements

We believe there to be 5 main phases of Feature Driven Development, the middle three are most classically “Agile” and the first and last phase are traditional in their structure. In our view, Feature Driven Development requires, it is based on, starting by clearly understanding the business requirements and features for the new solution. The process begins with requirements from a business perspective and develops an executable roadmap and governance for a successful implementation.  Whether your business direction is described in products and markets, Critical Success Factors, or Strategic Vectors and Do-Wells, that direction defines and informs things the business needs to have and do.  Those things drive the roadmap.  This is not an “Agile” process, it has a timeline of its own[2].

SAFe process

In Elaboration and Design those business requirements and feature definitions are extended and verified.  Missing business requirements and features, user experience descriptions, system integration and potential data conversion routines are discovered and documented. This phase takes a good idea and creates a definition of a “whole product.”  The scope of what must be done is clear enough from the Inception Planning that the Elaboration can be properly “sized” and structured. This is an iterative, “agile,” sprint-driven process, time boxed with “product owners” approving the work to be done and the results from each sprint.

Configuration and Construction involves a series of “traditional” Agile sprints, coordinated around the defined features, the “release train,” to deliver what is defined as the business objective.  Since the construction is Feature-based so is the Testing and Acceptance of the solution (feature or full solution) in a control and predictive environment.  This includes user acceptance test and performance test.  Once this phase is complete the system or feature of the system is ready for deployment.

This is an “agile” approach.  It expects that the initial design may mature during the development process.  It also expects that despite best efforts of all parties some of what is built is different from the intended design.  For these reasons we recommend conducting a product pilot test in a control production environment.  During this test resources are assembled to quickly resolve and business or technical issue raised during the pilot period.  Once this has been completed the system is ready for deployment.

For Core Systems efforts we favor Feature Driven Development because it minimizes unconstructive “green fields” thinking in a known space while maximizes the inventive, iterative, differentiation of deployed feature/function that Agile emphasizes. The resulting implementations are more focused on delivering solution features that are aligned to business concepts rather that counting the number of story points that have been delivered. Business people can better understand the project status and can react accordingly.

Jim Anderson
james.anderson@returnonintelligence.com
(610) 247-8092


[1] The Art of Project Portfolio Management by Meskendahl, Jonas, Kock, and Gemunden

[2] There are methods, like Dean Leffingwell’s SAFe, which attempt to use Kanban methods to add Agility in this phase as well

Tweet about this on TwitterShare on LinkedInShare on Google+Share on TumblrEmail this to someone