AI and Agile: The Quest for Optimization. Interview with Piotr Majchrzak, Boldare Co-CEO

Paweł: Could you describe the challenges our clients are currently facing? I’m interested in the types of solutions they are seeking when they reach out to us. Have you noticed any emerging trends?

Piotr: Of course - in times of crisis, market trends reveal significant volatility and growing concerns. So currently, when someone comes to us for software-based solutions, they are looking to optimize their operations in the first place, not to invest. They seek a partner who delivers greater value. Clients come to us not only for executing well-understood software components—tasks they could potentially manage internally—but for holistic solutions to their problems. For instance, they notice their competition offering less expensive solutions and realize they need to respond somehow. Like the telecom industry client who approached us, noting, “Our services in Poland are becoming more expensive than similar services in Germany. Can you help us address this?”

In this scenario, the client recognizes an opportunity in AI. He understands that this emerging technology could potentially streamline his operations, either by reducing the number of staff required or by scaling the business without increasing the workforce. Consequently, he approaches us, stating, “Okay, help me achieve this, as I don’t have ready-made solutions.”

Another aspect is that our clients, those we are currently working with, prefer shorter and quicker timelines. They aim to mitigate market-related uncertainties by planning investments or optimizations within a quarter, instead of extending over 6 or 12 months as previously. This puts companies under pressure to deliver promptly, yet they are keen to streamline and launch products quickly, ensuring the flexibility to pull back from investments if necessary. It appears that this is the trend influenced by recent market shifts—decision-makers are increasingly seeking faster end-to-end solutions, from concept to ROI.

Paweł: Why do decision makers, aware of technology like AI, hesitate to implement it even after recognizing its potential? What holds back their investment in exploring these solutions?

Piotr: You know, it depends. Right now, decision-makers are recognizing tools like ChatGPT and Midjourney, similar to how we first saw the Macintosh that Steve Jobs introduced. Initially, they’re impressed—”wow, you move the mouse around, it’s amazing!” But then they wonder how to leverage this for their company beyond the novelty. We’re at a point where we need more applications that showcase what these tools can really do in a business context, much like how Word and Excel made computers essential in offices.

Right now, we don’t have enough of these applications. This is where our company steps in: to help businesses stand out by creating custom AI solutions tailored to their unique needs. The challenge is not just the lack of applications but also a lack of awareness or companies willing to explain how AI can be practically applied. So, adoption is slow, and it feels like we’re in the early days, where decision-makers know the technology’s potential but don’t see how to apply it practically within their operations. It’s about moving beyond seeing AI as just a tool and starting to envision it as a solution woven into the fabric of their business strategy. But we’re getting there, slowly but surely.

You might be also interested in the article:

Case Study: Empowering Users of a Building Materials Trading Platform with a Smart, AI-Powered Assistant

Paweł: Given the current market volatility and the need for innovation, particularly in AI, how should decision-makers strategize to achieve a market advantage?

Piotr: In such cases, I would try to make sure the investment matches its worth so we can see the benefits quickly. It’s also important to keep checking if it’s still useful. Basically, this is what Agile is all about: making small deliveries and then seeing how valuable they are.

Sometimes, doing nothing is an option. But during a crisis, the best chances for growth often show up. Just saving resources won’t cut it.

There are always chances to get ahead of others. My suggestion is to find important areas where you can turn the pressure from the market into your advantage, like using IT to save money. That’s my advice.

Paweł: Based on our clients’ experience, can implementing AI technology in products and services actually lead to savings or profits, or is it still too early for investment and monetization of this technology

Piotr: You know what, for me, investments are not a lottery. Of course, there’s a big element of uncertainty, but it’s not gambling where we just throw the ball into the roulette and see what comes out. So, of course, building a business case for each company before they start doing anything is kind of the basis. And here I’m going a bit into details, explaining what I mean because generally, when we ask clients if they want AI, they say, “Yeah, cool, why not?” Now, I don’t know if they are enthusiasts or skeptics. But generally, the outcome is the same: “Okay, but how does it work for my business?” And that’s OK, because there are not yet many practical solutions in the wild.

Of course, we have access to various products, including Chat GPT, in which we see potential. However, the challenge lies in establishing a direct connection on how it can specifically benefit the company and adapt to its processes.

So there’s a broad area yet to be explored in AI applications and ways of monetizing them. When we shift the question from whether clients want an AI solution to whether they want the benefits associated with AI implementations, they readily agree. The specifics of the technology we select become secondary to them after seeing the results. For instance, we presented to an e-commerce client how we could generate SEO-friendly descriptions for thousands of products on their platform using AI, all within a week or two. Without AI, this task would have taken months and cost more than developing a new e-commerce platform from scratch. The client immediately saw the value, and we could implement the solution.

Just recently, we had a similar situation with a different client for whom we created a voice assistant. Technical details are not as important as the results and business benefits, which can be really impressive. This seems to be a fair approach.

When it comes to optimization, software itself acts as a lever through which people can perform their work faster or better. Similarly, AI represents a branch that today evokes a “wow” effect due to its novel applications. Initially, we adopt the technology, encountering numerous use cases that once demanded substantial effort but are now readily available and comparatively affordable. On the other hand, “traditional software” remains essential and will continue to be used in thousands of scenarios, including optimization.

In my opinion, the key to getting more from innovations like Gen-AI lies in achieving more through faster, more frequent deliveries that allow us to validate business or technological assumptions more quickly and cost-effectively.

This idea is at the very core of the Agile approach.

Paweł: Agile effectively manages uncertainty, quickly delivers value, and allows for plan adjustments, such as evaluating AI investments. On the other hand, there has been quite strong criticism of the Agile approach lately, containing many accurate observations. How do you respond to Agile criticisms and its current state? Is there a need to enhance or replace Agile, or is it still effective?

Piotr: First off, I think we shouldn’t overestimate Agile - there’s no silver bullet that will take and execute any project right now. Whether it’s Agile or Waterfall, a lot depends on how it’s executed. I’m also far from saying that Waterfall doesn’t work or that Agile doesn’t work. My thesis is that people actually talk about the execution of certain projects and categorize them as, “Okay, this was done in Waterfall, and that’s why it didn’t work”, or “It was done in Agile, and that’s why it didn’t work”. So, the execution of an idea often influences us to oversimplify and say that now this idea doesn’t work, or that one idea will save us, and another will doom us.

Surely, in the last ten years, there has been a significant shift from the Waterfall approach to Agile, as the world needed a method capable of handling risks often unknown at the start of a project. It’s impossible to predict everything at the start, especially product development, we’re unable to predict if, for example, a new competitor will emerge, or a new technology will appear, or other variables will come into play.

You might be also interested in the article:

What should every decision maker know about the Generative AI revolution?

Like with any trend, I think we’re at a point where we start not only to praise Agile and its benefits but also to recognize its shortcomings. I would say that Agile is performing just fine, but there’s an even greater need to execute it well, to adhere to its principles, such as iteration and software releases. So, in my view, it’s doing great. However, in times of crisis, there’s a need for certainty due to the prevalent uncertainty in the world. Thus, a company can address this uncertainty risk precisely by having a fixed contract and a fixed budget to gain more certainty. And by definition, Agile isn’t capable of defining, for example, the outcomes of a product at the start, so this uncertainty can’t be documented.

Therefore, today, a more structured approach is valued more because decision-makers need something stable, such as costs. Looking at Agile, by definition, we aren’t able to define much. But having said that, there’s still a whole spectrum of Agile because here at Boldare, we really care about the client’s budget. And with the project management triangle (time + money + scope = quality) in mind, I believe that agility doesn’t mean having an open budget and open time, so the team could chill while doing their work. It’s not a free ride.

We’re not in the business of free rides and we often advise our clients that an excessively large budget for some specific components is simply too big.

Agile-based work or problem-solving must be tailored to specific objectives, offering various strategies for achievement. Yet, despite its flexibility, goals need to be met within set time and budget limits. This method blends Agile’s adaptability with strict constraints to guarantee project success. And I think that people who say Agile is dead are talking about an Agile that lacks a budget, deadlines, and has an open scope, and that this approach is dead. But it has always been dead to me because that’s not a method for executing certain things

To sum this up: it seems to me that the problem is that people may think having every piece of the project management triangle fixed is a healthy response to some uncertainties that Agile offers. But it’s somewhat deceiving ourselves—if we were to start delivering digital products with a fixed scope, budget, or time frame for six months, it might look great for the budget, and we could fit into the deadline, but it won’t deliver the final value the clients expected or maximize those values in such a way. It’s because the value comes from understanding needs and adjusting to the new knowledge we gain throughout the process.

Paweł: You mentioned some drawbacks of Agile and I wanted to dive deeper into that. Agile is mainly theoretical until put into practice, which makes it tricky to fully understand its impact. Are there any aspects of Agile that are often misunderstood or misapplied?

Piotr: It’s probably like with everything; the biggest misuse might be treating something as a religion, interpreting various books without context. So, for me, the first sin is trying to turn Agile into some sort of guideline because it’s simply easier for humans to stick to simple rules. Through such thinking, we start forgetting what it means to be agile, which can lead us to thinking that Agile is a free ride, where we don’t manage the process, don’t follow deadlines or budget restrictions, because this would be too rigid, “not agile”.

This ties into what I consider the second misuse of Agile: that Agile sometimes lacks boundaries. Of course, programming is built by people, and they need to be synchronized. There’s a lot of work beyond the programming itself and the hard project management stuff. Here, Agile is the opposite of Waterfall, which is very focused on processes and creation, where the human element is practically non-existent. Agile, on the other hand, in a very simplified manner, focuses on building teams and the people who build products. I think we go too far with Waterfall, forgetting that programming is built by people, that they need to be synchronized, and there’s a lot of work beyond, how to call it, the hard project management stuff. Whereas today, as an industry, we expect from Agile teams that they will always deliver quality and that they will magically start doing everything right from the start.

I will always lean more towards Agile because it’s the idea I follow naturally, even before I fully understood what Agile was. However, I believe Agile lacks in setting those boundaries. Sometimes, we need to expect others, such as team members, to come up with something better or different. In traditional project management, it’s the project manager’s role to specify tasks. Yet, in Agile, we often struggle with healthy communication, whether it’s with product owners, clients, teams, or within our own team. Consequently, in challenging situations, instead of maintaining our roles or the necessary boundaries we need to operate within—often crucial for innovation once we overcome the initial shock—we start dismantling them, and then the entire structure collapses.

Agile is not as ‘soft’ as some may think. It’s perceived as outdated by some because its flexibility can be mistaken for weakness. Yet, much of Agile’s effectiveness depends on how it’s executed. Fixed-time, fixed-scope, and fixed-budget contracts are often more readily accepted, offering a sense of security, especially in times of crisis. This approach may seem safer for businesses in the short term, but it comes with its own challenges, like the potential for illusory safety or overlooked details. Currently, there’s a general preference for the assurance these fixed parameters provide, despite the risk of missing the adaptability that Agile offers.

Paweł: For me, Agile has always been excellent as an approach during times of crisis because it enables quick withdrawal from a bad decision. However, it seems that during crises, decision-makers prefer approaches where the outcome is known in advance, so they look at Waterfall approaches more favorably, even if they don’t know about Waterfall and agility. How do you see it?

Piotr: Selecting the best methodology for a new project can be tricky, focusing on scope, budget, and timeline. Agile is flexible and allows for quick project launches, yet some clients might miss the detailed planning offered by Waterfall. However, Waterfall’s detailed planning process can delay the start and be rigid against new ideas, possibly leading to a mismatch between what’s expected and what’s delivered. Waterfall spends a lot of time upfront on design, which is essential but costly and doesn’t provide immediate visual progress like Agile, where results are quickly visible.

On the other hand, shortening Waterfall’s long planning phase to a few weeks raises expectations from clients for a fast start, like, “Let’s begin immediately after a day’s workshop.” But rushing can cause misunderstandings due to a lack of detailed agreement, risking divergence from the client’s vision. And, in fact, it might lead us to a conflict, whether to stick to the original plan and just deliver what we were supposed to, or maybe extend the budget or change something in the product’s scope.

Of course, Waterfall can be effectively managed. It requires more time, especially when initial estimates, say, for a six-month development, need adjusting. If, along the way, you realize that certain features are no longer needed, this necessitates a return to the drawing board and the planning. Consequently, this might also mean renegotiating terms within the contract. Thus, any significant modification typically needs at least two weeks for proper adjustment. Faced with such changes, you might opt for a more Agile approach, encouraging open dialogue to expedite the process, or you might decide to absorb additional costs to ensure the final product strictly adheres to your initial specifications and meets your expectations.

Paweł: Let’s get back to the optimization topic. What do you see as the main tools for optimizing costs and processes? It’s a very general question, so you don’t have to limit yourself to any specific topic.

Piotr: The main tool is delivering as quickly as possible, right? To deliver quickly, everything must be thoroughly segmented, and dependencies eliminated. This fits, from my perspective, into Scrum and Agile, but taken literally, it doesn’t deliver this value by itself. Thus, we return to our basic methods and books that have compiled knowledge, allowing us to stand on the shoulders of those who developed them. The first thing is Lean Startup. Essentially, the entire Lean concept from Toyota, even Lean Software Development, is about continuously identifying where we’re generating waste, starting not by thinking through features alone but by what goal we’re trying to achieve.

From my perspective, one of the most underrated optimization tools is letting people talk.

Yes, it’s a very humanistic concept, which seems odd in times of crisis when action is required. Yet, paradoxically, when I see the best teams, which delivered exceptionally and delighted clients, they were teams that, for me, never stopped talking. This paradox, which never ceases to amaze me, shows that a programmer is not a machine that takes in coffee and spits out code. Instead, they’re a machine that takes in coffee, analyzes the client’s problem, processes it through the minds of their teammates to find the best solution, and only then codes it. This approach often allows a team to find better solutions than anyone could have individually, producing less code. Because another paradox is that the art isn’t in producing a large amount of code but in delivering something in the fewest lines of code that solves the problem. Simplicity is the ultimate sophistication. Economically, generating code then means it must be maintained. If someone wants to change something in the code, it must be read, impacting its further development. So, for me, this tool is team conversation, but when we add the client, or business team into the mix, even greater magic happens.

In simple terms, the idea is for the team to fully grasp their goal, rather than just getting a small part of the job. This understanding is a big step forward. Then, ensuring they have the working conditions to brainstorm solutions on the fly because that’s the discussion with the team, right? Talking not just within the team but with the business, maybe delivering something simpler a week earlier and a fuller version in the second week could be beneficial. This is where you can win. And once this complex machinery starts working, significant optimizations can be achieved. So, in today’s online environment, transparency and the flow of information are crucial. At the same time, as we’ve discussed earlier, the team must be highly accountable for their work, so tools should clearly show work progress, where the team might be struggling, where risks lie, and if they are being resolved.

Simple methods don’t show everything clearly, but things like burn-down charts, outcomes from retrospective meetings that aim for improvement, again leaning on Toyota and others, can help us identify where we’re losing, what needs to change, making it transparent. And whether at the beginning or as soon as possible, release because if we release something cool within a week, we can gather feedback faster and create something closer to what the world needs the next week. If we base our work on guesses, we might spend 3 weeks on something and then realize it’s not what was needed.