Following is the first of two lightly edited excerpts from Patricia’s recent presentation at the Gurobi Decision Intelligence Summit in Las Vegas.
In most corporate IT departments you see Agile everywhere, but many of us remember when that was not the case. Agile Software Development began, or at least coalesced, in 2001 at a meeting in Snowbird, UT and the creation of the Agile Manifesto (see this short history https://www.agilealliance.org/a-short-history-of-agile/). But it took years to become popular and broadly used; when I started as an optimization practitioner and technology consultant in 2007, the dominant methodology was Waterfall, which had taken root during the 1970s (see this interactive history on LinkedIn .)
Waterfall appeals to many developers and analytics practitioners because it calls for the requirements to be determined upfront. More than a few have asked, “How am I going to build a model if I don't know what I'm building?” It’s like being asked to draw a map without knowing the final destination. Waterfall takes care of that—in theory. We developers and modelers would sit with the users for days and weeks, watching them work and studying their processes. They told us everything they wanted up front, and we built it and created the formulation.
When we consider its stages, Waterfall is linear and sequential.
Throughout there is a lot of required documentation, including a granular project plan, detailed functional and technical designs, and user manual. This documentation provides a sense of security, that the team has done its due diligence based on the “thud factor.”
My colleagues and I—and I can assume many other practitioners—after completing a Waterfall project, have experienced the challenge that the requirements we gathered in our initial sessions with users did not yield a product they could incorporate into their decision-making process and workflows, or the recommendations were not implementable in the “real world.” There are many reasons why this happens: business processes can change over the course of a long development cycle and users sometimes think they need a specific requirement until they see it in action. Or very commonly, users may not be able to identify the full requirements until they start interacting with an application and its recommendations. It can be challenging for a business user to describe what makes a good or bad solution; they will know it when they see it. In one extreme case, after we delivered the model over the course of a long Waterfall development cycle, the users informed us it did not fit their process, so we had to redo the entire model. Waterfall is notably problematic because of late issue discovery, the lack of user feedback during development, the risk of misalignment, and inflexibility.
Agile development is more flexible—in theory. There are fast iterations, frequent validation and user engagement.
In my experience, the holy grail of modeling is user engagement. I like to sit with users and work with them daily. This interactive partnership can be a challenge: in talking with OR executives, I know they struggle with business engagement. One practitioner at an entertainment company told me his group continuously comes up with innovative ideas, but it is impossible to get business sponsors to meet with them because they have other priorities and are too busy. Agile prescribes the product owner, the client executive who sits with you in every sprint, attends ceremonies, and works with you.
My colleagues and I love Agile’s continuous improvement model. However, we are always vigilant about scope creep. In Waterfall, we would design everything, allocate a certain number of months for development, and feel confident. In Agile, during a sprint cycle, client executives may recognize changes they want that can add to the scope and complicate the project timeline.
Agile creates the potential for fragmented vision, particularly with an optimization model. When adding constraints, for example, it is important to be measured and mindful of the whole model, so that the fundamental formulation choices like decision variables still work.
When I first used Agile, because I came from an OR background, I was struck by the quantity of meetings. There are multiple ceremonies for each sprint. Planning, standups, the demo, refinement, retro... There is a lot of overhead. But Waterfall has a lot of overhead as well, just in stages rather than spread out across the development lifecycle.
Agile does not mean your direction and destination are unknown. There is Program Increment (PI) planning, a key element of Agile, particularly in the Scaled Agile Framework (SAFe), which has the following characteristics:
- Ensure alignment with business objectives
- Big picture focus
- Clear vision and roadmap
- Prioritization of features
- Manage dependencies and risk
To clarify, Agile does call for a roadmap, but there is flexibility in it, so you can account for dependencies and data sources, for example, as they are worked out. Modelers certainly want to avoid waiting a long time for the right data.
Why Agile for Optimization?
Agile embraces the complexities and evolving nature of optimization models, leading to better outcomes and user satisfaction.
Optimization models often involve complex variables and constraints that require frequent recalibration, which can be a challenge in Agile. However, its iterative approach allows for the continuous refinement of models, incorporating new data, constraints, or requirements.
Unlike traditional software, optimization models need ongoing validation to ensure they accurately represent the problem space and deliver optimal solutions. To secure frequent validation, we leverage smaller, incremental releases so even partial solutions can be tested and validated quickly, providing immediate value to the user and ensuring that the model remains accurate and effective over time.
User requirements and business environments can change rapidly, requiring the model to adapt accordingly. Through Agile-prescribed frequent interactions with users, we practitioners ensure that the model is aligned with real-world needs.
Let’s consider three examples in which Agile for Optimization was successful.
Case 1: Faster Delivery of Value
At a broadcast TV network, advertising analytics leadership wanted to optimally assign ad slots to advertisers to maximize the expected outcomes within a supplied budget. It was an innovative multi-objective solution that they hoped to attain quickly. While they sought to source a key, complex piece of data, our team decomposed the model and created a simpler Minimum Viable Product (MVP). We were able to focus and perform interim enhancements to incrementally increase the complexity. Client executives accepted the MVP right away and even used it while they tried to source the data and initiate organizational change management.
Often, a business process needs to change for a trailblazing optimization model, particularly when the organization has not optimized the process previously. There are business executives working with their spreadsheets, doing their own thing. Change management practices are required for adoption. In this example, our modeling team kept delivering value while helping the client institute suitable change management.
Case 2: Enhanced User Engagement
I was on a team that was optimizing railcar fleets. Executives at the client, a railcar pooling company, were charged with assigning different automotive-dedicated railcars to railroads at varying times. It was a critical business decision because if railroads lack railcars, they cannot serve their customers.
As we built our model, our team used a test data set of a few customers because the automotive rail network, with factories and dealerships, was quite dispersed and we could not source all the necessary data initially. Moreover, the data required a lot of cleaning. We saw positive results right away, and prioritized presenting them to a client executive, a key user, who was notably skeptical about our ability to optimize the problem.
The very first time I engaged with him about the results, he said, “That’s not bad.” To me, that was the highest praise! Early on, with limited data, we had secured buy-in from an influential skeptic. Ultimately the project was highly successful, yielding $35 million in savings and improved asset utilization in the first year.
Case 3: Early Issue Identification
We were working with a biomanufacturing startup that performed personalized cancer treatments using patients’ blood. Our project was to optimize product flow through the highly specialized facility, which featured very expensive equipment.
The product, made of human cells, was perishable. We were optimizing a schedule for a process that included thawing and freezing. At the beginning of the project, I asked client executives if we should include personnel in the scheduling model. They told us to focus on the rooms and the equipment. Sure enough, when we presented an optimized schedule, they changed their minds and said without the personnel, the results did not make sense, and the solution was not actionable. Because we were Agile and got this feedback relatively early, we were about to reformulate and stay in the project timeline. By the way, that startup was eventually acquired for $7 billion.
Conclusion
I hope you and other optimization practitioners recognize that the advantages of Agile outweigh the disadvantages, provided you use best practices such as iterative development, frequent validation, user‑centric approach, and continuous improvement.
In our next blog post, Patricia explains why many optimization practitioners are still resistant to Agile, and she presents key practices to overcome project obstacles. Email us to set up a call with Patricia about Agile.