Tales & Tips from the Trenches: Agile Principles in Data Projects, Part 1

COL01x - image - EDWelcome to our new column, Tales & Tips from the Trenches. Written with contributions from authors with many years’ experience in Enterprise Data Management, this column will be rooted in Case Studies, where we will share lessons learned from work “out in the field.”

This issue’s column begins a new multi-part series about integrating Agile Principles in Data Projects, which builds on two interesting articles from the last two issues of TDAN on Agile Project Management, found here: Part 1 and Part 2. We will illustrate various ways that we can apply Agile principles in many kinds of data projects, including data development and data management. We will also examine what Agile means to data practitioners.

There’s a lot of fuss about “Agile” in software development. First, it is important to define “Agile.” Part 1 of the article mentioned above sets the stage very well:

“…Agile software development and project management are a group of related behaviors, frameworks, techniques, and concepts that fundamentally favor the delivery of the right working software as early and as frequently as realistically possible.”[2]

Agile is not one specific methodology, but many. It is important to familiarize the data practitioner with the benefits of Agile to capture its overall vision. Once familiar with the benefits, the data practitioner is in a better position to explore the ramifications for data projects.

Agile methodologies:

  • Involve collaboration
  • Include both requirements and solutions that continuously evolve
  • Present candidate solutions early, which can be changed
  • Include development that progresses through successive iterations

“…It promotes adaptive planning, evolutionary development, early delivery, and continuous improvement, and it encourages rapid and flexible response to change.”[3]

In the past, software systems were usually built as “Big Bang” projects. They were very complex and time consuming to develop. Couple this with the fact that requirements are difficult to pin down and difficult to extract. When the system was finally delivered, it seldom met the business needs successfully because requirements were not agreed upon nor captured.

Constant change of the underlying business is another factor that interferes with accurate requirements gathering. This means not only that requirements are difficult to decipher but also that the requirements gathered today may not be accurate tomorrow. Business often evolves beyond when the requirements were gathered and while the Big Bang solution is being developed, so when the product finally arrives, requirements have changed and the developed solution is no longer adequate. It follows, then, that the system built based on those requirements will not meet the needs of the business when it is delivered. The system goes “legacy” the day that it goes production.

Big Bang software projects are laborious. Large software projects are extremely complex and difficult to build. The business often feels that the development of these projects occurs in a black hole; they provide requirements, time passes, and eventually they get a software system. They often feel they are not part of the development process, and when the system is finally delivered, they are disappointed.

Hence, Agile was born, to address some of these issues and to develop a faster solution better able to meet business needs. Agile’s goal is to present business stakeholders with part of the solution early so they can derive some benefit while the rest of the solution is being developed. The aim is to deliver smaller chunks faster, to get a partial solution in the hands of users so they can help to tune it, feeding into the process their feedback while using it to conduct their business. A vital part of this process is involving the business stakeholders in the development process itself. In doing so, they will have not only ownership but also influence on the outcome so that it meets their needs.

Many business stakeholders are visual. If you present them with a screen, prototype, visual, or strawman early on, this can help them determine what they want. Having them use the system to get work done will influence even more the outcome of the final product. Thus, they can start using part of the application immediately so they can derive benefit from it early on, while it is still being developed. It provides business stakeholders with better visibility into the project build process.

This ultimately translates into significantly reducing the risk associated with software development, while at the same time accelerating the delivery of initial business value. Providing an iterative planning and feedback loop allows project development to align more closely to business needs by “…easily adapting to changing requirements…”[4] The chances of a solution that conforms more closely to the customer’s needs is greatly enhanced by these factors.

It sounds like a win/win for both business stakeholders and technical personnel.

In my next column, I will address Part 2 of this series and address the Agile-Data Disconnect. Looking forward to seeing you there.


References

[1] The author’s affiliation with The MITRE Corporation is provided for identification purposes only, and is not intended to convey or imply MITRE’s concurrence with, or support for, the positions, opinions or viewpoints expressed by the author.

[2] Barnes, Paul. “Introduction to Agile Project Management, Part 1”, TDAN. http://tdan.com/introduction-to-agile-project-management-part-1/20937

[3] Wikipedia, “Agile Software Development”, accessed 2/14/17

[4] “The Benefits of Agile Software Development”: VersionOne. https://www.versionone.com/agile-101/agile-software-development-benefits/

Share

submit to reddit

About Bonnie O'Neil

Bonnie O'Neil is a Principal Computer Scientist at the MITRE Corporation, and is internationally recognized on all phases of data architecture including data quality, business metadata, and governance. She is a regular speaker at many conferences and has also been a workshop leader at the Meta Data/DAMA Conference, and others; she was the keynote speaker at a conference on Data Quality in South Africa. She has been involved in strategic data management projects in both Fortune 500 companies and government agencies, and her expertise includes specialized skills such as data profiling and semantic data integration. She is the author of three books including Business Metadata (2007) and over 40 articles and technical white papers.

  • Chris Pehura

    What we have to always remember that Agile came out of practices that have been around since the ’60s. For some reason people forget these tried and true practices and then rediscover them, brand them, and put them into a framework or body of knowledge.

    There is a rich history of how these this practices are effective. Very few are taking advantage of this knowledge.

  • Steve Corcoran

    I’ll look out for the next installment covering the ‘disconnect’. From
    my perspective – working as a Data Architect in a Data Goverance team –
    I’m currently working to get Agile teams/projects to embed a better
    understanding/consideration of the “data aspects” of the development
    work including good business-related data definitions, data models, data
    flows, mappings, lineage… the other side of the same coin perhaps?

    • Bonnie O’Neil

      Yes! I will address these things, such as reuse of the enterprise data model, in upcoming columns. Business related definitions are Key! This is a good reminder. One of my favorite subjects!

Top