Welcome 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/
Approved for Public Release; Distribution Unlimited, Case # 17-1619.
©2017 The MITRE Corporation. All Rights Reserved.
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.
