Startups Guide To Navigating The

00:01 → 00:05

Hi, and welcome to Meric Studios modernization themed

00:05 → 00:06

LinkedIn live session.

00:06 → 00:11

I'm Alexandra, and I'll be your host for the next hour or so.

00:11 → 00:15

Our topic today is software modernization team dilemmas.

00:15 → 00:19

And today, we are joined by two amazing guests,

00:19 → 00:22

Wojtek and Tomaj. Hi, guys. How are you?

00:22 → 00:24

Hello. Hi.

00:24 → 00:26

Hi. I'm fine.

00:26 → 00:29

Before I introduce our guests,

00:29 → 00:32

let me start with some housekeeping.

00:32 → 00:35

So this session is scheduled to last about an hour.

00:35 → 00:38

First, we will have a discussion between the three of

00:38 → 00:41

us, then we'll have some time to answer your questions.

00:41 → 00:45

And of course, we can't wait to read your opinions,

00:45 → 00:48

to read your your comments,

00:48 → 00:50

and to answer your questions.

00:50 → 00:54

So leave them in the chat box on LinkedIn and

00:54 → 00:58

in the comment box on YouTube.

00:58 → 01:01

And I also have some good news for those of you who can't make

01:01 → 01:05

it today because we'll be recording this discussion.

01:06 → 01:09

Then we'll post it on Merix Studios Insights,

01:09 → 01:13

and of course, we will notify you via our social media.

01:13 → 01:13

Okay.

01:13 → 01:19

So I think it's high time I let my guests introduce themselves.

01:19 → 01:23

Wojtek, could you first tell us about your experience in

01:23 → 01:26

IT and about what you do in Merix Studio?

01:26 → 01:30

Yeah of course, so I'm a senior project manager at Merix

01:30 → 01:34

Studio basically I've been managing IT

01:34 → 01:37

projects for the last six years or so,

01:37 → 01:43

I guess most of them in software house environments basically.

01:43 → 01:47

I'm a huge scrum and agile enthusiast,

01:48 → 01:51

so happy to share some of my thoughts about

01:51 → 01:53

this kind of projects as well.

01:53 → 01:55

And basically what do I do?

01:55 → 01:59

I make sure the communication is smooth and I make sure that

01:59 → 02:03

all of the involved in each project,

02:03 → 02:06

each product understand each other basically and support all

02:06 → 02:12

of our teams and support our clients and whatever they need basically.

02:13 → 02:14

Thank you, Wojtek.

02:14 → 02:18

Tomaj, could you tell us a few words about yourself?

02:18 → 02:20

Sure.

02:20 → 02:21

Hi.

02:21 → 02:24

I'm Tomaj, and currently, I'm a back end engineer

02:25 → 02:27

manager at Merix Studio.

02:27 → 02:31

I have over a decade decade of commercial experience in this

02:31 → 02:34

field, in the field of back end

02:34 → 02:36

development, of course.

02:36 → 02:40

Currently, my role is focused on development

02:40 → 02:43

teams, helping people to grow,

02:43 → 02:46

improving internal procedures and tool sets,

02:46 → 02:50

and also recruiting new specialists on board.

02:51 → 02:53

Thank you, Tomai. Thank you, guys.

02:53 → 02:55

I'm really excited to have you both here.

02:55 → 03:00

It will be very interesting to listen about these two

03:00 → 03:04

approaches, the project manager ones and the developers.

03:05 → 03:08

Okay, so I think we are ready to begin.

03:08 → 03:12

I'd like to start with kind of a basic,

03:12 → 03:14

but I think a very important question,

03:14 → 03:19

because software modernisation is usually singled out as a

03:19 → 03:22

separate service on Softohaus' websites,

03:22 → 03:26

and it's usually juxtaposed against greenfield project development.

03:26 → 03:32

So my question is, do these types of projects are really that different?

03:32 → 03:36

So how does software modernization differ from

03:36 → 03:37

greenfield projects?

03:37 → 03:39

Tomaj, could you begin?

03:39 → 03:41

Sure.

03:41 → 03:43

From my point of view,

03:43 → 03:48

I think that the software modernization projects are

03:48 → 03:52

different in terms of the state that you

03:52 → 03:55

meet the project for the first time because

03:55 → 03:59

every time you start a Greenfield project and you can

03:59 → 04:01

choose whatever technology you want,

04:01 → 04:05

you can use your own preferences or

04:06 → 04:07

do some

04:09 → 04:13

research and and pick the technology that you think that

04:13 → 04:15

would be the best fit for the project.

04:16 → 04:20

But in the in the software modernization, you

04:21 → 04:22

you enter the project,

04:22 → 04:25

the decision already have been made about the technology used.

04:25 → 04:28

So you have to adjust to what is

04:29 → 04:30

what is already there.

04:32 → 04:34

Many times, there is

04:34 → 04:36

there are some

04:38 → 04:41

dependencies or or technologies that are outdated.

04:41 → 04:44

So you have to

04:45 → 04:46

think in a different way.

04:46 → 04:51

You have to take many things into consideration on the start.

04:52 → 04:57

So it requires much more experience and

04:57 → 05:01

much better knowledge of the tool set that is used

05:01 → 05:03

in the in the project.

05:03 → 05:07

So the entry work is is much bigger in in terms

05:07 → 05:11

of of software modernizations in comparison to to

05:11 → 05:12

greenfield projects.

05:13 → 05:17

So put shortly, it's not as simple and it's much more complex.

05:17 → 05:19

Yes.

05:20 → 05:23

Wojtek, could you do you think you can add something to that?

05:23 → 05:26

Yeah. Of course. I well, I totally agree with Tomik.

05:26 → 05:28

Of course, that's basically what the difference is,

05:28 → 05:32

but that has some implications basically which are very

05:32 → 05:33

important from my point of view.

05:33 → 05:37

Right? As a manager, as a scrum master basically of the teams.

05:37 → 05:41

So the biggest difference which I would like to say

05:41 → 05:44

basically is that modernization is a is a marathon,

05:44 → 05:46

not a sprint, basically.

05:46 → 05:49

The biggest difference is that they take longer,

05:49 → 05:53

they last longer, they are less dynamic

05:53 → 05:58

compared to Greenfield MVP proof of concept and that sort of stuff right.

05:58 → 05:59

So

05:59 → 06:04

if we are taking over a project from proof of

06:04 → 06:06

concept state let's say

06:07 → 06:10

it's sometimes very difficult for the clients to understand

06:11 → 06:13

that we we need to slow down a little bit.

06:13 → 06:16

You know, that crazy Eldorado of deploying every day or every

06:16 → 06:19

two days and new stuff and adding new features and

06:19 → 06:23

functionalities on a daily basis sometimes you know just

06:23 → 06:27

well basically to be faster to get to the market as fast as possible

06:29 → 06:33

that's in most cases already passed right so

06:34 → 06:39

this also well, ski is not the key here exactly

06:39 → 06:42

due to the topics that Tom like mentioned.

06:42 → 06:44

Right? You cannot decide quickly right now.

06:44 → 06:47

You have some boundaries that you need to take into

06:47 → 06:50

consideration within every decision you make.

06:50 → 06:52

And the biggest thing is

06:53 → 06:58

that every change has an impact on a huge amount

06:58 → 07:00

of functionalities code base and so on and so forth.

07:00 → 07:03

Because most likely the product is already big,

07:03 → 07:07

so we simply cannot afford to go fast as fast as previously, right?

07:07 → 07:12

Yet still you can go fast according to agile or

07:12 → 07:18

scrum basically and deploy regularly at the end of

07:18 → 07:19

each sprint for example,

07:20 → 07:21

but it takes longer.

07:21 → 07:25

Sprints are usually a little bit longer so yeah and the

07:25 → 07:29

last thing I think that's worth mentioning is also a little bit

07:29 → 07:32

more difficult to maintain engineers motivation here in

07:32 → 07:35

this kind of projects because

07:36 → 07:39

I would say the main reason is that there's a little bit

07:39 → 07:44

less creativity needed compared to being two projects.

07:44 → 07:47

Basically, as Tomik said,

07:47 → 07:50

the devs do not have the possibility to decide about

07:50 → 07:54

everything right they need to comply to the rules that

07:54 → 07:58

very often were set by someone else so they first need to

07:58 → 08:01

understand those rules which takes time and then comply to

08:01 → 08:04

them and sometimes it's not easy.

08:05 → 08:09

I'm really happy that you brought up this human topic

08:09 → 08:12

because that's after all that's the topic of our today's life

08:12 → 08:15

and that's what I'd like us to focus on today.

08:15 → 08:19

But before we move on to that I have one more question because

08:19 → 08:23

you mentioned agile and you mentioned that software

08:23 → 08:26

modernisation projects also can benefit from this project

08:26 → 08:28

management approach.

08:28 → 08:32

But then again, if you research that topic of modernization,

08:32 → 08:36

you can quite often stumble across waterfall, for example,

08:36 → 08:38

and these methodologies.

08:38 → 08:41

So would you say that agile is always a way to go in software

08:41 → 08:44

modernization or maybe it depends on some factors?

08:45 → 08:49

Well, that's a tricky question. And as always it depends.

08:49 → 08:50

Right?

08:50 → 08:54

Me personally, I think you can do any kind of projects in an agile way.

08:54 → 08:57

Maybe not scrum, but Scrumban or whatever else.

08:58 → 09:01

Because you know we need to talk about the basic

09:01 → 09:03

principles of agility.

09:03 → 09:08

So the basic principles of agility is to make a small

09:08 → 09:11

step, see what happens and adjust and adapt to that right

09:11 → 09:16

and to be perfectly honest from my point of view on

09:16 → 09:18

the traditional projects and long term projects are ideal

09:18 → 09:23

for agility because you are forced to do small

09:23 → 09:27

changes either way Everybody's a little bit scared of them and

09:27 → 09:31

you need to have time to decide if that change is what you

09:31 → 09:35

is the thing that you actually wanted and adjust to that.

09:35 → 09:36

So

09:37 → 09:42

to be perfectly honest I can't imagine a modern modernization

09:42 → 09:46

sorry project whether you release

09:46 → 09:50

once a quarter for example or even longer because you know

09:50 → 09:53

the amount the sheer amount of changes that you do and the

09:53 → 09:56

potential regression

09:57 → 10:00

that's almost scary if I think about that one.

10:00 → 10:03

So yeah definitely and of course

10:04 → 10:08

Ajay was created to help

10:08 → 10:12

projects and products that were previously

10:12 → 10:16

managed in waterfall to get better basically.

10:16 → 10:19

So that's the core idea, right?

10:19 → 10:23

How can we manage long term

10:23 → 10:27

waterfall projects better and that's why the manifesto was created.

10:27 → 10:30

So that's the root cause to be

10:30 → 10:32

perfectly honest.

10:32 → 10:34

Okay. Thank you.

10:34 → 10:37

And moving on to to our topic, team dilemmas.

10:37 → 10:39

Before there are any dilemmas,

10:39 → 10:42

you first have to compose a team.

10:42 → 10:43

So how do you do it effectively?

10:43 → 10:46

How do you build a strong software

10:46 → 10:47

modernization team?

10:47 → 10:50

Tamay, maybe you have some tips on that.

10:52 → 10:56

I'd answer with the most frequently used answer.

10:56 → 10:58

It depends because,

10:58 → 11:02

yeah, it also it mainly depends on the strategy that you

11:02 → 11:06

want to follow during the modernization.

11:07 → 11:10

In Merix Studio, we offer three default strategies.

11:10 → 11:12

Of course, this just a proposal,

11:12 → 11:17

and you can pick any thing in in between of

11:17 → 11:18

these strategies.

11:18 → 11:21

But the proposal is that there is, for example,

11:21 → 11:25

a lift and shift, which mostly

11:28 → 11:33

follows the the mechanism of moving your service to the clouds.

11:33 → 11:34

So

11:35 → 11:40

in this scenario, we will probably build your team out of

11:40 → 11:43

DevOps engineers mostly.

11:43 → 11:47

Of course, there there will be required some project

11:47 → 11:50

manager to coordinate the work.

11:51 → 11:54

There is also a strategy

11:55 → 11:57

that's called completely right.

11:57 → 12:00

And in this strategy, on the other side,

12:00 → 12:05

you would need a complete team, developers,

12:07 → 12:11

back end developers, front end developers, QAs,

12:11 → 12:14

because you would follow a normal procedure of developing

12:14 → 12:19

a a fully stretched project in this in this case.

12:19 → 12:22

So you would need a specialist

12:22 → 12:24

from all the fields.

12:24 → 12:25

And,

12:25 → 12:27

yeah, that that's mostly it.

12:27 → 12:31

Depending on the strategy, would compose your team differently.

12:31 → 12:36

But the main rule would be in in opposed to starting

12:36 → 12:40

a greenfield project, you would need much more expertise from

12:40 → 12:45

from these engineers because of the reasons I've mentioned previously.

12:45 → 12:49

This is a project that requires more know more knowledge,

12:49 → 12:52

more experience.

12:52 → 12:53

So

12:53 → 12:57

I would strongly suggest picking the the senior

12:57 → 13:01

developers for this for this projects or regular

13:01 → 13:05

devs if they are strongly motivated

13:05 → 13:09

in in doing such a such a modernization.

13:11 → 13:13

And how about the skills?

13:14 → 13:16

Are there any particular ones that will definitely push the

13:16 → 13:18

modernization project forward?

13:18 → 13:22

Is there anything that you should bet on as a CIO wanting

13:22 → 13:25

to modernize their legacy system in terms of skills?

13:28 → 13:29

Yeah.

13:29 → 13:33

As I mentioned previously, I think technical skills are very

13:33 → 13:37

demanded here because you need to dig into

13:37 → 13:40

the code that was written some time ago,

13:40 → 13:45

but by it may be written in a not best

13:46 → 13:49

using not the best guidelines that are currently there.

13:49 → 13:50

And,

13:52 → 13:56

also, I think that soft skills are very important here

13:56 → 14:00

because you need to communicate with the the team,

14:00 → 14:02

communicate with the client.

14:02 → 14:06

You need to present complex ideas in a simple

14:06 → 14:10

way so that the client could understand what are the

14:10 → 14:14

consequences or some decisions that you would probably make.

14:15 → 14:19

And also communication in the team is is very important because

14:20 → 14:23

there are so many factors that that can go

14:23 → 14:27

wrong so that you have to think in advance of the

14:27 → 14:32

of of the possible consequences of of your actions.

14:32 → 14:33

So

14:34 → 14:36

and the the consequences may manifest

14:36 → 14:39

themselves not only in your field.

14:39 → 14:43

I'm talking from the perspective of back end developer,

14:43 → 14:47

but anything you do on the back end may manifest itself on

14:47 → 14:48

front end also.

14:48 → 14:52

And so or if there is a mobile applications,

14:52 → 14:54

it can manifest itself in a mobile app.

14:54 → 14:57

So you have to communicate with

14:57 → 15:01

the team, and you have to think in advance of

15:01 → 15:04

what will be

15:06 → 15:09

the consequences that is basic of any decision made.

15:10 → 15:13

Yeah. I totally agree with you, Tomik.

15:13 → 15:15

And I guess from my point of view,

15:15 → 15:17

those are the two main topics as well.

15:17 → 15:17

Right?

15:17 → 15:22

So being able to communicate very complex stuff and to

15:22 → 15:25

present to the client or to the team

15:25 → 15:29

the outcomes of our actions, which can, you know,

15:29 → 15:33

sometimes be visible very far away from now.

15:33 → 15:35

Right? Compared to to between field.

15:35 → 15:36

It's not, you know,

15:36 → 15:40

it's not the case of adding a feature and it works.

15:40 → 15:42

Right? The regression might be huge.

15:42 → 15:46

So for that reason, I I agree completely that

15:46 → 15:49

you'd rather have to think about

15:50 → 15:55

experienced senior devs or at least

15:56 → 15:59

have someone who could take over a role of a technical

15:59 → 16:02

leader basically for the rest of the developers right because

16:02 → 16:06

of course there's always place for less experienced guys or

16:06 → 16:12

girls in such teams and they need to learn from

16:12 → 16:16

someone right but I would strongly

16:16 → 16:19

recommend to create a strong core for example

16:19 → 16:22

if it's a broad application

16:22 → 16:25

seeing it in a very experienced front and back end and mobile

16:25 → 16:28

for example dev and build the rest of the skill set around

16:28 → 16:34

that to create basically a self organizing and you know

16:34 → 16:36

fully skilled team.

16:36 → 16:37

So yeah.

16:39 → 16:40

Okay, thank you.

16:40 → 16:42

I believe that those who are listening to us right now and

16:42 → 16:46

watching us now definitely know what to look for in the

16:46 → 16:48

potential team members.

16:48 → 16:51

But I guess that the success of software modernization

16:51 → 16:54

projects depends not only on

16:54 → 16:58

skills but also on the domain knowledge and the access to the

16:58 → 17:01

domain knowledge about the business, about the product.

17:01 → 17:04

And it's easier to mix these two,

17:04 → 17:07

so technology and domain knowledge if you're running the

17:07 → 17:09

modernization project in house.

17:09 → 17:13

But what about situations in which you decide to outsource it?

17:13 → 17:16

So the entire process or part of it?

17:16 → 17:19

How to facilitate this transfer of knowledge?

17:20 → 17:22

Samaj, do you have any tips?

17:23 → 17:24

Sure.

17:26 → 17:30

I think that a solid fundament for this would

17:30 → 17:34

be performing some kind of workshops

17:34 → 17:37

that would include

17:38 → 17:42

in the perfect scenario, the clients in or the

17:42 → 17:46

technical person that has a huge technical

17:46 → 17:49

knowledge or or the business knowledge.

17:49 → 17:53

And on the other side, from the

17:53 → 17:57

from the side of the company that would

17:57 → 18:01

be actually perform the modernization,

18:02 → 18:05

It would be good if there would be some facilitator with the

18:05 → 18:09

background in, for example, event storming or any other,

18:10 → 18:11

let's say,

18:13 → 18:17

technologies or or techniques maybe That's a better

18:17 → 18:21

word for obtaining the knowledge from the client.

18:21 → 18:23

So this is one thing.

18:23 → 18:24

And, also,

18:25 → 18:29

a good documentation would be of the currently existing

18:29 → 18:33

solution would be very helpful when overtaking the

18:33 → 18:35

the project from a different company.

18:36 → 18:41

Also, it would be perfect if there would be some point of contact

18:41 → 18:45

with the company that developed the previous solution.

18:45 → 18:46

So

18:46 → 18:49

If there is a chance of

18:49 → 18:53

obtaining the knowledge from the from the person that was

18:53 → 18:56

in charge of developing the the previous solution,

18:56 → 18:59

it would be very helpful to have someone that you can ask

18:59 → 19:02

any question at any time and just obtain the knowledge

19:02 → 19:06

that you are missing currently and just to

19:08 → 19:11

skip the reverse engineering process of some idea and just

19:11 → 19:14

have five minute talk with someone and

19:14 → 19:17

to explain what was the idea of the author

19:17 → 19:20

of some line of code, for example.

19:20 → 19:23

Yeah. So I think workshops is one thing.

19:23 → 19:26

Documentation and some point of contact

19:26 → 19:29

is basically it.

19:31 → 19:34

Yeah, I'd like to add to that

19:34 → 19:38

chip in a little bit basically from my point of view what is

19:38 → 19:41

very important also besides the technical stuff.

19:42 → 19:45

I think the most important thing is that you know if we

19:45 → 19:49

take into consideration that we're gonna be working together

19:49 → 19:53

for quite a long time right we are modernizing together a big

19:53 → 19:58

product most probably so the way the relationship

19:58 → 20:02

between the vendor and the client basically the owner of

20:02 → 20:05

the code base and ask for example Medic studios the

20:05 → 20:07

company that's getting in

20:08 → 20:12

is very very important basically so

20:13 → 20:17

what I'd like to tell and what I would really love to happen

20:17 → 20:20

every time is that once we meet once we start

20:20 → 20:24

working together please think about the delivery team from an

20:24 → 20:28

outsourced company basically not on as executors of your

20:28 → 20:33

idea but more of our consultants sometimes

20:33 → 20:37

quite very strict reviewers of your plans and of what has

20:37 → 20:38

already happened, right?

20:38 → 20:41

And keep in mind that

20:41 → 20:46

we do not know quite a lot of what

20:46 → 20:49

happened, what has happened before,

20:49 → 20:51

why some decisions were made.

20:51 → 20:54

We will see the outcomes of those decisions and most

20:54 → 20:57

probably you will see within the code base or within the

20:57 → 21:00

process or procedure that something most probably could

21:00 → 21:02

have been done better

21:03 → 21:06

and well at least we at Medic Studio we will ask we will

21:06 → 21:10

raise those topics so please be aware that if something was

21:10 → 21:14

hidden under the rug it will most probably be found

21:14 → 21:18

sooner or later so and when it happens

21:19 → 21:23

be patient because most probably was a very good reason

21:23 → 21:27

why that was hidden or why some decisions were made

21:28 → 21:31

but also take advantage of that maybe now is the time to fix

21:31 → 21:34

that right to pay that debt for example

21:35 → 21:37

and the second thing

21:38 → 21:41

totally agreeing with Tomac transferring the knowledge

21:41 → 21:45

about not only the technical side but also about the

21:45 → 21:50

business during the pre development phase is very important.

21:50 → 21:55

So think not only about, you know,

21:55 → 21:58

passing the code base and delegating one or two devs to,

21:58 → 22:01

you know, show the code base and what's going on.

22:01 → 22:04

It's equally or even more important at least from my

22:04 → 22:07

point of view to deliver a valuable solution,

22:07 → 22:11

which is basically delivering the business value for your company, right?

22:11 → 22:15

So if we won't understand the business and

22:15 → 22:18

why do you even bother creating the product,

22:18 → 22:24

it's gonna be super difficult to maintain it and modernize it in the future.

22:24 → 22:27

And of course I'm gonna tell this

22:28 → 22:32

whenever I can like a mantra keep the team in loop and

22:32 → 22:34

be very conscious about the communication, right?

22:34 → 22:38

Because you don't know quite a lot of stuff that we do know

22:38 → 22:41

and we want to share it with you and it works the other way around.

22:41 → 22:46

So please remember that if you know you start cooperating

22:46 → 22:48

with for example Merix,

22:49 → 22:53

we have all a couple of hundreds projects already finished.

22:53 → 22:55

So we've seen quite a lot

22:55 → 23:00

even if you're a investor who has like five or maybe even ten

23:00 → 23:04

startups under your belt most probably we have a little bit

23:04 → 23:08

more so feel free to use that knowledge and

23:08 → 23:10

use that experience right.

23:10 → 23:14

To make the best of what we already have experienced.

23:14 → 23:16

Exactly, exactly.

23:16 → 23:20

So I guess it all boils down to mutual understanding and

23:20 → 23:25

just you know knowing that we are here to do our job on both sides.

23:25 → 23:29

Of course, being honest, transparent,

23:29 → 23:32

you know, key values, right,

23:32 → 23:34

of good consolation.

23:34 → 23:34

Yeah.

23:34 → 23:36

It sounds very easy and very basic,

23:36 → 23:38

but sometimes people forget about it.

23:38 → 23:43

So it's it's really good to reiterate on that.

23:43 → 23:44

Okay, in the meantime,

23:44 → 23:48

I can see that some comments are already appearing in our chat box.

23:48 → 23:49

Thank you for that.

23:49 → 23:52

We'll have the Q and A after the discussion,

23:52 → 23:55

But also feel free to ask us more questions.

23:55 → 23:59

We can't wait to go through them after we finish.

24:00 → 24:00

Okay.

24:00 → 24:04

At the beginning, Wojtek, I remember that you said that

24:04 → 24:09

one problem with modernization can be team motivation.

24:10 → 24:14

So generally, get this feeling that sometimes modernization projects get a

24:14 → 24:15

bad rap among developers.

24:15 → 24:18

So they are not very well liked or desired.

24:19 → 24:21

Is it really true?

24:22 → 24:25

Well it depends

24:26 → 24:28

as always it depends who's working with them but well

24:28 → 24:32

generally yes I guess they are right because you know

24:32 → 24:34

the obstacle well

24:35 → 24:38

every developer and basically everybody who works you know

24:38 → 24:43

with his head and with his wants to be creative right

24:43 → 24:45

everybody wants to you know challenge

24:47 → 24:51

obstacles in a creative way use the newest

24:51 → 24:54

technology when we're talking about IT,

24:55 → 24:57

sometimes maybe even try something that you have never

24:57 → 25:00

tried before and see what the results are.

25:01 → 25:04

Basically be creative and you know have the

25:04 → 25:06

space to

25:09 → 25:11

have the space to maybe sometimes even fail right

25:11 → 25:14

without very big consequences.

25:14 → 25:19

Unfortunately within organizational projects that's not the case

25:20 → 25:21

most cases right?

25:21 → 25:23

It cannot happen right?

25:23 → 25:27

So you can't just you know implement a completely new

25:27 → 25:31

library for example because you want one is already implemented

25:31 → 25:34

and you need to work with that you maybe you want try to

25:34 → 25:37

refactor it a little bit change something some small some small

25:37 → 25:41

tweaks or so but not too much more but on the

25:41 → 25:45

other hand I've also met some guys who

25:45 → 25:49

really like working with this kind of projects because

25:49 → 25:51

that's a real challenge.

25:51 → 25:52

Right?

25:52 → 25:56

They felt a little bit tired with creating yet another,

25:56 → 25:58

you know, logging mechanism,

25:58 → 26:00

payment mechanism and so on and so forth.

26:00 → 26:05

And they wanted to do something a little bit more difficult

26:05 → 26:07

with those restraints.

26:07 → 26:10

So they also have some good sides, right?

26:10 → 26:13

And you can find still

26:15 → 26:17

good things about those projects.

26:17 → 26:21

But in most cases that's why we said previously with

26:21 → 26:23

Tomic and we agree on that.

26:23 → 26:27

Those are mainly the projects for developers who

26:27 → 26:32

have seen quite a lot and are basically mentally ready

26:32 → 26:36

to manage these kinds of well completely different problems

26:36 → 26:41

and issues and what's most important who know how

26:41 → 26:44

and want to foresee

26:46 → 26:50

into the future as you know sometimes a very long way and

26:50 → 26:54

not only foresee the results of their own work but also

26:54 → 26:55

the work of other people around.

26:55 → 26:57

So

26:58 → 27:02

yeah they have a bad reputation but definitely I wouldn't

27:02 → 27:08

say that cannot be they cannot be rewarding or satisfying.

27:10 → 27:14

My point of view also you know the the the one other thing is that you know

27:15 → 27:19

if you work with greenfield and startups only

27:21 → 27:25

you don't really very often work with live apps

27:25 → 27:29

which actually have users and you see what they do

27:30 → 27:32

and here you do.

27:32 → 27:35

So if you wish you're tired of creating yet another

27:35 → 27:38

startup, I mean if you're a developer

27:38 → 27:41

tired of creating another setup that you don't really know

27:41 → 27:44

what's gonna happen with it because you know the market

27:44 → 27:48

stays you know stays for itself right how what what

27:48 → 27:53

percentage of new new products stay with us for longer

27:53 → 27:58

then look for a modernization project so I

27:59 → 28:02

would add to that that as Wojtek said,

28:02 → 28:05

more mature projects struggle with completely different

28:05 → 28:09

category of problems that new projects do.

28:09 → 28:10

Because

28:11 → 28:15

if a project is on the mark if some solution is on the market

28:15 → 28:18

for a couple of months or years,

28:18 → 28:22

then you have to deal with such issues as

28:22 → 28:25

some bottlenecks in performance or database

28:25 → 28:28

queries, and you have to

28:29 → 28:32

face a completely different

28:33 → 28:37

category of problems and come up with different solutions

28:37 → 28:40

that you would normally do when starting a greenfield project.

28:40 → 28:44

So if you are looking for some new experience or

28:44 → 28:48

some new challenges, then definitely software

28:48 → 28:51

modernization is a way to go.

28:51 → 28:52

And that's the one thing.

28:52 → 28:55

And a different another thing is

28:56 → 29:01

the better reputation of of this kind of projects

29:02 → 29:03

is there of course.

29:03 → 29:07

I agree with that but you have to keep in mind that what is

29:07 → 29:09

the cause of

29:10 → 29:14

or maybe I would put it in a different way.

29:15 → 29:20

The software modernization is performed because of some reasons.

29:20 → 29:25

And the reason probably is the the code is very very tightly coupled.

29:26 → 29:28

It is hard to maintain.

29:28 → 29:32

It is very hard to add new features because the legacy is

29:32 → 29:33

so big that if you touch one thing,

29:33 → 29:36

it would have impact on ten different things,

29:36 → 29:41

and you would not know what what can blow up simply.

29:41 → 29:45

And if their architecture is poorly designed or if there is

29:45 → 29:50

no architecture at all, just say spaghett decode, then

29:51 → 29:54

it is very unpleasant, and it may be a challenge for

29:54 → 29:57

anyone to to enter such a project.

29:57 → 30:00

But you have to keep in mind that that every time you start

30:00 → 30:02

a greenfield project and you don't follow the best

30:02 → 30:06

practices, you don't keep in mind the architecture,

30:07 → 30:10

then you are producing a legacy from the start.

30:10 → 30:15

So if you even start a new project and you

30:15 → 30:18

would perform poorly on following the

30:18 → 30:21

best practices, then every new developer that you

30:21 → 30:25

join your your new project after a month,

30:25 → 30:29

they enter actually a legacy project with the legacy

30:29 → 30:30

that you produced.

30:30 → 30:31

So

30:32 → 30:37

the best practice would be not producing the legacy code in the first place.

30:37 → 30:41

And the only difference here is that if you enter a a

30:41 → 30:42

modernization project,

30:42 → 30:45

then the legacy is not produced by you but someone else.

30:45 → 30:49

So you have someone to blame for the poorly written

30:49 → 30:54

code, but you have to keep in mind that everyone

30:54 → 30:59

had some point in his life that when you were were learning

30:59 → 31:01

new new things and

31:02 → 31:06

the the main success was when the when the code code

31:06 → 31:10

was actually working and not how it was written.

31:10 → 31:14

So this is another level of experience

31:14 → 31:18

and another level of being a a good developer when

31:18 → 31:20

you not only

31:20 → 31:24

put your attention on the the code whether it is actually

31:24 → 31:27

working, but also whether it is maintainable,

31:27 → 31:29

whether it is testable,

31:29 → 31:32

whether a new developer that would have to maintain your

31:32 → 31:35

code would be able to do it in the first place.

31:35 → 31:36

So,

31:37 → 31:39

yeah, that's from me.

31:40 → 31:44

So, Thelma, do you mean that it's kind of a mistake to to

31:44 → 31:48

think about tech debt only in terms of software modernization

31:48 → 31:51

and these very old systems?

31:51 → 31:54

Is it something that's building up from scratch, like,

31:54 → 31:57

the day one when you start working on project?

31:57 → 31:59

Of course. This is absolutely true.

31:59 → 32:04

Most most of the people when when you are using a phrase

32:04 → 32:05

legacy project,

32:05 → 32:07

they think of a project that was on the market for,

32:07 → 32:10

let's say, ten years, and it was written in language

32:10 → 32:13

that not currently exist, and the people who written it

32:13 → 32:15

are already dead probably.

32:15 → 32:18

But this is not true because, as I said,

32:18 → 32:22

you can produce a legacy code in two weeks or or one month.

32:22 → 32:25

And if you don't follow any good

32:27 → 32:29

if in mind when developing the code,

32:29 → 32:31

you already produce a legacy code,

32:31 → 32:37

and it would be very hard for any new developer to to enter such a project.

32:37 → 32:40

Okay. I see.

32:41 → 32:44

And you mentioned that there are some developers who enjoy

32:44 → 32:47

taking part in modernization.

32:48 → 32:51

But I suppose that even those who are really excited about,

32:51 → 32:54

you know, tampering with the old code and seeing the

32:54 → 32:59

progress can experience some burnout sooner or later.

32:59 → 33:02

So how do you prevent that from happening?

33:02 → 33:05

How do you keep your team engaged and motivated?

33:05 → 33:09

I know that it's not possible you know every day but I

33:09 → 33:13

suppose there are some general rules and tips for that.

33:13 → 33:17

Wojtek do you have any of them to share with us?

33:17 → 33:20

Well yeah from my perspective the most important thing is to

33:20 → 33:22

keep the team

33:23 → 33:26

understanding and up to date with what they are actually

33:26 → 33:28

doing and why, right?

33:28 → 33:29

Because

33:29 → 33:32

you're doing everything for a reason.

33:32 → 33:35

One of the main reasons is and also please remember

33:35 → 33:38

that in most cases if

33:38 → 33:42

someone decides to modernize a project and has a budget

33:42 → 33:46

for it and agrees that it's gonna take a very long time

33:46 → 33:49

then most probably the product is already a success,

33:49 → 33:50

Right?

33:50 → 33:54

So you are then working in a

33:54 → 33:57

successful project from day one,

33:57 → 34:00

although it's completely different and very difficult.

34:00 → 34:02

I think that's one thing.

34:03 → 34:06

The other thing is to keep the team very close together.

34:06 → 34:06

Right?

34:06 → 34:10

And the team that is well,

34:10 → 34:13

in most cases it won't be just one team.

34:13 → 34:14

So

34:15 → 34:17

two topics that I wanted to talk about.

34:17 → 34:20

Keep the team very close to each other and don't allow them

34:20 → 34:24

to, you know, silence each one into a different,

34:24 → 34:27

you know I'm just into a mindset where, okay,

34:27 → 34:28

I have a task.

34:28 → 34:30

I'm gonna finish it, and I don't care about the rest.

34:30 → 34:34

That's basically one of the biggest challenge to keep that

34:34 → 34:35

mindset set.

34:35 → 34:37

Guys, don't do it like this because, you know,

34:37 → 34:41

you're gonna be creating legacy on a biweekly

34:41 → 34:44

basis, basically.

34:44 → 34:45

Right?

34:45 → 34:49

And the other thing is always try not to silo

34:49 → 34:52

the whole development team from the rest of the company.

34:55 → 34:57

Updates the team on sales,

34:57 → 35:00

update the team on marketing strategies,

35:00 → 35:04

update the team on customer feedback,

35:04 → 35:07

have the designers on board also.

35:07 → 35:10

So the constant flow of communication and of

35:10 → 35:14

understanding and of the vision and the goal basically.

35:14 → 35:18

Why are we here? Why do we have to struggle so much?

35:18 → 35:21

And what's at the end of the road basically? Right?

35:21 → 35:22

We can see the light,

35:22 → 35:25

but please tell us what that light is exactly.

35:25 → 35:28

Oh, it's a little bit easier.

35:29 → 35:31

So I guess those are the most important things when it comes

35:31 → 35:35

to, you know, keeping the team motivated.

35:35 → 35:36

Right?

35:36 → 35:39

I'm not gonna talk about, you know, pizzas, beer,

35:39 → 35:43

and that kind of stuff because it's quite self explanatory.

35:43 → 35:46

I can tell you that is sometimes, you know,

35:46 → 35:48

if the team is really

35:49 → 35:51

if the team is great,

35:51 → 35:54

then you can even change a late night deployment,

35:54 → 35:58

post deployment back fixing into a party afterwards.

35:58 → 36:00

So,

36:00 → 36:03

yeah, it is doable.

36:03 → 36:05

It's hard for the problem.

36:05 → 36:10

I also think that it would be a lie to say that this kind

36:10 → 36:13

of project is for everyone because it it's certainly not.

36:13 → 36:17

It requires a certain attitude, and

36:18 → 36:21

you have to somehow answer as a developer,

36:21 → 36:22

you have to answer a question,

36:22 → 36:25

what is the source of your motivation and

36:25 → 36:26

fulfillness?

36:26 → 36:27

Because

36:27 → 36:31

if the main source of your motivation is providing

36:31 → 36:35

a code that is just working in a simplest possible way,

36:35 → 36:37

then probably this is not for you.

36:37 → 36:41

But if your source of motivation and the feeling of

36:41 → 36:45

fulfillness is when the code that was written

36:45 → 36:49

poorly suddenly after not suddenly,

36:49 → 36:53

but after weeks of hard work

36:53 → 36:57

is written in a very

36:57 → 37:01

in a way that is maintainable and

37:01 → 37:04

accordingly to to the best practices.

37:05 → 37:08

Then you can certainly join such a

37:08 → 37:11

modernization project because this is something that you

37:11 → 37:15

would find very fulfilling for you.

37:15 → 37:20

So I think that this is my personal opinion, but

37:21 → 37:23

I will say it anyway anyway.

37:23 → 37:25

I think that with seniority,

37:25 → 37:28

if the the source of the

37:28 → 37:32

motivation moves gradually from if you are a junior,

37:32 → 37:36

then you are motivated when your code is just working.

37:36 → 37:40

But after you become a regular or

37:40 → 37:44

or senior developer, the this motivation moves gradually

37:44 → 37:47

towards not only providing a working code,

37:47 → 37:51

but also the code that is a high high quality code.

37:51 → 37:54

And that means that the code should be testable,

37:54 → 37:56

should be maintainable.

37:56 → 37:58

This code should be self explanatory.

37:59 → 38:03

It would not require any additional comments inside.

38:03 → 38:05

Just the the naming of the functions and the structure

38:05 → 38:07

would just

38:08 → 38:12

just explain what was the the meaning of the author.

38:12 → 38:13

So

38:14 → 38:18

that's why I said that it's mostly for senior developers

38:18 → 38:22

because the source of of motivation is different in

38:22 → 38:24

terms of this kind of developers.

38:25 → 38:30

And certainly, the the the software modernization is is

38:30 → 38:34

a type of project that would give you this

38:34 → 38:36

feeling of

38:38 → 38:39

of

38:41 → 38:46

let's say moving from a poorly quality code

38:46 → 38:48

Towards the better and better quality.

38:48 → 38:51

So, yeah, that's basically.

38:51 → 38:54

Also maybe to add on top of that

38:55 → 38:59

two more things that I think are also very important and

39:00 → 39:03

they work alongside with seniority

39:04 → 39:08

which Tomik mentioned is that more senior devs

39:08 → 39:13

will be most definitely more vocal about what they see

39:13 → 39:16

and what needs to be changed so if you want to keep the team

39:16 → 39:19

motivated listen to them because they know what they are

39:19 → 39:23

talking about so and me as a scrum master as a project

39:23 → 39:27

manager I need to ensure that they are being listened to

39:27 → 39:31

and the changes that they want to introduce of course after a

39:31 → 39:33

very you know after a review,

39:33 → 39:35

after deciding exactly and talking through the rest of the

39:35 → 39:37

team and the rest of the company are actually being

39:37 → 39:42

implemented and one very sometimes very tricky thing

39:42 → 39:46

that is not very obvious for many people

39:46 → 39:49

is that you know you as the owner of the product

39:50 → 39:54

must prepare yourself to sometimes manage organizational

39:54 → 39:58

change or maybe even procedures within your company because

39:58 → 40:01

I've already seen and I've already experienced

40:02 → 40:06

cases where you know some actions of the system were

40:06 → 40:11

reported as a bug, where actually that wasn't a

40:11 → 40:15

bug or undesired feature but the system was representing

40:15 → 40:19

basically a process, procedure within the company that was

40:19 → 40:22

using it, which actually

40:22 → 40:25

well was not going too strong,

40:25 → 40:29

but basically stupid and it needed to be changed.

40:29 → 40:31

So also remember that, you know,

40:31 → 40:34

you have a mature product and sometimes if it's a product

40:34 → 40:37

that is being used internally within your company,

40:38 → 40:42

the beginning of modernization of the code base of the

40:42 → 40:46

software may lead to also changes within your

40:46 → 40:50

organization itself and your processes and to be

40:50 → 40:53

perfectly honest for me I always take that as a good

40:53 → 40:57

thing right because it's always good to find a reason

40:57 → 41:01

to get better at something but it is not very

41:01 → 41:06

well most commonly it is not very obvious when

41:06 → 41:10

this thing happens so yeah probably easier said than

41:10 → 41:14

done sometimes well yeah definitely

41:15 → 41:17

There's loads of useful advice from you guys.

41:17 → 41:20

Suppose that from now on every modernization project should be

41:20 → 41:24

really a piece of cake for everybody watching this.

41:24 → 41:27

I have one more question to you.

41:27 → 41:30

So you told us a lot about motivation,

41:30 → 41:35

about the fears of developers taking part in modernization projects.

41:35 → 41:39

But what about the red flags that CIOs or CEOs or tech

41:39 → 41:43

leaders should watch out for when starting and running a

41:43 → 41:45

modernization project?

41:46 → 41:50

What can what can be suspicious and what can foreshadow

41:50 → 41:53

the the end or the backfiring of the project?

41:53 → 41:54

Tamay?

41:54 → 41:56

Well, okay.

41:57 → 41:58

Okay.

41:59 → 42:00

From my point of view,

42:00 → 42:04

the the main red flag may appear when this is something

42:04 → 42:10

that relates to to what just said in a minute ago.

42:10 → 42:14

When you meet some resistance from the client

42:14 → 42:18

side, when you detect some strange behavior in their

42:18 → 42:22

process and you want to improve it somehow

42:22 → 42:25

during the workshops that are a predevelopment

42:25 → 42:29

phase, and you suggest some changes,

42:29 → 42:30

you suggest some improvements,

42:30 → 42:34

and you expect the client to be open to this.

42:34 → 42:36

But instead, you

42:37 → 42:41

meet with a reaction like we've done it for decades

42:41 → 42:44

this way and it has to stay this way.

42:44 → 42:49

So because the process is fine and you don't we don't want to change anything.

42:49 → 42:53

So anytime we we meet this this

42:53 → 42:58

kind of reaction distance from from the

42:58 → 43:02

client side, it is it is a struggle for us because we have to

43:03 → 43:06

follow the process that we already know that is not perfect.

43:06 → 43:09

It could be better and it could be improved.

43:09 → 43:14

And this also translates to worse,

43:14 → 43:18

let's say, satisfaction from from providing this kind of

43:18 → 43:21

solution because we have in mind that we would

43:21 → 43:24

modernize this solution, not only the solution,

43:24 → 43:25

but also the processes.

43:25 → 43:29

And yet, we don't have an opportunity to to do so.

43:29 → 43:29

So

43:29 → 43:33

I'd say that this is the the probably the the main red flag

43:33 → 43:35

that can that can be raised.

43:36 → 43:36

Yeah.

43:36 → 43:38

I

43:38 → 43:43

think that the the big question here is you know how to

43:43 → 43:46

you know how to see the red flag?

43:46 → 43:49

How not to miss that something is going terribly wrong?

43:49 → 43:51

We're going downhill.

43:51 → 43:55

Well for me the biggest biggest red flag in any

43:55 → 43:59

project but also in modernization is

43:59 → 44:02

when the team is getting silent.

44:03 → 44:07

Where nobody doesn't even care to raise

44:07 → 44:10

another idea for example because they

44:10 → 44:14

know that the resistance to change is so big that most

44:14 → 44:16

probably is not gonna happen, right?

44:17 → 44:19

They are burnouts, they're tired,

44:19 → 44:25

basically they don't care anymore or start you know

44:25 → 44:31

start feeling so burnout and basically they don't see any

44:31 → 44:34

they they don't see the results in the future being worth it.

44:34 → 44:39

And the the the biggest red flag for me is when they are getting silent.

44:39 → 44:44

That that means that you need to talk to them really fast

44:44 → 44:48

and be really honest and

44:48 → 44:52

especially when you start to notice that if they give you

44:52 → 44:54

feedback, most probably they wanna give

44:54 → 44:57

you the most honest feedback

44:57 → 45:00

because they most probably have already done,

45:00 → 45:02

but it wasn't heard.

45:02 → 45:04

And, you know, no action points were there.

45:04 → 45:06

But if this happens,

45:07 → 45:10

you really need to focus on implementing even the smallest

45:10 → 45:13

changes, smallest improvements, you know,

45:13 → 45:16

one percent improvement Kaizen style basically.

45:17 → 45:18

Change the time of the meetings.

45:18 → 45:22

Change very small things to start moving forward again and

45:22 → 45:24

get motivation running.

45:25 → 45:25

Yeah.

45:25 → 45:27

Because, you know

45:27 → 45:31

I I would add that this is also a red flag when

45:31 → 45:34

it happens on the client side because Exactly.

45:34 → 45:34

Yeah.

45:34 → 45:39

If you you meet a situation in which a client's

45:40 → 45:45

clients and engagement into the project is decreasing

45:45 → 45:48

and the client doesn't want to participate anymore in the,

45:48 → 45:52

let's say, scrum ceremonies or or the reviews,

45:52 → 45:58

and the client doesn't want to give you a feedback when you demand it.

45:58 → 46:02

And the and the client doesn't accept the the changes on

46:02 → 46:06

time and you don't have any idea what actually

46:06 → 46:11

is in the in the head of the person that actually is

46:11 → 46:15

involved in the process, then this is another red flag

46:15 → 46:19

for you because you don't have you are not closing the feedback loop.

46:19 → 46:21

You are probably off the track,

46:21 → 46:25

and it may appear that after some

46:25 → 46:28

time, after a month or or two,

46:28 → 46:32

the the final vision of the product would be so different

46:32 → 46:36

than what client expects that it would cost very

46:36 → 46:39

high amount of time and and money to

46:39 → 46:42

actually be again on the track with the project.

46:42 → 46:46

So it's both being silent from the

46:46 → 46:50

team side and but also from the client side is is very bad

46:50 → 46:51

situation probably.

46:51 → 46:52

Yeah.

46:52 → 46:56

Okay. Alright. Thank you very much, guys.

46:56 → 46:58

I think I'm done with my questions,

46:58 → 47:03

but now it's the time to answer questions from our audience.

47:03 → 47:06

So let's start with Jan's question.

47:07 → 47:12

Jan asks if you could share some of your

47:12 → 47:14

experience in modernisation projects.

47:14 → 47:17

So what difficulties did you have to face in the last

47:17 → 47:20

projects and how did you handle them?

47:20 → 47:25

So maybe you could share one example from each of you.

47:25 → 47:29

I don't know if I can, you know, MBAs and stuff.

47:30 → 47:34

So it's not gonna be a very direct answer, Daniel.

47:34 → 47:36

Sorry.

47:36 → 47:39

But, basically, yeah, for the last two or three years,

47:39 → 47:44

I'm I'm mainly focused on on the modernization projects.

47:44 → 47:46

And to be perfectly honest with you,

47:46 → 47:49

the things that we've been talking about previously are

47:49 → 47:54

the biggest problems that that I had to face with with my teams lately.

47:54 → 47:56

And I guess the most recent one was

47:56 → 48:00

an issue of taking over a project without well,

48:00 → 48:05

basically with little to none handover from the previous team.

48:05 → 48:07

The product is quite big, very complex.

48:08 → 48:11

And you know, for some reasons completely

48:11 → 48:15

to which we had absolutely no no influence on.

48:15 → 48:19

We had just like one or two one hour meetings with the previous

48:19 → 48:21

team that we've been taking over from.

48:23 → 48:25

How did we handle it?

48:25 → 48:29

Communication, communication, location, location, right?

48:30 → 48:34

Basically we were very very vocal, very transparent,

48:34 → 48:38

sometimes very brave with contacts with the client

48:38 → 48:41

basically we were stating very clearly what the issues

48:41 → 48:44

were, what we need to do, basically,

48:44 → 48:47

on a daily on a daily basis, to be honest.

48:49 → 48:52

Hence, what might also seem strange,

48:52 → 48:56

we agreed to the client that for the first couple of of

48:56 → 49:00

sprints, well, not couple, four or six sprints,

49:00 → 49:05

we will not be planning in very high detail

49:05 → 49:09

because we basically have absolutely no idea what can happen.

49:09 → 49:13

Right? So we went very, very agile.

49:13 → 49:16

The sprints were overbooked, but, you know,

49:16 → 49:17

the results and the outcomes,

49:17 → 49:21

the the the increment that we did provide,

49:23 → 49:26

although small compared to greenfield projects, but,

49:26 → 49:30

you know, fixing one issue

49:30 → 49:35

which leads to an increase in sales or

49:35 → 49:38

delivery for, ten or fifteen percent.

49:38 → 49:40

That's a huge improvement.

49:40 → 49:41

So now

49:41 → 49:44

we're getting a little bit more stable.

49:45 → 49:48

So it's getting a little bit normal and and and on track

49:48 → 49:50

right now, but I guess that that's what happened.

49:50 → 49:54

We're we were courageous, transparent.

49:54 → 49:56

The client luckily was open minded.

49:56 → 50:01

He did understand what the state of the product is,

50:02 → 50:04

And he was aware of what's gonna happen,

50:04 → 50:08

and we were aware as well what our task at hand is.

50:08 → 50:10

So

50:10 → 50:11

yeah.

50:12 → 50:14

Tamayo, your story?

50:17 → 50:21

I think of two, but I would select one.

50:21 → 50:25

I think that there was a project I know that there was a

50:25 → 50:28

project that I participated in,

50:28 → 50:31

and the problem in this project was related

50:31 → 50:36

to the decision makers had already

50:36 → 50:39

made a decision that they want to modernize the software,

50:39 → 50:42

and they want they had some deadline that they wanted to

50:42 → 50:46

fit into of delivering the the, let's say,

50:46 → 50:49

new modern modernized version.

50:49 → 50:52

And they wanted to start the development as quickly as possible.

50:52 → 50:56

But from our experience we knew that we have to

50:56 → 50:59

firstly discover what is there to be done,

50:59 → 51:03

and we had to propose a discovery session

51:03 → 51:06

in in the form of workshops with the clients.

51:06 → 51:09

So to gather the knowledge about the business knowledge

51:09 → 51:11

and

51:12 → 51:18

this is something that the client was very let's say,

51:18 → 51:21

they they wanted to make it as short as possible because they

51:21 → 51:25

wanted to start the development phase as quickly as possible.

51:25 → 51:28

And we knew that there is a lot of

51:28 → 51:29

to be discovered.

51:29 → 51:30

So

51:32 → 51:35

we had to find a compromise and come up with a solution

51:35 → 51:39

to somehow start the development

51:39 → 51:44

process and paralyze it with the with the

51:44 → 51:45

ongoing workshops.

51:45 → 51:48

So we started workshops first.

51:48 → 51:50

And after a week of workshops,

51:50 → 51:53

we also started development on the things that was already set

51:53 → 51:55

in stone during the workshops.

51:55 → 51:59

But in parallel, there was also workshops ongoing

51:59 → 52:02

and we were discovering new things and providing the work

52:02 → 52:03

for the developers.

52:03 → 52:08

So it was somehow two phases overlapping

52:08 → 52:13

and this was the solution to to the client's demands.

52:14 → 52:17

Yeah. So it was a challenge for us.

52:17 → 52:21

So a lot of multitasking at the same time?

52:21 → 52:23

Yeah. Multitasking and communication.

52:23 → 52:26

Again, this is something that Wojtek mentioned.

52:26 → 52:28

Okay.

52:30 → 52:34

So we're still waiting for for some more comments because we

52:34 → 52:35

have a couple of minutes left.

52:36 → 52:41

But in the meantime, maybe I have one more question that's

52:41 → 52:43

just popped into my mind.

52:44 → 52:48

If you could give a CIO wanting to run a

52:48 → 52:52

modernisation only one piece of advice that

52:52 → 52:54

they could remember, what would that be?

52:54 → 52:55

Would that be, you know,

52:55 → 52:59

this most important tip for them?

52:59 → 53:00

Only one?

53:00 → 53:01

Yeah.

53:01 → 53:03

I know it's difficult,

53:03 → 53:06

but maybe you have something that you know strikes you when

53:06 → 53:09

it comes to successful modernization projects.

53:11 → 53:14

I would have to say be patient basically.

53:14 → 53:16

Patient is here, right?

53:17 → 53:20

You you need to be patient and you need to listen to people

53:20 → 53:23

around you because then, you know,

53:23 → 53:25

you have hired them for a reason.

53:26 → 53:29

They know most probably what they are doing.

53:29 → 53:31

If you think that they don't know

53:31 → 53:34

what you're doing, then be patient and explain that to them.

53:34 → 53:36

Right? Be patient listening to them.

53:36 → 53:40

Be patient explaining what you actually want.

53:41 → 53:44

Yeah. That would be the one.

53:45 → 53:47

Okay. Thank you.

53:48 → 53:52

And so much, do you have that one final tip?

53:52 → 53:56

I think I would say that coming up with a list of your

53:56 → 53:59

priorities would be something very helpful.

53:59 → 54:04

You should prioritize your goals and think of the

54:04 → 54:07

things that you want to do in the first way in the first place.

54:07 → 54:10

What are your biggest pain points currently?

54:10 → 54:14

What is the thing that is really

54:14 → 54:18

hurting your business currently and

54:18 → 54:22

try to address these issues in the first place and

54:22 → 54:25

do not perform the modernization just for the sake

54:25 → 54:27

of modernization.

54:27 → 54:31

You you should think of the the main goals that are

54:31 → 54:36

there and always keep in mind to

54:36 → 54:40

to go for them and not be distracted by some new

54:40 → 54:43

technologies emerging or or something like this or

54:43 → 54:46

something someone telling you that they work their solution

54:46 → 54:49

on, for example, cloud based solution and you are

54:49 → 54:53

hosting your your solution on on premise services,

54:53 → 54:57

and this is the cause of your of your pain and just

54:58 → 54:59

follow your goals and

54:59 → 55:01

That's it probably.

55:01 → 55:05

So hype driven development is definitely not the thing to do.

55:06 → 55:07

No.

55:07 → 55:09

If you want hype driven development,

55:09 → 55:15

sell your products and start a new one and keep on the hype basically.

55:15 → 55:18

Create a second, third, fourth startup.

55:18 → 55:19

Okay,

55:20 → 55:21

I see.

55:21 → 55:26

Alright, so thank you guys very much for a

55:26 → 55:29

very interesting discussion.

55:29 → 55:33

I definitely learned a lot and I bet that our audience

55:33 → 55:36

also learned a lot from you.

55:36 → 55:37

If

55:38 → 55:40

you come up with any questions,

55:40 → 55:43

you can leave them in the comments under this video.

55:43 → 55:46

So we'll try to answer them after

55:47 → 55:48

our stream.

55:48 → 55:50

And as I said at the beginning,

55:50 → 55:53

we'll share the recording with you so you can access it

55:53 → 55:55

anytime you want.

55:55 → 55:59

Thanks again and see you next time.

55:59 → 56:02

Thank you. Thank you for having me. Bye.

56:02 → 56:03

Bye.