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
(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

A Model for Transition to IoE in Manufacturing

In a recent interview, executives from Robert Bosch GmbH and McKinsey discussed the Internet of Everything (IoE) and its impact on manufacturing.  They described significant changes to the production process and to the management of supply chains from this “fourth industrial revolution.”  The IoE allows for the interconnection of factories within and across regions and the exposure or “display” of the status of each component of each product for each customer via each distribution method.  Sensors in machines and in components will be able to keep universally in synch about what has to be done, what has been done and how well it was done.

A global decentralization of production control is now possible. Creating this reality will require new forms of intercompany and interdisciplinary collaboration.  The buyer, seller and distributor will all be involved in product design, engineering, and logistics.

GE Industrial InternetToday, physical flows and financial flows and information flows are different for manufacturing.  The IoE vision has them increasingly fusing together.  This transformation to what GE calls the Industrial Internet begs a set of questions: In this future how will orders be placed and with whom?  Who or what verifies the accuracy of an order or a deliverable across a network of suppliers, manufacturers and distributors that is formed, of an instant, down to the level of at an order at a time?

In this coming future state information, via the cloud, will be real-time available to all concerned parties.  The decisions to be made based on this information will be subtle, situation-sensitive, and so voluminous and time dependent that people won’t be making them. Algorithms running in machine-machine (M2M) systems will.  On first consideration this all seems overwhelmingly complicated.  We’ll need a model, an example to build from, on how to make the transition.  It turns out we have one.

Changing the trading cycles for Wall Street are recent, real examples that provide a roadmap for the manufacturing transition.  In that world the number of days allowed to settle a trade, the “settlement cycle,” has undergone major transitions. The most notable was from 5 days to 3 days, so-called T+5 to T+3, occurred in 1995. That change required almost every firm in the US to make some changes to their processing flows and systems.  Since the move to T+3 various exchanges have made further improvements towards T+1.  The table below shows some of the major changes, the before and after, that were accomplished:

T-5 to T-1 Table

T+1, even if never mandated, can be viewed as an example of industry opportunity through dislocation. At some level, IoE capabilities can enable dramatic cycle time gains by unlinking end-to-end dependencies (e.g. I no longer need to “affirm” trades based upon evaluating “confirm trade” messages). Some entities/roles will become more independent, some more dependent. Some may disappear if they no longer add value.

The parallels for manufacturing in an Internet of Everything world are clear (though some elements used in trading may not be used here or at the same level of emphasis).  Cross-industry governance will be needed on the format and import of transactions, acceptable technical modes of sending and receiving the messages, management of the quality and timing of the messages both in content and technically, and how to handle disputes.

Douglas Brockway

Ira Feinberg

July 16, 2015

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