The Intelligent Data Management Blog

Put some Agililty in your MDM Mix [Part 2]

This post is the second part of a series defining the use of Agile methods (Extreme Programming, SCRUM) in the context of MDM Projects. Read the First Part Here.

Agile MDM: Challenging Differences

There are challenging differences between MDM projects and typical agile development projects.

Agile projects assume a very simple customer/developer relationship. To simplify, agile methods consider an ideal situation where "a benevolent customer works with a small self-organized team of great developers".
Political, people, processes and other organizational issues and considerations are major challenges in MDM projects, and even more when MDM is part of a larger data governance initiative. Communicating with "the customer" or building a "great development team" is complex. Besides, self-organization would be an exception in MDM/Data Governance initiatives. In the MDM world, organizational matters are way more complicated and organization tends to be more in a "command and control" style.

MDM Projects are not standalone software products. They have strong dependencies on other projects (BI, Integration, Profiling) which are not necessarily using agile methods. The project interactions and dependencies need to be taken into consideration in the project planning. Planning in an MDM context is unlikely to be a simple sequence of "one month or week development sprints" as expected in agile methods.

Time-driven (Agile) vs. Requirements-Driven (MDM): While agile methods focus on using time for delivering a working product (and possibly postpone some of the requirements), MDM has a stronger focus on meeting the requirements (and possibly postpone the project release date). Both MDM projects and agile methods aim at delivering value to the customer, but using different approaches.

Working with Agile Methods in MDM

With these challenging differences in mind, there are factors that make Agile MDM work.

Agile Mediators

Agile methods work when developers work in close loop with customers (final users).
In an MDM project, the "customers/stakeholders structure" is more complex than one average end-user. Developers put in direct contact with these would face political, organizational considerations they should not cope with.

In this context, a mediator is a base requirement to handle the communication and the ever growing list of requirements. This mediator role is extremely close to the Product Owner as defined in the SCRUM methodology:

The Product Owner represents the voice of the customer and is accountable for ensuring that the Team delivers value to the business. The Product Owner writes customer-centric items (typically user stories), prioritizes them, and adds them to the product backlog.

Adaptability (aka "Please Use Your Common Sense" rule)

Agile is a method to deliver value to the customers, not a dogma. So if you need to give up some of its aspects for the sake of the project, just do it.
A few examples:

  • "Organize a team" instead of "have a self-organized team" to reassure your executive sponsors and keep things under control.
  • "Adjust the release planning" to work with the entire ecosystem of projects.
  • Use different methods/models (waterfall for example) for parts of the project when they fit better.

Use an Efficient Platform

The tooling is key for agile development, as you cannot be truly agile with lead shoes. The platform used to develop and deploy the MDM project should provide key features to enable the agile method:

  • A metadata driven approach (Logical Model + Business Rules) coupled with strong generation capabilities to enable a fast path from design to deployment. Cumbersome developments required for implementing the physical model, the enrichment, quality, matching, and consolidation processes should be handled by the platform, and not manually by the developers.
  • Native support for fast iterations in a safe and efficient way. The tooling should natively handle metadata version-control at design and run-time with no additional efforts from the developers. The tooling should also support data version-control as part of the delivery process.

A Tooling not providing these fundamental features would be an impediment to the adoption of an agile method for MDM.

A great thank you for those who came back to me with their experiences and feedback on Agile Methods and MDM! I encourage you all to discover Semarchy Convergence for MDM, the Evolutionary MDM Platform that enables Agility in your MDM project.