← Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Scrum Master Toolbox Podcast: Agile storytelling from the trenches
BONUS The Human Side of Software Development With Jussi Mononen
00:47:40
CTO Series: Jussi Mononen on the Human Side of Software Development and Technical Leadership In this episode, we explore the intersection of technology and people with Jussi Mononen, CTO of . Drawing from his extensive experience as an Agile...
Loading summary
Transcript66 lines
- [00:07]
Host
Have you ever wondered what it really.
- [00:09]
Event Promoter
Takes to make Agile work well? At the Global Agile Summit, we're bringing you real life first person stories of Agile succeeding out there in the real world that will inspire you to take action. Whether you're a leader, a product innovator, a developer, you'll hear practical insights from those who've done it. They'll be telling their own stories from the stage. I'll tell you more about this at the end of this episode. So stay back and listen to the full detailed description of what we have in store for you at the Global Agile Summit. But if you can't wait, you can go right now to globalagilesummit.com and check out our full schedule for now onto the episode. But I'll see you at the end of this episode with more details on the Global Agile Summit. Talk to you soon.
- [01:04]
Host
Hello everybody. Welcome to one more episode of the CTO series. And joining us for today's CTO series episode is Jussi Mononen. Hey, Jussi. Welcome to the show.
- [01:15]
Jussi Mononen
Hello. Thank you. Thank you for having me.
- [01:18]
Host
As you will very quickly realize, Jussi is a bundle of energy. He's also a problem solver, a programmer, and a business to technology translator. People's side of software systems is, as he often says, all or sorry. He says that developing software systems is all about people. I should re edit the bio before I publish it as well. And he has both technology and people street cred. Being a longtime agile practitioner, I actually met Jussi when he was both a programmer and an agile coach. And he's now the CTO of a promising scale up in Helsinki called Carbon Link. Check it out on the show notes. So you see, that's a short intro, but of course you have a long career and as it often goes, yeah.
- [02:13]
Jussi Mononen
A quarter of a century.
- [02:15]
Host
Oh, there you go.
- [02:17]
Jussi Mononen
Did you have a century?
- [02:18]
Host
Did you get the silver plaque already?
- [02:21]
Event Promoter
Like do you have there?
- [02:22]
Jussi Mononen
No, not yet.
- [02:24]
Host
One should give myself one of those.
- [02:27]
Jussi Mononen
That length actually hit me when I was giving a visiting lecture at Aalto University and I was like introducing myself shortly, like, hi, I'm Jussie and I, I've been doing this for 25. For a quarter of a century.
- [02:40]
Host
There you go.
- [02:41]
Jussi Mononen
That was kind of an okay moment, like, yes, I'm getting old or experienced as they want to say, yeah, on.
- [02:48]
Host
To the next 75 is what I'm saying. All right. But in those 25 years, I'm sure you've learned a lot about leadership and technology. Can you share one of those pivotal Moments that shaped how you look at the role of the cto.
- [03:07]
Jussi Mononen
There might be actually a couple pivotal moments. The other one, the first one is kind of easy to describe. It was when I first got introduced into Agile methods, when while I was working for a middle sized listed company making software for teleoperators. And it was okay, just like when it was done, you know, old water polish methods and there was no structure. And the introduction of Agile ideas kind of opened up a larger avenue. Like software is not just code. And there it started. My kind of a humanist, as an engineer kind of approach to software. I realized that there's a larger, larger picture. I realized that there are lots of room for errors and almost all of those errors were related to humans. People make mistakes.
- [04:13]
Host
One of the things that I really like about that intro is, okay, so I was developing software with waterfall like methods and of course that's understandable. I mean quarter of a century puts you right in the end of the waterfall tale in terms of methodologies. But then you said, and the intro of Agile ideas opened this larger perspective, a more humanist perspective. So let's dive into that a little bit more, you see, make the contrast of what was there before and then after Agile. What are the biggest differences you noticed in your own perspective on software development?
- [04:49]
Jussi Mononen
Yeah, basically before the kind of the vision that Agile gave, what software production can be, they there was a. It was more siloed. There were like heavy barriers kind of walls built between different people who were kind of managing or trying to manage the actual business that we were trying to support with the software. I was working on an R and D department and we were making software that was crucial for billing customer. For example. Whenever you made a call, you send an MMS message. Like how do you build for an MMS message? We did it first with radio Linear at the time and it was a mess because people didn't know how to discuss or approach problem solving as a whole. There wasn't this kind of a holistic view on the ideas or the problems or the actual business. And it was like just siloed. We did some technical stuff, we didn't care.
- [05:55]
Host
We coded, right?
- [05:57]
Jussi Mononen
Yeah. And then someone did the, let's say sales and they sold something like it could be that it didn't exist. So we were kind of selling slideware or vaporware and then we were given just a like rigid time frame. Oh, I sold this one. I know we don't have it. And you have one month time to develop and deliver it. And with the advent of Agile, it kind of basically it opened up the perspective that you have to have a holistic approach to everything regarding software. You cannot do it in isolation. And then you emerge from a darkroom after three months and say, it's done, please sell it. It just doesn't work that way. And it kind of made sense since I've kind of, since a small kid, I've been part of like, of communities of different sizes, sports clubs and so forth, like playing for a team, being part of a soccer club. And I, I was like coaching little kids at the time in football. And it's kind of holistic approach. It partially also applied to the football. It's a chaotic idea of a sport. And actually like the. What is this? I'm forgetting terms. Bob.
- [07:37]
Host
No worries, take your time. We have an editor.
- [07:39]
Jussi Mononen
Yeah, because I just had a discussion with, I'm still managing a club, this is like a sports club. And we had a long discussion about chaos in football. And it was based on these British scientists work on emerging systems. And with this I just can't pinpoint it. But anyway, the human approach kind of enlightened me that the only way to make reasonable software that provides benefits for people who will be the end users, because even though we sell it to companies and people like trade companies as customers, there are in the end it's always humans who will use the system or enjoy the benefits that a system brings. And you have to involve all the people in there. So that's kind of where it started. It's not a single bright moment. It's not like I can say this date, but it was kind of a gradual progress. Within a month when I started to learn that, hey, we do have these humans everywhere. So.
- [08:58]
Host
And this focus on humans, of course, I mean, very often in Agile we talk about humans as the team. Right. Like the humans developing the software. But you're talking about much more than that. You're talking about the humans who ask for the software to be developed. That would be the business side, sales, marketing, the CEO, whatever, and those who.
- [09:15]
Jussi Mononen
Will, and the end users and the.
- [09:18]
Host
End users and also the customers. Right. Because it's not just end users. In some cases, you have customers and end users as separate.
- [09:24]
Jussi Mononen
Yeah.
- [09:24]
Host
So because when you, when, when you think about your role as a cto, how do you now bring that perspective, that more humanist perspective into the work that you're doing as a cto?
- [09:35]
Jussi Mononen
Well, we talk a lot to our customers and I have this little habit of declining every single idea of a new feature or a new product. Or anything related to software initially. Because I want that every single time that someone asks for a feature or a new approach or something, that they actually have to argue. Why? Because in the end every piece of software and every line of code that you write will be a liability because you will invest time and money in there and then you have to maintain it. You have to, for example, from a developer perspective, you have to have documentation or you have to make sure that it works and it's readable. And from a company's perspective, it's a liability because you have promised and you have delivered that to someone. Usually I approach the software that the software is done when you actually pull the block and nobody is using it until that moment, someone is in a position to maintain it, to be aware that it exists and be aware how to keep it up and running. So every single line of code or a feature or system will become a liability. And this is directly related to total cost of ownership. And we are talking about decades, not like months or days. I'm talking about years and, and most likely decades. When you create, for example, a larger software systems, you had to approach the initial design in a way that you have long enough time span. If you design or architect software within like just thinking one year forward, most likely you will miss something crucial. Things will live longer than you expect.
- [11:39]
Host
Okay, so that is, that is absolutely true. Okay, so there's a couple of topics here that you approached that I think are great as segues for the next question. So you talked about, okay, you know, as much as possible, talk to your customers. Don't consider software ever as done until it's no longer running. Right? It's dead, it's gone, it's no longer running. Every line of code is a liability. And make sure that you think about the longer time span, not just what you need to deliver tomorrow. Those are all great tips and heuristics, especially when you need to make sure that the tech strategy like this, longer term and the aspect of maintainability and all of that that you were talking about needs to align with the business objectives, which are in many cases, even in startups like you, even more. In many cases those business objectives are kind of a lot more shorter term. Right. And we need to kind of manage, as CTOs, as technology leaders, we need to kind of manage this understanding of the long term sustainability of the code base versus the short term demands from the business. How do you do that at Carbon Link?
- [12:50]
Jussi Mononen
Yeah, there are a couple of different views on that. First is that when we started about four years ago. And we don't call ourselves startup anymore. We are more like a growth company. We are now like financially independent. So we are kind of financing ourselves with our software. But basically first you have to figure out the technology that will kind of. You can trust the technology in a way that it will be operable, maintainable and usable for the next 10 years. And still you have to select in a way that allows you to move really fast. When we started we are using dynamically typed language which lives in Java ecosystem. So basically our backend is written still in clojure. The idea is that it's dynamically tight so it removes some development burdens, it allows us to move real fast. But still the backend is jvm, the Java virtual machine which is capable of enough performance and it's mature and it has one of the largest ecosystems in the world regarding programming. So we thought about these things like we want to move fast, so technology cannot limit us, but we need something that we can maintain and be sure that it's viable in 10 years. These are one of those aspects and then one that we thought about a lot is that if we choose this technology stack, can we find people who are already familiar with it? Like if you compare to JavaScript world where things move really fast, there's a new framework like every six months. You have to be really careful what you choose so that you don't get the latest gimmick and then someone just stops maintaining it. And you have a framework or technology in your hand that is no longer maintained when it becomes your liability because you have chosen that as the choice of weapon like to do so. This kind of. It's an act of balancing things. You want to move fast, you want stability, you want certain level of maturity regarding the technology choices you have and so forth. And it's. Well, you have to be really agile in a way that for example, in the startup phase you have to get rid of technologies that do not work. But when you get your first customers, you have to really think can this technology take the heavy load that the customers and the kind of responsibilities you accept when you take money from someone else, are they a match? Can you do it with these technologies? That is kind of things that we thought a lot. And your mileage may vary, but you have to trust on those technology decisions that you make that they don't inhibit you or prevent you from moving fast enough. But still developing software that can stand the time so that you don't need to rewrite your software every year.
- [16:25]
Host
That'S actually a very important point to think about how the technology that you choose will enable you given the business goals that you have. For example, if you're doing one off single use tools that do very simple things, you're going to have different set of technology constraints than if you're creating a system that has to be audited, probably security critical, mission critical for your customers, and needs to be maintained for decades. So that's a very good point. But how about the collaboration? Because you still have that. You talked a lot about this kind of balancing out the different demands and in collaboration, going back to that humanist perspective you were talking about between business and technology, what are some of the key practices that you've put in place to make sure that you're still listening to the business, not just trying to get the perfect quote unquote technology, but at the same time that you're respecting that vision of what maintainable technology looks like without bending too much to the business. How do you make that collaboration work?
- [17:31]
Jussi Mononen
With respect and trust, basically. I have this kind of optimistic view of humanity so that I want to trust people at this point of my time. Like I've been doing this for quarter century and I'm in a company, I believe that we are all adults. So I expect and I give respect to people and their opinions and then I trust them to make the decision that they need. And I appreciate like open dialogue and debate. One thing that I've learned is that one, especially in technology where we have lots of smart and bright people, one of the like biggest personal mistakes that you can make is to become jealous about your own choices and preferences. So I try to give lots of leeway and liberties to others. So if they are like we had a really interesting debate a while ago where we actually moved from a dynamically typed language in our front end into a really statically typed language because it kind of, it empowered one of our developers a lot more. His productivity grew a lot because he had much more experience in statically typed languages than in dynamically typed. And he had lots of personal preferences that it gives him a certain level of assurance that my invention will work with this. And we discussed, we debated like all of these aspects that I already mentioned and then, okay, you want to try it, make a proof of concept. If it works, just go ahead. So as a cto, I don't want to dictate technology's choices. I just want to make sure that all the choices that we make are thoroughly pondered through. You have to think from all the decision from a Multiple aspect, like I said, total cost of ownership. Is this viable for the long term? Does it have a major enough ecosystem or do we believe that it will gain such attraction that there will be so that we don't have to maintain it for ourselves? And can we find enough experienced people or people willing to learn these technologies that we can kind of get new developers or if someone changes his path and wants to work somewhere else, that we can replace someone with a new person? And if we can argue and get a reasonable result. And this is not like a discussion where there's a winner. No, this is kind of a discussion where we end up in a situation that we can all live with and we believe that these decisions are good, timely and they can stand the test of time. Technology is like a rounding error. You can do great stuff with almost any technology. So I'm more interested about people who will be using those technologies than the actual technology. Of course we have, let's say non functional requirements like security robustness and storing data and stuff like that. So we have to be careful and we will do our due diligence on that side. But then it will be people who will be developing software. And I would like to maximize the potential that every person has. So I trust people with the choices that they make. And maybe I consider myself more like a shepherd of brilliant people than just like dictating something. And I try to just goad people into the same direction. So we put some limits, like you shouldn't go beyond these limits that we said unless it's absolutely necessary. You can argue why and then we give a direction and then we just trust people and the processes that we have in place to support the business, the people, the users and everyone involved around us and our small financial business ecosystem that we have at the moment.
- [22:11]
Host
Yeah, absolutely. And it's beautiful to hear how you brought that person or people centered aspect back into the conversation about maximizing the potential of each person in the team. And of course that means of course the business people as well as the developers, the testers and whoever is involved. But another aspect that is particularly difficult for many CTOs out there is road mapping. Right. Because you're both in the middle of what needs to be delivered yesterday and also thinking about what the future looks like and doing those pondered decisions as you were just talking about. So in your role as a cto, talking to business, talking to customers, talking to the team in the engineering, engineering department, how do you keep the future in your horizon as a leader through.
- [23:00]
Jussi Mononen
Road mapping, revising it weekly Currently we have this kind of all hands on deck meeting once a week where we kind of address every aspect of our company's problem domain. So we get the latest from the customers, we get latest from our technical support, we get the latest from developers from everywhere and we try to come up with a vision what will happen during the next week. This is our way of kind of organizing. We have remotely working people, but we kind of meet in person once a week. And after these discussions they usually take like two to three hours. And after that I usually go back to our backlog. We have a trailer, like we are using a software called Shortcut, which is kind of a trello type of list of lists where we have like ideas and well, lots of columns with stuff and I mess it up. I kind of figure out the overall priorities of bigger ideas and I try to maintain a roadmap for roughly 2/4 at a single point of time. We roughly know what were the signals from our customers and what do we see internally, like do we need to strengthen some aspect of our program or is there a new feature that we figured out based on some feedback that we need? And then I try to keep it visually available all the time for everyone. This is how we see the next three to six months. And at the moment we don't look any further than that because then it falls more on the strategy of the whole company. Like where do we want to be in three years of time? And our current domain as we working with companies reporting like the, you know, the EU standard of CSRD which requires companies to report the carbon footprint about their good governance and social responsibilities, which is EU directive and it's mandated and it still evolves and we are in that business. So there will be regulation that is mandatory, it will shape the business, there will be reporting needs that will change constantly. So we have to be on our toes all the time. Like what, what happens in the EU level, what happens on a long term.
- [25:47]
Host
Those changes are also longer term than two quarters. Right. So how do you keep that, that kind of updated roadmap for the next two quarters, but then also taking the signals like legislation that might be coming in a year ahead?
- [26:02]
Jussi Mononen
Yeah, we follow a lot of like work groups, we follow local accountants, for example, because the responsibility of checking the CSRD reporting as part of the financial sheets that every company has to produce yearly, it's falling for the accountants. And we have an ongoing dialogue with all of these instances in Finland that need the information we provide. And of course the companies who need this for their Own purposes, like multiple purposes for calculating your organization's carbon footprint. And so we have to be aware of quite variety of signal sources. So there's EU level legislation, EU level work groups like legislation locally in Finland, workgroups here in Finland who are working with the legislation. And then of course the customers, we have pioneer customers who want to know their carbon footprint. Despite the legislation, they want to know it. Then we have customers who just say that we need this so that we can take part in this beat of this large global cooperation, but we don't actually care, but we need to have it. So there's like, we have a lot of signals and it's like reading every week, is there anything that we need to react to? And then we try to also make some forecasts on our own based on all the signals we get from this forecast.
- [27:39]
Host
You mean forecasts for what might be coming in terms of requirements and so on, right?
- [27:44]
Jussi Mononen
Yes. In terms of roadmapping, it changes the order of priority. I don't mean that we forecast that in September 19th we will have this. No, I have just like a boxes with varying lengths that might or might not imply the amount of effort it will take to create it. It's just my best guess. And then I just reorder the boxes like next two months we most likely will be doing this and it might change weekly. So we are kind of taking really low level and responsive approach to roadmapping.
- [28:25]
Host
So you have these different signals coming in that helps you to figure out the longer term trends. And then you have this weekly cycle where you evaluate all of these signals and how they impact what we are currently working on. And then you have kind of the middle way, which is this two quarter ahead roadmap that kind of merges the two views, right?
- [28:46]
Jussi Mononen
Yeah, yep. And the middle one, the kind of the one or two quarters is basically for the board of the company because they want to know where are we heading for internally? I hope that everyone is kind of aware where we are going because we are doing the work itself. But I'm part of the board of the company and they really need to know and we present it in every meeting that how do we see to market in a technological way and where are we going? So they just like keeping the board informed. How do we see the near future? So there are actual, there's consumption for that information. So I keep maintaining it.
- [29:32]
Host
Yeah, absolutely.
- [29:33]
Event Promoter
That's a great point.
- [29:35]
Jussi Mononen
Yeah. I don't do it for myself or for the company. Of course I can, I can use it just like to visualize quickly, like, hey, this is how we see. Do you have any input or do you disagree? Is there something that needs to be in here? So it's a tool of discussion, but also kind of because we are in a growth phase, trying to grow quite rapidly. So the board is really interested, like our direction technologically.
- [30:02]
Host
And it's a really great idea, this idea of having these different types of signals, right? Like you have the technology signals, that might mean we need to adapt to the team's skills and what they feel comfortable with. You have these customer signals, you call them pioneer customers. What do they care about? What are they looking at? And then you have the legislation signals. And that comes from different levels, different groups and so on. That's a really great way to also visualize how the roadmap is evolving from different perspectives. Now, not all of these things are simple. So I wanted to tackle a particularly big and difficult challenge that you faced in your career. So what's the biggest challenge that you faced in your career and how did you overcome it? Or maybe you haven't and you're still trying to.
- [30:50]
Jussi Mononen
Well, it's hard to say what is the biggest technologically? I would say maybe it was the four and a half year stint while we were rewriting completely the systems for universities here in Finland. So they had this like 20 year old system that had been refurbished a couple of times and it didn't kind of cater for all the needs that universities had. So in 2014 they started a project to renew the whole system. I joined the developing team in 2015 and when I left in 2019 after four and a half years, I think three of the largest universities had already migrated this new system. And it caters for all the students and the needs of their designing their studies. It caters for all the teachers, lecturers, how do they provide the required information and then it provides for the administration who actually then control the operations. And it was kind of a moving from a really dinosaur like system into a modular, shareable system between completely different organizations. There was one really good description, like if you take randomly five middle sized listed companies from, let's say from housing stock market, and you write a single system that should serve all of them. That was the problem domain that we had. Every single university has like hundreds of years of history and their own way of doing things lightly.
- [32:51]
Host
Different things, yes.
- [32:54]
Jussi Mononen
And the only kind of common thing was legislation regarding education. And we had to come up with a system that addresses all the needs of all these universities here in Finland. Like the longest history is 450 years of economic, let's say this kind of universal freedom they were free to do in their own ways and they were all different. So managing those expectations, managing those technologies, I wasn't the only one and I wasn't the person responsible for everything. We had a great team, great team there. But we started with six persons on the development side and we had like five, you could call them product owners who were kind of driving to content from the university perspective. We came up with a system that is in production, has been for four, five, six years now. It's growing constantly. More universities and polytechnic schools are joining and taking it into use and it's even in a shape that you could actually use it in everywhere in Europe. So it's really resilient, it's versatile. I think that was like the, the biggest problem that, that I've encountered. I have lots of like small but really contained issues. I don't see those as crucial or something pivotal. They're more likely. This is work and I'm a kind of a solution oriented person. So I just take the challenge at hand and I drive directly at it.
- [34:45]
Host
When you think about that four and a half year stint rewriting systems for universities that were all different, what are some of the key tips that you take from that experience that you want to share with aspiring or Even already practicing CTOs?
- [35:08]
Jussi Mononen
You have to be able to live with constantly contradicting and changing requirements. That's like, from a philosophical point of view and from a mental health perspective, it's a constant storm, it's a constant struggle and it's really hard to maintain the focus because the demands are so different and varying and you need to have this kind of abilities to work as a middleman. Like you have to be able to focus on getting some kind of a compromise out of it because the requirements are so vastly different and the people's expectations are so different. You need to have the capabilities, produce some kind of technological focus and a kind of an outcome that everyone can agree. Then when we have agreed that, okay, we will go towards this idea, then everything suddenly becomes a much smaller problem and they are like solvable in a smaller context. So then you can work with bounded context, like what type of services do we have, how do we store this data, how should we model our data and so forth. They are bounded contexts that you can console in technological way or in a business way that supports the overall goal. So it's just hard to kind of take that channel of people and desires, feature requests and Then the portion of legislation, it's jungle. And you have to kind of carve your path somehow. And it requires a lot, like mentally, you have to have stamina. It takes years.
- [37:05]
Host
Absolutely. Be ready for it, right?
- [37:08]
Jussi Mononen
Yeah, yeah. It's not easy. It's not going to be simple. But it's really rewarding when you actually see that, hey, this will work and we can make it work. But it, it kind of requires capabilities that you don't think at first. When you think about developing software. We're talking about people abilities. Like how do you.
- [37:31]
Host
Humanistic abilities.
- [37:33]
Jussi Mononen
Yeah, indeed. We are back into people. So we had an excellent team. We had even a kind of a meeting room that was named the shouting room because people were so adamant of getting their own way that they were shouting at one point of time. Then we had to interfere, like, hey, we're all adults, come on, we want to. And we can have some kind of an idea that will, that will satisfy the needs of everyone in a way that we can move forward. So lots of people skills and I don't even want to go to. Yeah, we use, we used Jira, of course. It's like this bottomless pit where you can put all your wishes and wants and you'll never see them again. But you can make it, you can even make that work. It just requires that someone needs to take care, that someone gives enough love for the items in the backlog, at least in a way. Like I described this next six to three months that what are we going to do? What are the bigger objectives that we want to achieve within the next like three or four months and keep them like afloat in a shape that you can discuss, you can debate, you can argue, you can reason with them. And it requires people, it requires time. If you are just a developer, this kind of a position might not be the best one because you need to do a lot of non development stuff like looking at those requirements and digging through all those archaeological layers that you can find in Europe.
- [39:28]
Host
And the archaeological layers, I love that. So you see, we're getting close to the end. But I do have two questions, quick questions for you. The first one is, as a cto, what was the book that most influenced your approach to that role?
- [39:54]
Jussi Mononen
There's no. I wouldn't recommend a book. Books are missing one crucial thing that I think is crucial from my point of view and it's context. The crucial thing for me has been the people I've been working with. I like this idea that I kind of. I read from a. Was it Chad Fowler, who wrote a couple of Agile Books in 2008, 2,010 times. He was an avid jazz player, jazz musician, and he had this idea of always being the lousiest musician in the band. And I've strived to be like the lousiest developer or architect in the team that I work in. Why? Well, because if everyone else is smarter, more experienced or brighter than I am, I will learn. So instead of a book, I would suggest of choosing the context more accurately. Like involve yourself with people who do you. Who you like, kind of you look up to. And if you can work with those people or smarter people or who have more experience, go there and be like a sponge and suck it all in. That's been kind of. That's, that's my idea. Yes. You can read like books about architecture and like tackling all of these technological issues and most likely there are lots of good books. But for me, I've just kind of immersed myself in the experience of other people and try to kind of learn from there, like by doing being inside the context, getting your hands dirty.
- [41:47]
Host
And so that's getting back to that it's all about people statement that you had in the bio for sure.
- [41:54]
Jussi Mononen
Yeah.
- [41:54]
Host
So you see, we're getting close to the end. The last question is what about if people want to get in touch with you, learn more about you and even Carbon link, where should they lock? Where should they go?
- [42:05]
Jussi Mononen
Yeah, LinkedIn. I have reduced my use usage of social media because it took too much time. But LinkedIn is one way just you can find me on LinkedIn. And then of course our company has a website and here's my picture and name and it's like first name, last name at Carbolink Fi. If someone wants to add something about me.
- [42:31]
Host
Absolutely. We'll put the link to those on the show. Notes. Jussi, it's been a pleasure. Thank you very much for your generosity with your time and your knowledge.
- [42:39]
Jussi Mononen
Thank you. I always love to babble about these things because as I said, this is like two people now discussing. It's all about people.
- [42:50]
Event Promoter
Hey friend, thank you for staying here. Is all you need to know about the Global Agile Summit. If you've ever suffered or know people who are suffering from Agile fatigue, this event is for you. Agile fatigue is that feeling that settles in when we can't really see a light at the end of the tunnel.
- [43:11]
Host
We get discouraged.
- [43:13]
Event Promoter
Especially when conversations revolve around the same old frameworks, the same old buzzwords and theories. We don't feel that energy anymore. Well, the Global Agile Summit is a different kind of event. We're bringing you real life first person stories of Agile succeeding out there in the real world that will inspire you to take action and transform the way you work. The Global Agile Summit will happen in Tallinn, Estonia May 18th. That's the workshop day. Then 19th and 20th, the conference day. And Tallinn, Estonia is one of the most innovative tech hubs in Europe. The Global Agile Summit is hosted together with Latitude 59, which is, which is kind of a citywide celebration of software startups and groundbreaking ideas. And we'll have a shared ticket for you to attend those events as well. So who will be speaking? Well, we've got an incredible lineup of thought leaders in software and agile. For example, Clinton Keith, the person who wrote, literally wrote the book on game development with Scrum and is busy bringing Agile to the world of game development. You must check his session. The very famous and well known Jurgen Apelo, author of Management 3.0, will be talking and exploring about AI's impact on leadership. We also have Goiko Adsic, who's taking an unconventional look at product growth with his Lizard Optimization keynote. Other speakers include, for example Sixven Dietz, who's challenging everything we know about software development by ditching, literally ditching contracts and estimates. Can you imagine his teams deliver software before their competitors are even done with the contract negotiation? How agile is that? But there's more. We'll cover engineering practices in our developer track with talks on, for example AI assist, test driven development, developing products in minutes with a different approach to how we develop, configure, deploy platforms, and much more. We also have a product track where we cover cutting edge ideas around product discovery, delighting customers with product delight frameworks. We'll have a talk about that. And we also have an Agile business track where we will talk about, for example, Open strategy, a very agile approach to managing organizations and delivering software faster to clients faster than you can even write a contract. Literally. I mean, I already told you about Svendeet's story is amazing. It definitely is a must see. I'm sure you'll be inspired. Get a lot of ideas for your own software projects and software delivery. Now, whether you're a business leader, a product innovator or a developer, you'll definitely find value in our three focused tracks. That's Agile Business for those working with businesses and organizations, Agile Product for product managers, product owners and innovators, and Agile Agile Developer for the builders making agile work in practice, the coders, the testers, the designers, the producers, the Scrum masters you name it. If you join, you will meet over 200 agile professionals from all over the world. People who, just like you, want to grow, want to share, and want to learn. By challenging the ideas that don't work anymore at the Global Agile Summit, you'll get new connections, fresh ideas, and the energy to take your own Agile to the next level. And who knows, maybe even find your next career opportunity. So don't miss out. Check out the full program and grab your ticket now@globalagilesummit.com I'm really looking forward to seeing you all in Tallinn, Estonia in May.
- [47:28]
Host
I'll see you there.