Agile Discipline, Transparency, AI and Metrics | Alex Polyakov

112

---

In this episode, Alex Polyakov, founder and CEO of ProjectSimpl.ai, discusses his career journey and the software his company is building for agile development teams.

Alex is a multifaceted professional and has had a diverse career journey. Over the past two decades, he has worn various hats, from Application Developer to Solutions Architect, and Startup Founder.

Currently, Alex leads a company called ProjectSimple.ai that aims to revolutionize software development. Their mission is to enhance teamwork and transparency while providing GPS-like guidance for software delivery. Their innovative approach helps address development challenges and mitigate risks, all powered by AI.

In addition to his entrepreneurial endeavors, Alex hosts a YouTube channel called “Let’s Talk Agile,” where he delves into software development topics. If you’re interested in collaborating on an episode, don’t hesitate to reach out!

Takeaways

• Agile is a discipline, not just a methodology or framework.
• The focus should be on solving real problems and driving change, rather than perfecting the process.
• Choosing the right methodology, such as ScrumBan, can improve team collaboration and efficiency.
• Transparency and visibility are crucial in software development, but the metrics and tools used should be tailored to different stakeholders.
• Building discipline is crucial in teams, and it requires encouraging participation from all members.
• AI can be used to improve predictability in project delivery by analyzing data and providing alerts.
• AI has the potential to enhance development tools and improve processes, but it is important to focus on efficiency factors.
• Metrics and analytics play a significant role in project management, and AI can be used to drive predictability measurements.
• Technical entrepreneurs should consider the financial aspect, focus on monetization, and develop sales and marketing skills.
• Podcasts can provide genuine and insightful information, helping to educate and inspire the next generation of professionals.
• While AI has potential, its impact on the industry is still evolving, and it may not bring significant life-changing advancements in the short term.

Connect with Alex

• Website: https://projectsimple.ai/ 
• LinkedIn: https://www.linkedin.com/in/apolyako/ 
• YouTube: https://www.youtube.com/@lets-talk-agile/featured 

Connect with Vit

• Website: https://vitlyoshin.com/ 
• LinkedIn: https://www.linkedin.com/in/vit-lyoshin/ 
• X: https://twitter.com/vitlyoshin 
• Other: https://linktr.ee/vitlyoshin 

Timestamps

(00:00) Intro: About Alex Polyakov

(04:40) ProjectSimple.ai Software

(15:04) Choosing the Right Methodology

(18:50) Perfecting the Process vs Solving Problems

(24:29) Transparency and Visibility

(29:38) Encouraging Participation

(33:31) Leveraging AI

(40:08) Metrics, Analytics, and AI

(43:12) Advice for Technical Entrepreneurs

(50:02) The Purpose of the Podcast

(55:35) The Impact of AI on the Industry

Transcript (Edited by Vit Lyoshin for better readability)

Vit Lyoshin (00:02.414)

All right, hello everybody. Welcome back to the show. We have a new guest today, Alex Polyakov.

So you are the founder and CEO of a company, Project Simple AI, and you guys build software for agile development teams, project management software, and maybe product management software too. And you’re using AI as I understand. So, we’ll talk about this a little bit today. And you’re also a podcaster, so I’m gonna have a question about that as well. And yeah, welcome to the show.

Alex Polyakov (00:42.921)

Yeah, thanks for inviting me. Glad to be here. So happy to explore whatever topics we start diving into.

Vit Lyoshin (00:53.776)

Yeah, great. So, let’s jump into it. Can you walk me through a little bit of your career journey? So you started as a software developer engineer, and now you’re running your own startup and development teams. Were there any pivotal moments or experiences in your journey, that you can share?

Alex Polyakov (01:12.129)

Sure. OK, so I’ve been an engineer for a little over 25 years. I went through essentially all of the phases from applications developer through architect, then got into a little bit of product management, and onto the startup world. So, it’s been fun.

I think from the most impactful experiences, I have to say that as an engineer, it’s probably not the best statement to make, but I never cared about the business. I only cared about the technical problems I wanted to fix. I really didn’t care about, you know, the details, requirements, customers. That wasn’t my thing until I got a little bit more mature as an engineer.

And when I started to lead teams, this is where the knowledge of the business became more important. And then also another pivotal moment in my career was the fact that somewhere in the early 2000, this skinny guy in the turtleneck by the name of Ken Schwaber came to the company where I was working and for about two and a half months taught the company how to do Scrum. So I kind of caught the agile bug, if you will, a long time ago. I just liked the nature of engineering a lot better than what I’ve experienced previously. And that kind of stayed with me throughout my entire career. So those are, I guess, the most, I guess, recognized moments where my behavior and approach really, really changed.

Vit Lyoshin (03:03.22)

I see, okay. And you have also been in leadership roles like a CTO and architect before you started running your startups, right?

Alex Polyakov (03:14.249)

CTO? No, no. I was always an architect. I was always, you know, like a technical guy hands-on. I did lead some teams. I did serve as a chief architect for a couple of companies, but mostly I didn’t go up above into more of a technical role. I primarily started to take more of an executive stance, if you will, within the startup world. But, you know, to me, it’s more of the same.

Obviously, I have not come out of huge organizations, even though career-wise I worked at IBM, I worked at pretty large enterprises. So I have a pretty good mix of enterprise and smaller companies as well.

Vit Lyoshin (03:55.412)

I see. Okay, great.

So let’s switch gears a little bit and talk about the software that you’re building and the company that you’re running today. As I understand, you’re trying to improve productivity and make software engineering teams more effective and efficient, so that they have great collaboration between themselves, especially for remote teams. So could you collaborate a little bit, I mean, emphasize a little bit of key principles that you personally care about in software development?

Alex Polyakov (04:42.889)

There’s quite a lot to talk about here, but I guess, you know, again, I reflect a lot of the decisions and a lot of ideas out of my own kind of frame of reference and experience. So the problem that I wanted to address with Project Simple with our solution is the fact that I had a pretty versatile experience working for companies that were very and followed the process and did very well. And also by the same token companies that said they were agile but did not have a process that was even remotely close to what I’ve experienced with my best teams. And I wanted to replicate the successful engineering team environment. Those are the companies where I really enjoyed working.

And if things like the economy didn’t change, I’d probably be still working there. But unfortunately, in different careers, a lot of my positions were eliminated due to layoffs and things like that. It’s always great to make a lot of money too. But in my experience, I just wanted to rebuild the same feel of a great team.

And what’s a great team? It’s a team that’s not stressed. It’s a team that has very strong camaraderie. It’s a team that has management that understands your goals and understands your difficulties as a team. It’s somewhere where you can feel very comfortable taking on the toughest challenges, knowing that, you know, you can learn on your own without anybody, you know, kind of, hitting you from the back, going faster, faster, faster. Right. So, I think replicating those environments is hard.

And one of the biggest challenges that I found is that number one, the tools we use today is they’re still 20 years old. The project management tools haven’t evolved much, but the discipline has. I also find that you know, we are right now in a generational shift when it comes to software engineering. 20 plus years have passed since the Agile Manifesto and, you know, my career, the guys that went through the career with me, we’re now much older. And then we have young developers that are coming through and young developers, unlike us, are exposed to a completely different environment. Number one, they do not learn the same way we did. We had a mentor, we all sat side by side, we were co-located and we had a great team environment. A lot of the current environments are remote where you don’t have relationships like this.

We did not learn by YouTube. You know, we did not have that as a resource, right? We had to read books, we had to attend conferences, we had to actually take sophisticated classes. Right now, almost anybody can afford a Udemy class. However, the information is for the most part very abstract. It’s not very pointed. You know, anybody can go and take any class, but I also found that unfortunately, the young generation doesn’t really watch those classes. You know, so the success of them is questionable.

So I think in the younger shift, there’s really nobody to teach that younger generation of developers. What is the proper way to build software? People think they know it, but without actually knowing the science behind it or the reasons why it’s really hard to understand. So that’s another missing link.

So what I wanted to do is I wanted to build a platform that’s built for the modern time, something that makes engineering teams better by leveraging behavioral science. For example, the science of how do you bind the team? How do you form it? What are some of the things that you need to reinforce? And also the science of agility, but in a way that’s very prescriptive.

Meaning. If we can’t teach people how to actually follow the process, and if the process is interpreted differently by everybody, how can we have a very standardized approach that you just sign up and the solution teaches you how to follow all of the agile best practices and all of the software engineering best practices? Meanwhile, there’s also the gap of product management. So we still seem to be struggling in managing product vision, in managing product backlogs, and in distributing work across multiple teams. We’ve learned that managing one team is easy, relatively easy. Managing multiple, that’s where everybody starts having a lot of difficulties, especially for the enterprise. 

So that’s where people created SAFe, scrum at scale, LESS, and all kinds of other methodologies to attempt to teach that. And still, none of those are really uber-successful. Some are better than others, really depends who you listen to. But the shortcoming of all of those approaches is there is no tooling that allows you to make it easier. So people rely on the tools they have and try to craft the process around it. My vision, you should be able to sign up for something that gives you these things out of the box. Something that actually teaches you the proper standard way of doing things.

Vit Lyoshin (10:18.136)

I see. That’s great. It covers a lot of things and it actually explains a lot like the reasoning behind it and so forth.

Alex Polyakov (10:27.817)

And helps the team maintain its rhythm. So I know a long answer, but ultimately that’s kind of the idea behind it.

Vit Lyoshin (10:47.184)

Now, the approach that you have picked is a very specific way of doing software development, you set up this environment, and you have specific tools for people to use. So it eliminates that kind of eliminates flexibility at the same time, but it puts them into the frame of how to work. And that’s essentially when you start a new job, that’s what you get, right? You join the company and they’re doing the same agile practices in a completely different way. And you still have to learn everything, even though they call the same things, scrum, kanban, or whatnot. You still have to learn how they operate. Even if people move from team to team, it’s again, it may be slightly different. Everything is called the same, but actual practices day to day are different.

So that’s great. And the tool essentially allows you to jump in and start using it with a very prescriptive approach. But there are some flexibilities as well, right?

Alex Polyakov (11:44.841)

A little bit, but ultimately here’s a big difference, right? The tools that are out there for product management and project management, are like sales forces of project management or product management. You can configure pretty much anything and everything. It’s there sort of sales forces of it, right? So you have forms and processes and triggers and statuses and all these other things. You can build anything that you want. It’s the Lego set of, you know, whatever you want to build.

And most of it is subjectively interpreted by something else. The Agile Manifesto is also written like a legal document, open to interpretation. So people implement things based on their own limited experience. They have a lot of bias, mostly led by whoever’s leading the team, right? Sometimes it’s actually controlled all the way up through the org to do a certain way, but it’s not actually taking the interest of the team. And there you have like a completely strange setup where the executives want to understand what developers are doing and things are going to be done on time. But they don’t use the software that actually tells them, so they ask PowerPoint to be presented PowerPoint presentations. Everybody collates the information together and what you get back is this weird optimistically centric state of current development, which is kind of full of a little bit of white lies here and there.

And that’s what we take as the truth. And then we wonder why when we get close to the end of the project, we can’t get it done on time. So we need to step away from that approach because there’s three parties that are involved in any kind of software development principles, right? There is the executives, they’re trying to manage the timelines and customer relationships and things like that. And they want to understand obviously the level of investment. Then you have the next one, which is the managers who manage the teams. So you have your product managers, they’re managing the teams from the product perspective and the engineering managers from the technical perspective. And then you have the teams themselves. But so far, the tools that we use only really are tailored for the users of the teams, but the data they get is not really exposed well to the executives. So this is where we start having an ecosystem of the tooling. I think we need to bring it all together to the same thing. You have all of these three users that are benefiting from one process.

Vit Lyoshin (14:24.804)

Yeah, that makes sense. So for your particular case you chose to use Scrumban out of all these methodologies. Can you explain the reasoning behind that?

Alex Polyakov (14:41.123)

Um, so let me correct that. For my own team, for the implementation, we use Scrumban, correct? But for, you know, anybody using the platform, they can either choose between Scrum and Scrumban. It said it’s actually pretty versatile. Now on my team, we switched to it and we haven’t gone back.

And the reason we switched to it, it’s not a secret, most of my engineers are located in Ukraine. So when the war started two years ago, we were following the scrum process. But obviously, you know, with the war happening, we had no expectation of anything being done. We couldn’t plan. We had no idea when people were going to be available. People were moving, you know. So it was a pretty challenging time. So we needed a different methodology to manage what anybody was working on. And we decided that we were going to follow a Scrumban. And the reason I like that process is because it maintains the cadence. But at the end of the cadence, we can sort of cut it off where we were and inspect and adapt the previous cycle. So the previous two weeks, and assess what we’ve been able to do and anything that we need to improve. And the adaptation period is really, really good. However, going towards the more of a Scanban approach, we didn’t have to do any more planning in a way that of, you know, let’s plan the next two weeks. We didn’t have to have grooming sessions. All of that became replaced by just-in-time prioritization. And I feel like that’s something that gave our team the edge because engineers felt that small conversations at the appropriate times were much more efficient than planning ahead of being able to take something because it wasn’t ever clear if they would take something. If we don’t know what we’re completing, how can we plan the next section? We’re just wasting time. So the just-in-time prioritization worked beautifully. And it was a big surprise that the platform handled it so well. And just the fact that we could visualize the work is one of the reasons why we don’t want to go back. But we’ve retained the retrospectives. We’ve retained the sprint reviews where we kind of go through what was achieved in the last cadence cycle. And that’s always really good for celebration. The team feels comfortable that, hey, listen, we’re not just a feature factory, right? We’re actually making progress towards user value every time.

And here it is, everybody can see it and feel it. And I think that’s something, I mean, I used to be a huge proponent of Scrum, but trying this process and working on it, it became so easy that I can’t see myself going back.

Vit Lyoshin (17:52.432)

Yeah, well, that’s also a perfect example of being agile in your organization, right? You saw the change in the environment and you had to pivot to a new approach and you had a tool to do it. So that’s a great example of staying agile and actually leveraging your own tool for that.

Alex Polyakov (18:12.803)

Yeah, I think as an agile community, we often work too much on trying to perfect the process. We fail to take a step back and always ask a question, what is the problem we’re trying to solve? Is the problem delivery? Is the problem feedback loops? Is the problem building the right thing? Is the problem, how do we get quality up? Is the problem, how do we develop more? Is the problem, how do we negate the risks of delivery? What are the problems we’re trying to solve? Because each one of those problems, can be solved in many, many different ways. And the fact that agility means changing direction, easily, quickly, and with ease. It’s kind of Alistair Cockburn’s definition, who I really respect and admire in the Agile community. And If we follow agility as the ability to just make decisions and drive change, and that’s really the ultimate principle, the rest, there are just basically recommendations. Okay, the retrospective is how you do the feedback. But our community is so focused on perfecting the process, perfecting what is the definition of scrum? Is it this? Is it that? Is it immutable? Is it not?

I think we argue a lot about these things and obviously everybody’s entitled to their own opinion, but I don’t know that it drives value to the engineers or the technical leaders that are running the teams, right? We shouldn’t be perfecting the process for the sake of perfecting the process. We should be solving real problems.

Like if you’re looking, you know, we’re arguing about estimation all the time, story point or not story point, no estimates, or whatever the methodology you want to use. Do you estimate the wags in times, days, I don’t know, oranges or apples, right? We always argue about that. But the question is what works for the team? Is the team more comfortable with one approach or with the other approach? And I think we need to be a lot more flexible. We tend to sink a lot into the terminology rather than into how we get the teams moving. How do we lighten up the load for them? Because I remember what it’s like being an engineer who was micromanaged. I hated it.

So that’s actually one thing that we’ve noticed is that by implementing our approach, we basically do not have a single sign of micromanagement. Our clients notice that as well, that they’ve micromanaged so little and only the points primarily when support cases start coming through, which is the area that’s important to take a look at to make sure that no one’s dropping the ball and missing the opportunity to quickly get back to the customer.

Vit Lyoshin (21:02.416)

Yeah, what you just said is really my principle as a Scrum Master and Project Manager to let the team choose the tools and methods. Allow them to do that. As little as possible to manage how they actually do these things and which methods they use, like story points or hours. That’s a typical conversation with some agile coach who runs into the room like, guys, we have to start to use story points because that’s better and that’s blah, blah, blah. And the engineer is looking at them like, why do I care? Like, you know, just let me do my work, my task, right?

So anyways, but then at the same time leadership may come back and say like no you have to do it in this way because we have this reporting, we have this budget, we have this commitment to the users, blah blah blah. So there has to be a little bit of balance.

Alex Polyakov (21:57.571)

Yeah, but I think we’re making a lot of mistakes on the metrics that we expose. There are two types of metrics. There’s metrics that are inside of the teams and then there are metrics that are outside the team. When you start communicating the metrics that you use inside of the team to the outside world and they’re not engineers, good luck. Good luck trying to explain that that’s just your approach to doing something, right? Which has nothing to do with making sure that things are getting done. Meanwhile, on the outside, people need to still have the ability to see how things converge toward execution. They can’t rely on what I call subjective self-reporting. Hey, where are you? We’re 85% done. What does that mean? It’s gonna take another 85% to finish the next 15, right? So…

I think we gotta start talking in a certain appropriate language depending on which level we’re communicating with. Inside the team, you can use what you want. To the outside, they need to have the ability to do one thing and one thing only. Show what are the risks of delivering by a certain timeframe. Because there are contracts, there are revenue expectations, there are things that are very important with the deadline.

And meanwhile, inside the team, it’s not the deadline that’s more important. It’s the volume of work to be completed that’s important. So we need to bridge the gap. And that’s another kind of consistent point that I’ve seen people state. The ability to see top down the product, not only the decomposition of the product, but also its execution and delivery.

Vit Lyoshin (23:49.968)

Yeah. Great point. So let’s talk about transparency and visibility with your tool. You mentioned some of the tools like retrospectives and some other ones like estimation. It’s also part of the system, right? And stand-ups. So what’s your goal with this tool and how does it allow transparency between everybody who’s working?

Alex Polyakov (24:22.915)

So good point. This is where we have to talk about discipline. Most people think that agile, they argue about agile being a methodology. Is it a methodology? Is it a mindset? Is it a process? Is it a framework? I kind of scratch all of those words and I say agile is a discipline, right? You’re either following a disciplined approach to agility or you’re not. If you’re constantly changing and you’re taking certain things that are agile and you’re making decisions that make it not agile.

Well, unfortunately, you don’t have the discipline of being agile, so you’re gonna make mistakes, and obviously, you’re gonna suffer the consequences. So when we talk about the discipline, and you’re asking about all this tooling, the question comes up with how do we get the teams to exercise discipline properly? And this is where we run into behaviors. I’ve seen teams do story pointing in Slack where the tech lead is the first one to state the number and everybody else copies it. That’s not really good because now you have bias. Now you have people that are totally uninterested and this process will not work. It does not create friction inside of the team to openly explore challenges or approaches to solving certain problems. So what we’ve just done is because we use a certain tool in Slack that is free and we just plugged it in, we actually created the wrong environment unintentionally, right? I’ve also seen people do, what do you call it, retrospectives by coming up with the cards on the fly and everybody else can read them. So the first two people pull the hardest cards and then everybody else is disinterested and they just copy the same.

So the approach to discipline needs to be a purposeful one. Everybody plays a role and everybody needs to contribute. You can’t just have a couple of people always contribute like the tech lead and maybe a few more seniors, right? And everybody else just says, well, I trust you because you’ve done this a hundred times and you know it better. That’s where you actually start not having teamwork. That’s when you start actually telling people what you should be doing.

But we need to start crafting environments where people pull the work they want to participate in, not wait for it to be assigned. And in such an environment, what you need is you need the proper tools to be used. There are a million plugins people have. If somebody is using Jira, you could just sign up for a thousand of them. They’re all different. They all work differently. You could also use external tooling. You could even do things in Miro boards and et cetera.

The problem with all these approaches is they still make everything completely visible to everything else. And sometimes you just have to hold your cards down and not open them until the right moment. That’s why it’s a story poker. Everybody opens the cards at once and we find out where things stand. If you don’t follow it, then there’s an opportunity to have a process that doesn’t work. If you’re doing retrospectives and people copy, you’re not actually getting people of the areas that are of biggest concern. And by the way, one of my mentors once said, the best employees are the ones that are never happy with anything, right? So you need to let people actually talk through their problems. And you need to create an environment where people openly discuss them. What works, what doesn’t work. What worked better, what didn’t.

Without it, you really can’t have the feedback loop that makes teams better. And so our decision was to bring all of the tooling inside because there’s so much value in doing it the right way. But also, when people use tooling outside, nobody can find how the information got there. I mean, here’s a challenge to anybody listening on your agile teams. Can you pull up a retrospective from six months ago? How easy it is to find it. Do you remember who said what? Right. And I think I think that’s important, especially since we’re faced with AI and generative AI can understand those notes and maybe make some recommendations based on those notes. That’s a new field and there’s a lot of opportunity how to utilize it better to the advantage.

Vit Lyoshin (29:02.044)

Yeah, well, you’ve said a lot of things there, which are great. And tooling has to come with discipline or discipline first, actually, and then tools that support that. And somebody’s doing due diligence, making sure people follow through and they do it and they build that discipline over time. I would say that in every team I worked with throughout my career, there were at least a few people that are always quiet and you always had to poke all the time to make them participate. It’s just engineers, they are very introverted. They’re quiet people, they just want to be left alone and do the work. And sometimes in these events like either estimation or retrospectives or even stand-ups, they just say a few words and pass them on to the next person. So it’s just the personalities that we have to deal with as well.

What I’m trying to say is that you have to approach this and not like everybody has to do this right or whatnot. Still, be a little bit empathetic, train them, coach them, mentor them, and just give them a little space and try to motivate them to participate and build a discipline that this is also important work to do.

Alex Polyakov (30:20.355)

Exactly. And so when you give people the tools that approach them, despite of their personal preferences on how they do things, right? Then that becomes pretty easy to replicate the process for everyone. So let’s say the way our system, for example, works three days before the end of the sprint, the system says, hey, please fill out your retrospective. And we expect that three days before the end of the sprint, people have enough that they can go by about what worked and what didn’t. Right. And they can fill it in. By the time the team shows up for the retrospective, everybody’s notes are available. We’re not wasting anybody’s time. Right. We’re just coming in and immediately start talking through the notes. We, you know, somebody starts and says, here’s mine. And then everybody else adds to their comments. And so, even though people are introverted, a lot of them are in engineering, as you mentioned, but you got to give them the environment where they can feel free to contribute.

And without, you know, with a process where people come up with the notes on the fly, it’s very easy to fall behind and just say, well, you don’t really need my feedback. You came up with everything on your own already. Right. And actually, actually we have an approach. I know who my introverted people are. So I actually start with retrospectives with them first.

Vit Lyoshin (31:41.594)

You actually have a good tactic there because I always tell my teams like, guys, you don’t have to wait until we actually meet for retrospective to put your items and keep track of those things throughout the sprint. As soon as they happen, send yourself an email or whatever and save it for that day when we meet actually because we don’t have tools yet.

Alex Polyakov (32:05.987)

I have another trick that I always use with introverted people. And whenever we have conversations or team meetings and we have discussions, people know that they always need to listen because I’ll always pull somebody out of the list and I’ll say, what do you think? So, you know, like the, I know who my more quiet guys and gals are. So I will ping them and I’ll ask them and I’ll expect to actually get their thoughts.

So if I feel like somebody is being very reserved, or I know that that’s their tendency to be so, I don’t let them hide. Our job as leaders is to develop our people and to give them an environment where they feel like they’re contributing.

Vit Lyoshin (32:51.052)

Yeah, that’s a key. That’s great. So you started mentioning a little bit about how AI can help us with such tools. Can you elaborate a little bit on how you specifically leverage an AI in your app?

Alex Polyakov (33:10.179)

Sure. So there are lots of areas. Now, we’re experimenting with a lot, but the one AI element that we already have in place is the predictability of delivery. So in the platform, you can create a roadmap. The way that roadmap is aligned with the work and the milestones that you create allows us to start measuring how the team solves problems. And what the AI does, it gives us predictability if we’re going to deliver what we set out to deliver on time. And usually, we let it work for a little bit of period without any kind of alerts, about 20% of the time. And then we start forecasting the next 80%. So if we detect that you’re sliding off schedule, it will start providing the alert.

So that’s the AI that is extremely important. But again, that explains why we need a very prescriptive process. Without teams following some standard approach and everybody implementing their own process in one project in a multi-team environment, something like project milestones would not be possible to even measure. You could probably do it within one team, but that’s not really valuable. What is valuable is the higher-level goal. So that’s something we already do. But there’s a lot of opportunities. There are opportunities on, you know, like agile GPT, some sort that actually analyzes how the team works. There’s an opportunity to change the way that we work with, you know, taking descriptions, turning them into tasks, definition of done, acceptance criteria. Not really doing it for the end user, but suggesting it. So there’s a little bit on the product side and a little bit on the team side. But those are primarily efficiency factors. I don’t think they’re supercritical. People do them all the time. And I think prompt engineering is not something that’s easy to do given that all of AI keeps evolving. So you’re constantly reinvesting to make things work. But there’s a lot of opportunities. There’s an opportunity to take a look at how we do documentation. There’s an opportunity for test cases. There’s an opportunity for many things. It just really, it sometimes it’s hard to focus.

Ultimately, our approach is, If we nail down the process that gives us good predictability, that gives us good data, then we can use the AI to drive predictability measurements. And that’s sort of our first biggest AI value. As far as I know, we’re the only ones to have this functionality at this time.

Vit Lyoshin (36:19.988)

My background is in decision support systems. So conversations like this about predictions and different models, how to automate decisions, or help people make better decisions, I really enjoy all the time.

Alex Polyakov (36:41.731)

Yeah, I mean, we know that there were Monte Carlo simulations, right? This is where agile kind of relied on, but they don’t really work. In my opinion, nobody’s going to run a Monte Carlo simulation and find out what year this feature can be done 2 days to 72 days. That’s not really useful. It’s not one feature you’re running. You’re running an entire sprint of them or in a milestone, you running a hundred maybe, right? And you do that across multiple teams. So now this entire simulation just doesn’t really scale, doesn’t work. And also we’ve discovered that most of the new work comes out as an evolution or iteration of the existing work. Like you take a pass, you make the first run and then you’re like, ah, we should change this, we should change that, we should change this.

So the iterative approach, is actually how you discover newer. Plus, nobody takes away the old work. There’s a bug that can be discovered. There’s a certain enhancement somebody asks. So how you bind it together into prediction is something critical. And yes, people are gonna bring up no estimates and no estimates can show. The problem with trying to drive the graph that no estimate can show predictability is the fact that you actually need to have everything detailed and decomposed already. And that’s anti-agrile. So it’s kind of a strange approach. Nobody wants to plan out one sprint in advance, let alone three sprints to see if you’re going to hit the milestone. So what we’ve done is we’ve done a lot on determining all of these things and they rely on cycle times. Not only cycle times of the story, but also cycle times of their tasks. We rely on the new work that’s constantly discovered. We rely on knowing metrics and statistics of a lot of stuff. So you just kind of throw that all in the bucket and see what AI spits back at you.

Vit Lyoshin (38:53.244)

That’s pretty cool stuff. And I’m sure as we’ve progressed to the future, there are more tools will be available and more models and algorithms will be out there. Right now, it seems like the focus in the industry is mostly on generative AI and machine learning, maybe expanding further to other areas. And it will be helpful for development tools, actually how they write code and how to test code, right? And also for the product side, product managers, project managers, and from the business.

So, another thing is I know your tool has a lot of metrics and analytics around projects and sprints and how work is being done. Is there any AI or any expectation for predictability models involved or is it just the status reports and how things went?

Alex Polyakov (39:51.895)

No, so the analytics don’t really need the AI because actually AI is driven by what analytics are on the surface. So analytics is just a different way to visualize the data. But those are the data points that AI then leverages.

Vit Lyoshin (40:11.068)

I see, okay.

Alex Polyakov (40:15.171)

The only thing that I can state is that without, again, going back to the uniqueness of the solution, without having a very prescriptive process that asks to follow a certain way, it’s hard to capture the data points in other systems because of the fluctuations. So let’s say you have one team that has one development process, right? And it has swim lanes for specific things. Another team has a completely differently defined swim lane. Right?

They have some kind of triggers and much more complex automation. Both of these teams work under different managers, hence the preferences for a different process. Both of these teams work on the same project under one product backlog, which is external to the project management platform. How do you bind all of this data together to give it predictability? And the way most have been doing it so far is connecting BI. Pulling all the information, all of the teams out, going through some complex transformation, and then attempting to visualize the data. The challenge, however, with these BI tools is what are they looking at. They’re going to give you the same data on what cycle time, right? Which is not deterministic. Are they really going to give you forecasting? Well, maybe some, but limiting. But you have to do configuration-based to assess which swim lane belongs with which swim lane. How do you categorize it?

Plus, the other thing is the only people who can afford BI are companies that already have BI tools, right? Because it’s pretty expensive. So you’re not gonna just buy it to predict if your project is gonna be done on time. You may, if the problem is important enough, you may, but that’s gonna cost a pretty penny. So my vision is you don’t really need BI. All of the data can be self-contained.

We just need a better way to display it right within the tooling that everybody else is using.

Vit Lyoshin (42:20.7)

Okay. And anybody out there, feel free to check it out. This is pretty cool software that you built in there.

So let’s switch gears a little bit and talk about some entrepreneurship stuff. You went from the technical field to the entrepreneurial field, I would say if such a thing exists. Do you have any advice for any technical guys who sitting and thinking about starting a company or building some cool app and going on their own rather than staying in the company?

Alex Polyakov (43:07.427)

So number one, I am far from an expert here. So you may want to read some books instead of listening to my advice. I mean, I can only tell you what I’ve encountered.

I’ve made the mistake of believing in a solution without a problem in the previous company. And we had to reverse engineer and find the market.

We did, so we got lucky, but I think it could have easily gone the other way. So, us engineers, we tend to fall in love with the problem. Just like I said, I didn’t really care for business much. So definitely thinking from the business and monetization perspective is very important early on. Somebody I met early in my journey of entrepreneurship actually said, if you can’t see an exit, don’t do it.

So I think it’s an interesting advice. So if you’re thinking of an exit as your exit strategy and it’s not a lifetime business, then you may want to consider it seriously. On the other side, technical founders typically do not know how to sell. They’re not exposed to marketing, sales, and all of those things. Turns out it’s harder than it looks. It’s not just a bunch of fast talk.

It’s difficult, there’s a lot of things to do. You need to have the proper communication. You need to learn to listen. You have to step out of the shell if you’re introverted. So there are lots of things that need to be taught, presentation skills, et cetera. That’s not easy. I had to learn a lot of that. And maybe not really learn, but get the confidence.

So I think that’s another big one. And then if there’s anything else, I know there are lots of areas to consider, but I think people struggle with the funding aspect. So you really need to understand and launch when you believe you have an approach. A lot of times I wouldn’t even suggest quitting your job until you have something that you could show or go for because raising capital is not easy. And if you don’t have the connections, which most people don’t, it’s going to take some time. Making people believe is a job in and of itself. And again, it sales. It’s the same sales. The only difference is the product is you. So that would be my biggest recommendation because I think from technical founders, we can build anything.

We think we’re so hot and good, we can build anything. And it’s true, we can. But build it and they will come is not a success strategy.

Vit Lyoshin (46:10.524)

Right. Yeah, you need to be able to sell and motivate people to follow and build a team around yourself and your product. I agree. Those are very good suggestions and lessons that you’re sharing. 

So the financial aspect is very important as well. Of course, if you, especially if you’re doing it with other people and you know, you need to pay them or you need to pay for resources, even simple stuff like servers and licenses and things like that.

Alex Polyakov (46:44.867)

So I have a friend and I actually admire him a lot. He is a serial entrepreneur and he decided to do something new recently. And he said, and I’m like, hey, what are you doing? And he’s like, I’m exploring. And I said, what do you mean exploring? He’s like, I’m talking to a lot of companies and all I’m doing is I’m asking them questions. I think I know what I wanna do but before I even dive into it, I want to understand their pains.

So that’s the approach. This is what we call a lean approach where you’re actually validating your idea before your building. However, be careful how you craft those questionnaires because it takes absolutely no effort for people to say, yes, yes, yes, I want it because they just like who you are and don’t want to hurt your feelings. In reality, that’s not something they would buy or they’ll just give you advice that’s completely wrong. But that’s an approach that you can definitely leverage before you dive and build things. Because we get so caught up in creating our own baby of a product, it’s very hard to step away from it afterward.

Vit Lyoshin (48:00.424)

Yeah, I have two things to comment on here. It’s when you talk to people, even when like I used to be a product manager and I talk to people and I say like, hey, I have this and these tools for you. Do you like them or not? And people, of course, I like them. If you give it to me, I will use them. I’m like, okay, ask people to pay for it. And then that’s how you test if they really need it. And if it’s really paying for them to like pay money and use it to solve their pain. If they’re willing just to use it, well, it’s a 50 -50 chance. It’s maybe valuable, maybe not.

Alex Polyakov (48:38.979)

I actually have a correction here. Ask people to pay for it and then ask for them to pay it again.

Vit Lyoshin (48:47.452)

Okay, all right, repeatedly pay for it, yes.

Alex Polyakov (48:48.963)

If they pay again, that means it’s needed. If they just paid once, that means that, hey, listen, the marketing worked. You know, nobody wants to create a company that has so much of a churn that you’re constantly going for a new audience. I know we live in a big world and there are, you know, many billion people. But at the end of the day, you know, you don’t want to keep cycling through the new list every time.

Vit Lyoshin (49:15.772)

Yeah, that’s true. So yeah, asking those questions is a good approach.

You also have a podcast you recently started. So I just wanted to mention this and ask you what the purpose is, who are your speakers, and why you are doing this. Why did you start this? You have other things to do I think so.

Alex Polyakov (49:43.239)

Well, so again, going back to the new audience, right? So we need to educate people, especially the young generation on the proper way of doing things. And they’re really not following our channels. They’re not going to, hey, Agile Alliance, I gotta sign up. I’m a junior developer and that’s the first thing I gotta sign up for. No.

And companies don’t really train as well as they used to either. So I think this is where we need to start communicating. But I actually do the podcast a little bit different. The idea was to try to create something that’s a little bit more truthful in terms of the information. Because we all see the amount of LinkedIn ads or LinkedIn posts and YouTube videos, they go, agile is dead. And then there’s like 300 million clicks, but it says absolutely nothing. And it’s just clickbait. I wanted to create something that’s really genuine that people can go, you know what? That’s some, this is something insightful. Again, I make it very clear in that podcast that it’s my opinionated response or it’s my opinionated thoughts.

But I wanted to expose a much wider opportunity for discussion because we always get the articles that are in, and on LinkedIn, it almost feels like a virus sometimes. Somebody’s gonna post something and the same topic is gonna be pushed for the next two weeks, which could be completely wrong or erroneous, but it gets the clicks and people just like to go for it. So I think we’re beginning to struggle with what is validated information because our heroes, Martin Fowler, Kent Beck, you know, Alistair Cockburn, and everybody else, you know, the younger generations don’t really follow them. They’re our heroes. So we need to create heroes for the next generation. And I’m not trying to be one, I’m just trying to voice the information so they can find the heroes because a lot of the information is not actually original to me. The only original to me is how I describe it. But, you know, I go to a lot of conferences, I try to learn, I read.

I read a ton of books, you know, and I have a ton more on both sides. And I think, you know, it’s not always the information, the books, people can’t be expected to read every one, but you can summarize it into bite-sized information nuggets, and people can grasp and explain.

Like, for example, I got into an argument recently on a video that talked about the difference between decomposition and unpacking. And it’s pretty funny, like decomposition of the story or unpacking the story. Turns out it’s a thing. Unpacking is a different way to describe something. I think it’s totally unnecessary and the research is very superficial, but people say, hey, there’s research on this subject and you can go take a look at it. Unfortunately, the research is unsubstantiated. It’s not for software development. Some basic experiments in a university can be very biased depending on how you read the information. So I think what I’ve learned is that you don’t just trust the book. You always have to go through and follow the references. And that’s what I try to do. I try to uncover the real truth and then give people the absolute understanding. Like, hey, you know, if the scrum says that it’s immutable, let’s not challenge it. Just leave it alone. Leave it scrum. You can have your own version of a hedgehog.

That’s fine. You know, if you want to bring work in and out, well, call it Scrumban. For example, our Scrumban, we don’t call it Scrumban. We call it a continuous sprint. Because when the sprint ends, the new one begins. There’s no prep work, nothing. And it actually sounds a lot better. So I think there are ways that we can create derivative work, but you know, we just need to know the information. So that’s kind of the purpose.

However, what I found is that people started volunteering to participate in the podcast. And so I started talking to people and kind of like you interviewing folks and I’ve been getting a real kick out of those conversations, particularly because of how valuable certain message was. And so, I definitely wouldn’t want to hide it. I think it’s worth sharing.

Vit Lyoshin (54:37.884)

And, you’re meeting a lot of people, you’re having interesting conversations, that’s a lot.

Alex Polyakov (54:44.323)

Well, I think you can relate to it quite well.

Vit Lyoshin (54:47.356)

Yes, I can. So that’s a pretty interesting thing to do. Okay, cool. Okay, so the last question for you for today is with all these technologies and artificial intelligence are there any any sort of trends or where the industry is moving?

Alex Polyakov (55:29.347)

Um, I don’t know. Uh, good question. So even though I have a lot of original ideas, I am not an early adopter on lots of them. I really wait till they play out. I’m more on the, I think, I guess, very conservative side. I want to see proof and the proof is it needs to stand the test of time. You know, everybody’s talking about AI as this big craze right now. And oh my God, you know, like, Jeff, you know, Sutherland made a statement recently that, you know, using AI, engineers will be 25 times faster. I think that’s baloney. Okay. I think we’ve learned that co-piloted code gets rewritten in a very short amount of time. And by the way, we didn’t need AI to generate certain blocks of code. We’ve been doing it for over 15 years.

IntelliJ, which is my choice of a tool for Java development. You know, we always generated skeletons and blocks of code and there were cool plugins you could use. It didn’t really need AI for that. So there’s, I can’t see that engineers are going to be 25 % faster. I mean, even if we had libraries of ready things that you could just throw together and do development that way. That’s one avenue. I mean, we have, you know, codeless development right now, but it’s not even that popular. It’s I don’t see everybody rushing towards it and going, I need to have it. You know, you have that in certain specific tools like, hey, get me a macro for Excel or, you know, like certain functionality inside air table or maybe notion, right? But it’s not something that is really just mainstream. I think a lot of it is still knowledge work that we’re involved with. There’s a lot of knowledge work that’s based on the trade-offs. The trade-offs need tests and data to drive decision-making. You need to sometimes place a bet. Sometimes that bet is not clear. You need to tie it all together. You need to tie up a whole bunch of business.

And I don’t know if near term the AI world is able to provide that. I really don’t. I mean, I’d like to see it. Maybe it will, maybe it won’t. But, you know, do you find yourself just living inside of the world of chat GPT every single day? Sorry, I like my original writing, for example. If I struggle to formulate something, I’ll ask it. But again, I prefer my style, my true nature.

So I think AI is a great helper. If you have writer’s block and you don’t know what to blog, what to write, you know, it can generate some ideas for you. If you need a picture and you don’t want to pay for it, sign up for picture generation on the AI versus Shutterstock. Okay. That’s good. Why pay, you know, $15 for a picture when you can generate a hundred of them for, you know, for a monthly subscription.

So we definitely see some of that, but I see most of that as impacting creativity, not really a process. And maybe we need to wait for the next version, but the way most people actually use AI right now, there are two types of applications.

They’re either generating something as a way of creating, or what they’re doing is they’re using it as a context-based search.

So I don’t think there’s anything else of that nature. And maybe I’m going to be proven wrong. I’m far from an expert in AI, but that’s a topic that the industry is trying to move towards. Obviously, in the agile world, I think we’re seeing that the industrialization of agile is not really going that well. It’s becoming harder and harder to be an expert in this.

Folks should have never actually picked it for a career because it’s really a senior role to be like a scrum master or an agile coach. You really need to understand a lot, not just, you know, be a, I was a developer for two years and now I’m an agile coach at NASA, for example, right? So I think there’s a lot to be learning, and the community itself is shrinking. You can sense that because folks eventually, If they can’t find a job and it doesn’t deliver value to the organization, well, they’re going to have to look for a change in their career.

Vit Lyoshin (01:00:26.46)

Yeah. And I agree with you what you mentioned about artificial intelligence and where it’s going. I don’t see anything coming out of it completely life-changing in the short term, maybe down the road, a bunch of years from now, but not soon. So we should be safe with our jobs, I would say for now.

Alex Polyakov (01:00:56.195)

Yeah, time will tell.

Vit Lyoshin (01:00:56.54)

All right. Well, thank you very much for coming in today and having this conversation. That was great. I think it was very interesting. And yeah, I’ll drop all the links for your contact information and for your websites to the description so people can check it out and maybe ask a question or reach out and whatever happens after that.

Alex Polyakov (01:01:21.723)

Oh, thank you. Always happy to chat more about that. And thanks again, Vit, for the invite. Enjoy chatting with you. And we should do more in the future.

Vit Lyoshin (01:01:37.244)

Yeah, absolutely sounds good. We’ll come up with more topics to discuss. Talk to you soon. Bye.

Alex Polyakov (01:01:45.731)

Thanks, bye.