Live Software Modernization Time Market

00:43 → 00:46

Hello and welcome to Meric Studio's live session,

00:46 → 00:48

Software Modernization Time to Market.

00:48 → 00:49

I'm Alexandra,

00:49 → 00:52

senior content marketing specialist at Meric Studio,

00:52 → 00:54

and I will be your host today.

00:54 → 00:57

Joining me are two very special and very knowledgeable

00:57 → 01:01

guests, Andrey Puska, our software architect,

01:01 → 01:03

and Matty Szeretski, our project manager.

01:03 → 01:05

Hi, guys. How are you?

01:05 → 01:08

Hello. I'm fine. Doing good.

01:09 → 01:11

Okay, I'm really excited to have you here today.

01:11 → 01:14

So as the title of the session suggests today,

01:14 → 01:18

we'll be talking about optimizing the process of

01:18 → 01:19

releasing new features.

01:19 → 01:20

In more detail,

01:20 → 01:23

we are going to cover things like the importance of

01:23 → 01:27

optimizing time to market for mature organizations,

01:27 → 01:30

symptoms indicating that you are going either too fast or

01:30 → 01:32

too slow with releases,

01:32 → 01:34

as well as the ways in which you can improve time to market

01:34 → 01:36

for healthy business growth.

01:36 → 01:40

And before I ask my guests to introduce themselves,

01:40 → 01:43

let me do a short housekeeping.

01:43 → 01:46

So today's session is going to last about an hour,

01:46 → 01:48

and it will be divided into two parts.

01:48 → 01:53

First, we will have the expert discussion and then the Q and A session.

01:53 → 01:56

If you come up with any questions whatsoever,

01:56 → 01:59

please leave them in the chat box and we will address them

01:59 → 02:00

after the discussion.

02:00 → 02:03

It's a live stream, but it's being recorded,

02:03 → 02:06

so you will be able to rewatch it later on.

02:07 → 02:10

Okay, I think it's time for our

02:10 → 02:14

guests to tell us a few words about who they are and what they do,

02:14 → 02:18

as well as about their experience with software modernisation.

02:18 → 02:22

Andrew, could you begin and tell us a few words about yourself?

02:22 → 02:24

Hi. My name is Andrew.

02:24 → 02:27

I'm a software architect at American Studio.

02:28 → 02:32

I started working with American Studio around two years ago,

02:32 → 02:33

firstly as a DevOps.

02:33 → 02:37

Then last year I switched to software architecture.

02:37 → 02:40

Before that I worked in a subscription and pay per view

02:40 → 02:43

business as a backend and tech lead.

02:43 → 02:47

And overall, I'm a fan of cloud solutions and I kind of

02:47 → 02:50

try to push people past their code.

02:51 → 02:55

Okay. Thank you very much. Mate, how about you?

02:55 → 02:55

Hey.

02:55 → 03:00

I'm project manager and scrum master at Marik Studio.

03:00 → 03:04

I have nine years of experience in software

03:04 → 03:08

development, including such industries like medical

03:08 → 03:13

and pharmacy, video gaming, gambling, and sports betting.

03:13 → 03:15

Okay. Thank you very much for the intros.

03:15 → 03:20

I'm really excited to have you both here and to have two quite different,

03:20 → 03:24

but I believe complementary perspectives that you will bring today.

03:24 → 03:27

Okay. Shall we begin? Are you ready?

03:27 → 03:29

I hope so.

03:29 → 03:31

Okay. So let's roll.

03:31 → 03:35

I'd like us to start with something that I believe all of

03:35 → 03:37

us want to achieve with success.

03:38 → 03:41

So in software, success depends on many factors,

03:41 → 03:45

on the level of innovation that the digital product brings to

03:45 → 03:47

the market, on the product market fit,

03:47 → 03:49

on cost of development.

03:49 → 03:52

And I believe I could go on forever, literally.

03:53 → 03:56

So my question for the beginning of this session to

03:56 → 04:01

you is: what is the role of time to market in software success?

04:01 → 04:03

How would you describe it?

04:06 → 04:08

Time to market is

04:09 → 04:13

the length in time where we are

04:13 → 04:17

able to deliver some incremental new features,

04:17 → 04:21

new products to our end users.

04:21 → 04:24

And it's very important because

04:24 → 04:26

in software development,

04:27 → 04:31

our goals are to bring some new value to to

04:31 → 04:33

our users.

04:34 → 04:34

Yeah.

04:34 → 04:37

Not only not only just value for users,

04:37 → 04:40

but it also means that if we if we bring this value to users,

04:40 → 04:44

we we directly connect to a bigger revenue for the company.

04:44 → 04:48

So having a short time to market as possible is crucial

04:48 → 04:50

for companies.

04:50 → 04:51

Yeah.

04:52 → 04:56

Definitely, Angie, you are a bit more direct

04:56 → 04:58

regarding the reasons.

04:58 → 05:02

I tried to be a bit more idle

05:04 → 05:05

dreaming person.

05:05 → 05:06

Let's call it this way.

05:07 → 05:09

Okay.

05:09 → 05:13

And I'm wondering, would you say that time to market is more

05:13 → 05:16

important in some industry than others?

05:16 → 05:20

So suppose you want to start your business or you're already

05:20 → 05:24

operating in a certain industry, on a certain market,

05:24 → 05:29

when should you make time to market your top priority?

05:30 → 05:34

I believe that time to market is

05:34 → 05:38

very, very important for the new markets,

05:38 → 05:40

new industries.

05:41 → 05:45

Also, if we are operating regarding

05:45 → 05:49

the seasons, some events where we are where we

05:49 → 05:51

have quite

05:51 → 05:55

strict deadline to to

05:56 → 06:01

introduce new products and or a new a new feature.

06:04 → 06:07

Andrew, do you have anything to add regarding the industries in

06:07 → 06:10

which time to market is especially important?

06:10 → 06:11

Yeah. Exactly.

06:11 → 06:14

On the on the especially on, like, on seasonal

06:15 → 06:19

or brands, when we are talking about tourism,

06:19 → 06:24

for example, or sports events that only happen,

06:24 → 06:26

for example, during the summer

06:27 → 06:30

or when we have touring for winter for skiing or something

06:30 → 06:34

like that, then we cannot really move the deadline.

06:34 → 06:38

Cannot control the weather or month that we are in.

06:38 → 06:39

So it's crucial

06:41 → 06:44

to produce value for our customers before that happens

06:44 → 06:48

or to be kind of on the market when the time comes.

06:49 → 06:50

Okay.

06:50 → 06:53

So the industries in which you just cannot exceed the deadline

06:53 → 06:55

no matter what happens.

06:55 → 06:56

Okay. I see.

06:57 → 06:58

And Yeah. Come on?

06:58 → 07:03

It's hard to imagine a situation that we are

07:03 → 07:06

preparing a new application for upcoming

07:06 → 07:08

football season, for example.

07:08 → 07:14

And we are calling to the league management.

07:14 → 07:14

Hey, guys.

07:14 → 07:19

Could you postpone your your league start for a week?

07:19 → 07:22

Because we are almost ready.

07:22 → 07:24

Yeah. Like Super Bowl. Sorry.

07:24 → 07:26

Let's postpone it until the next month.

07:26 → 07:30

Yeah. Our ad is almost almost perfect.

07:30 → 07:32

Okay. I see.

07:32 → 07:35

And how about the phases of product development?

07:36 → 07:39

Because so far I have the feeling that we've been mixing it.

07:39 → 07:40

And I'm wondering,

07:41 → 07:45

is time to market perhaps more important for younger businesses,

07:45 → 07:50

maybe for scale ups or maybe for mature organisations and enterprises?

07:51 → 07:54

Is there any simple way to address this question?

07:54 → 07:56

What do you think?

07:58 → 08:00

It really depends.

08:00 → 08:03

For startups, it's obviously

08:03 → 08:06

very important because it determines if the company will

08:06 → 08:07

even have success.

08:07 → 08:11

If you miss your time to market or if

08:11 → 08:14

you deliver something that is already not unique because

08:14 → 08:17

somebody else beat you up to it,

08:17 → 08:21

then it might be as simple as just closing the business.

08:21 → 08:24

On the other hand, you have big companies,

08:24 → 08:28

big enterprises that they have obviously more resources,

08:28 → 08:31

but it it also can can result, you know,

08:31 → 08:33

if you if you miss your time.

08:33 → 08:36

It's gonna result in in in big loss revenue, for example,

08:36 → 08:40

or shutting down departments and and people

08:40 → 08:41

losing their jobs.

08:41 → 08:44

So so both both situations are pretty

08:44 → 08:45

important when it comes to time to market.

08:45 → 08:47

It really depends.

08:48 → 08:52

Yeah. I would like to focus on enterprises.

08:53 → 08:56

So even if we are leader,

08:57 → 09:01

the main competitor on the market, and

09:02 → 09:06

since some moment, we are always second

09:06 → 09:11

thought with new features, then we definitely

09:11 → 09:14

won't be at the top after a while.

09:14 → 09:18

Because it's very important to to give

09:18 → 09:22

some innovation to to the market, to to the audience.

09:23 → 09:27

So keep this competitive advantage even if you are a

09:27 → 09:31

mature organization or especially if you are a mature organization.

09:31 → 09:31

Okay.

09:31 → 09:34

We need to try to stabilize

09:36 → 09:39

to to to keep this this position of the leader

09:39 → 09:43

of the market and being

09:44 → 09:47

fast with with new products,

09:47 → 09:50

new features is one of those ways.

09:50 → 09:51

Okay.

09:51 → 09:54

I'm glad that you actually mentioned enterprises because

09:54 → 09:57

that's what I'd like to focus on from now on.

09:57 → 10:01

Because after all, the main topic is software modernization.

10:01 → 10:03

And Andrew, you actually said it depends.

10:03 → 10:06

And that's one of my favorite phrases in IT.

10:06 → 10:10

And now I'd like to ask you a question to which I suppose the

10:10 → 10:12

answer will be it depends.

10:13 → 10:17

But my question is, is there any optimal value of time to

10:17 → 10:22

market that you should strive for as a mature organization?

10:23 → 10:24

Is there any value like that?

10:24 → 10:28

Or maybe you should rely on a gut feeling to say what

10:28 → 10:31

the optimal time to market is?

10:31 → 10:33

Yeah, I mean, of course, it depends. Right?

10:33 → 10:36

But to to give maybe an example,

10:37 → 10:40

there might be a situation when when the the feature that that

10:40 → 10:44

your your team is developing is considered unique on the market.

10:44 → 10:48

And then having this delivered still as a

10:48 → 10:52

unique functionality is crucial because it keeps your

10:52 → 10:55

customers interested your company, for example,

10:55 → 11:00

or it can expand your customer amount or number.

11:00 → 11:02

If you miss this mark,

11:02 → 11:06

if there is a competitor of yours that will deliver this

11:06 → 11:08

functionality sooner,

11:09 → 11:10

you're kind of out of luck,

11:10 → 11:13

then you need to figure out something else and waste

11:13 → 11:15

resources on something else as well.

11:15 → 11:19

Not necessarily as well, but kind of commit to to new features.

11:20 → 11:20

Yes.

11:20 → 11:25

But from another hand, we cannot go too

11:25 → 11:29

fast to the market because if if our product

11:29 → 11:33

is not polished enough, if it's not

11:33 → 11:37

ready, we have still some gaps in

11:37 → 11:40

functionalities and so on.

11:40 → 11:42

We will also lose.

11:42 → 11:46

Well, it's not so important that we were first,

11:46 → 11:49

but we we made a bad first impression.

11:49 → 11:53

That's also not a good approach.

11:53 → 11:56

And it's a specific specifically true for

11:56 → 11:58

enterprises because for startups,

11:59 → 12:02

you know, you you don't have yet this this point of view of people

12:02 → 12:06

seeing you as as a quality enterprise, for example.

12:06 → 12:08

If if you're a big company,

12:08 → 12:10

there are already some expectations towards you.

12:10 → 12:14

So so it cannot be that you are developing just some

12:14 → 12:18

kind of proof of concept on a real stable market.

12:18 → 12:21

Yes, totally agree.

12:21 → 12:25

Okay, so striving for balance would be the

12:25 → 12:26

answer to this question.

12:26 → 12:27

Okay.

12:28 → 12:31

But unfortunately, that's not always the case, right?

12:31 → 12:35

Because we wouldn't be here today if everybody

12:35 → 12:40

were able to find this golden mean the optimal time to market.

12:40 → 12:43

So speaking from your own experience,

12:44 → 12:46

what's the problem that, you know,

12:46 → 12:48

enterprise clients face more often?

12:48 → 12:51

Going too fast or too slow with releases?

12:51 → 12:56

I would say definitely it will be too too too slow.

12:57 → 13:01

Usually, we we have to deal with many stakeholders,

13:01 → 13:05

many involved people departments,

13:05 → 13:07

many voices, many expectations.

13:07 → 13:11

So so that I would say even conception

13:11 → 13:13

process takes

13:14 → 13:18

a lot longer than in in some smaller

13:18 → 13:20

companies like start ups and so on.

13:20 → 13:25

We we have to get approval from many, many people.

13:25 → 13:28

It takes time.

13:30 → 13:32

So I'm wondering,

13:33 → 13:37

are you able to actually point out to some symptoms that

13:37 → 13:40

show that you are going too slow and that your time to

13:40 → 13:43

market is too slow when you're a mature organisation?

13:43 → 13:46

You already said that there are too many stakeholders.

13:46 → 13:51

What other symptoms would you name to help our audience

13:52 → 13:56

realize that actually something is wrong with their time to market.

13:58 → 14:00

Andre, do you have any hints?

14:00 → 14:04

I mean, one of the examples is in enterprises,

14:05 → 14:08

it's usually very common to have

14:08 → 14:12

kind of bad feedback loop or even an existing feedback loop

14:12 → 14:14

to direct customers.

14:14 → 14:18

And that means when we combine this with multiple stakeholders,

14:19 → 14:22

the idea phase of the of the project may take a long of

14:22 → 14:24

time a lot of time.

14:24 → 14:28

And we're not even sure if if this

14:28 → 14:32

is kind of the feature that we that that

14:32 → 14:34

will be used by by our customers,

14:34 → 14:36

and they will be satisfied by it.

14:36 → 14:40

And all of that brings like,

14:40 → 14:43

the longer it goes, the more questions people have,

14:43 → 14:44

even inside the team.

14:44 → 14:48

So so also kind of one of the symptom is that that people can

14:48 → 14:51

get kind of fed up inside the team and look for maybe other

14:51 → 14:53

alternatives because the project is going, for example,

14:53 → 14:57

for a year or two without any feedback if this is even going

14:57 → 14:58

in the right direction.

14:59 → 15:01

So they cannot really see any progress.

15:01 → 15:04

And I suppose that can be really discouraging to people

15:04 → 15:06

on the project team.

15:06 → 15:07

Yeah. That's correct.

15:07 → 15:11

Most of the people in IT wants

15:11 → 15:13

to see their

15:15 → 15:16

outcomes of their work.

15:16 → 15:20

And if we are working, as Andre mentioned,

15:20 → 15:24

on some feature for for a whole year and we cannot

15:25 → 15:28

see it working on a production,

15:28 → 15:33

cannot get some feedback from from users,

15:33 → 15:35

it might be very frustrating.

15:36 → 15:39

So there is no tangible progress.

15:39 → 15:42

Nothing to be proud of, actually.

15:42 → 15:43

That's correct.

15:43 → 15:45

Okay. So we have the symptoms.

15:46 → 15:47

How about the reasons?

15:47 → 15:51

Because something must trigger this kind of situation.

15:52 → 15:56

I suppose that you could group these according to

15:56 → 15:59

what part of the organisation they are tied to.

15:59 → 16:04

So maybe let's start with the processes and organisational aspects.

16:04 → 16:09

Matti, I'm sure that you have plenty to say about this issue.

16:09 → 16:11

When we think about enterprises,

16:11 → 16:14

we often think about the

16:15 → 16:18

structure that works in waterfall.

16:18 → 16:20

So first we we need to design

16:21 → 16:24

our our feature, our product.

16:24 → 16:27

Then we have to focus on development.

16:28 → 16:30

Then it's testing phase.

16:30 → 16:33

And after after we accomplish all our

16:33 → 16:37

checkpoints on the list, then we can release.

16:37 → 16:41

It all all it's it often takes much time.

16:41 → 16:45

Also, sometimes it's even before the design,

16:45 → 16:47

a lot of r and d work and so on.

16:47 → 16:50

So so even when I'm speaking,

16:50 → 16:54

we can imagine how long it it might take.

16:54 → 16:55

Okay.

16:57 → 17:02

And how about the vision that lies within this enterprise company?

17:02 → 17:06

Can it also be the reason for the prolonged time to market?

17:06 → 17:08

Maybe lack of coherent vision?

17:09 → 17:10

Yeah, for sure.

17:10 → 17:14

And it affects not only just the length of the project,

17:14 → 17:16

but the team as well.

17:17 → 17:20

Thing that we talked just before about team members being

17:20 → 17:22

kind of frustrated

17:22 → 17:25

if on the top level or kind of on the higher

17:25 → 17:26

level of organization,

17:26 → 17:29

there is no unified vision of the of the feature or the

17:29 → 17:33

project, then then also on the lower lower level,

17:33 → 17:36

there are questions and doubts of of how it's gonna work.

17:36 → 17:43

And and all of it just delays the time to market and delivery of the product.

17:43 → 17:47

And speaking of the team,

17:47 → 17:51

I'm wondering how about the development practices?

17:51 → 17:53

Do they also influence time to market?

17:53 → 17:56

And can they also be the reason for the delays?

17:56 → 17:58

Yes, of course.

17:59 → 18:03

There is this big thing called legacy code.

18:03 → 18:07

When we talk about enterprises, we cannot miss legacy code.

18:07 → 18:10

There's always a company that has some kind of software

18:10 → 18:12

already in place.

18:13 → 18:17

When we or the companies, when they develop new features,

18:17 → 18:21

it often comes with some technological depth that they

18:21 → 18:25

need to overcome in order to release new features.

18:25 → 18:26

Now you can you can talk about, you know,

18:26 → 18:30

some hidden dependencies or or some areas that were neglected

18:30 → 18:34

when it comes to tests or or just pure functionalities that

18:34 → 18:35

were just overlooked.

18:36 → 18:38

Okay.

18:38 → 18:42

We have when when we have a a

18:42 → 18:45

huge

18:45 → 18:50

batch of legacy code, then we can

18:51 → 18:54

often experience some some delays dependencies

18:54 → 18:58

because every every even tiny feature needs to

18:58 → 19:01

be checked with old code.

19:01 → 19:05

Sometimes we discover some some unexpected bags

19:05 → 19:09

and no one knows how to deal with them

19:09 → 19:13

because people who are responsible for for this old

19:13 → 19:15

code are no longer in the company.

19:15 → 19:16

So

19:17 → 19:21

and often this this code is outdated, maybe

19:22 → 19:24

bad quality.

19:24 → 19:26

So so it's it's very,

19:26 → 19:30

very problematic situation for for the company to deal with

19:30 → 19:32

the legacy code.

19:32 → 19:37

So it's kind of like very unpleasant process of excavation.

19:37 → 19:38

Yes.

19:38 → 19:38

Okay.

19:38 → 19:41

And I know that when we are talking about software modernization,

19:41 → 19:45

there are always NDAs and you cannot really mention

19:45 → 19:48

particular projects for obvious reasons.

19:48 → 19:52

But I'm wondering if you can share any of your own

19:52 → 19:58

experience regarding work with legacy code and how it affects time to market.

19:59 → 20:03

Yeah. I have an example from my previous company.

20:03 → 20:04

One

20:04 → 20:06

of my previous companies.

20:06 → 20:10

We had to deal with a lot of front end

20:10 → 20:14

legacy code So so every every new element

20:14 → 20:20

on on the product for the product took a

20:20 → 20:21

lot of time.

20:21 → 20:26

So finally, the company, the c level structure

20:26 → 20:29

decided we have to deal with legacy code.

20:29 → 20:33

We spent a a couple of long springs

20:33 → 20:36

to to rid of

20:36 → 20:41

the old code, replace it with a new shiny one.

20:41 → 20:42

And

20:43 → 20:46

the this was the the reason why we could

20:46 → 20:51

reduce time spent on the court tests.

20:51 → 20:55

So so there there was very, very

20:57 → 21:01

good good pros we experienced

21:01 → 21:05

after we dealt with legacy code.

21:05 → 21:09

So it's actually the proof that that it works. Right?

21:09 → 21:10

Definitely.

21:10 → 21:14

Okay. And you mentioned testing.

21:14 → 21:19

Are there any maybe testing practices that also

21:19 → 21:21

impact time to market in a negative way and make it

21:21 → 21:23

unbearably lengthy?

21:24 → 21:25

Yeah. Of course.

21:25 → 21:28

When when you talk about enterprises,

21:29 → 21:32

there there are still companies in in the world that's that's

21:32 → 21:34

follow so called release trains,

21:34 → 21:38

where you have multiple teams that they gather each half a

21:38 → 21:42

year, for example, and they they release their features.

21:42 → 21:46

And and it comes with a lot of stress, a lot of risks,

21:46 → 21:48

a lot of regression tests, and and overall,

21:48 → 21:51

the whole company is kind of put on hold

21:51 → 21:55

for for a couple of weeks almost to in order to to

21:55 → 21:58

release features that

21:58 → 22:02

could could probably be released on on a daily basis if

22:02 → 22:04

it if it was done in a different way.

22:06 → 22:09

Hence, people just lean towards agile.

22:09 → 22:10

Yeah.

22:10 → 22:14

When we imagine situation that we

22:14 → 22:17

release new features twice a year.

22:17 → 22:22

So so we have code that was written

22:22 → 22:24

six months ago.

22:24 → 22:27

Now we noticed that some dependencies,

22:27 → 22:33

some some problems with the the whole release package.

22:33 → 22:37

And we have to go back to this six months

22:37 → 22:40

old code.

22:40 → 22:44

It's it's also very uncomfortable situation

22:44 → 22:49

because no one's really remember what and how

22:49 → 22:52

was written six months ago.

22:52 → 22:56

And you cannot really foresee all the dependencies and kind

22:56 → 23:01

of connections between those systems before they actually work together.

23:01 → 23:03

And if you develop it in small batches,

23:03 → 23:07

it's easier to figure this out than, you know,

23:07 → 23:10

doing that every half a year and having to deal with

23:10 → 23:14

some cases that you wouldn't even think about

23:15 → 23:16

at the time of development.

23:16 → 23:17

Yeah.

23:17 → 23:22

It's easier to review a few hundreds of

23:22 → 23:26

line of code than thousand of thousands line of

23:26 → 23:29

line of lines of code, sorry,

23:29 → 23:33

to to find what's what doesn't work.

23:33 → 23:34

Yeah.

23:34 → 23:37

And I suppose it must be very stressful for for the developers.

23:37 → 23:37

Right?

23:37 → 23:39

The pressure is here,

23:39 → 23:41

especially because you are dealing with a mature product

23:41 → 23:44

and a mature organization.

23:44 → 23:48

You have the reputation to sustain, right?

23:48 → 23:51

And when there is, you know, this big release coming,

23:51 → 23:53

the pressure really gets real.

23:55 → 23:57

Yes. Okay.

23:57 → 24:02

Okay, so I believe that we have quite an accurate diagnosis.

24:03 → 24:05

And now to follow this analogy,

24:05 → 24:08

I would like us to try to administer some kind of

24:08 → 24:12

treatment to our modernisation patient and talk

24:12 → 24:15

about how we can actually improve time to market to make

24:15 → 24:19

it faster and to match it with our desired outcomes.

24:20 → 24:23

So two months ago, we had another software

24:23 → 24:25

modernisation session.

24:25 → 24:28

It was devoted to legacy design,

24:28 → 24:31

and we talked a lot about user centricity.

24:31 → 24:33

And I'm sure that all those who watched us will agree

24:33 → 24:36

that being user centric is quite

24:36 → 24:39

important for the success of

24:39 → 24:41

modernisation efforts.

24:41 → 24:43

And I'm wondering,

24:43 → 24:48

what role would you say user centricity plays in improving time to market?

24:48 → 24:52

Can being customer centric or even customer obsessed

24:52 → 24:56

actually improve time to market and shorten it?

24:56 → 24:58

From your own experience, what do you guys think?

24:58 → 24:59

Yes.

24:59 → 25:04

It may help us, but it can be also a trap.

25:04 → 25:09

Being user centric is good because the product is

25:09 → 25:12

prepared is developed for for users.

25:12 → 25:15

We do not develop it for the board,

25:15 → 25:18

for someone from administration.

25:18 → 25:22

Of course, besides situation that

25:22 → 25:25

they are end users, but we do

25:26 → 25:30

the whole work for people who are actively using

25:30 → 25:31

our product.

25:31 → 25:35

But the trap might be if we are following all

25:35 → 25:39

the cop every comment, every every suggestion,

25:39 → 25:43

and we can lose our vision and the whole

25:43 → 25:47

strategy of the product of of company

25:47 → 25:49

goals and so on.

25:50 → 25:52

Yeah. And feedback loop is important. Right?

25:52 → 25:56

And and and kind of we we can as a as a company,

25:56 → 25:59

we can identify some beta users, for example, or or,

25:59 → 26:02

like, some some testing group that can help us

26:03 → 26:06

realize if the feature is is going in the right direction

26:06 → 26:09

and and if it satisfies the the selected group.

26:10 → 26:11

But as as much I said,

26:11 → 26:14

it's it's it can also be a trap because we we need to

26:14 → 26:18

remember that that everybody is different and and not all

26:18 → 26:20

everyone might have

26:20 → 26:23

first division that the company follows.

26:23 → 26:27

And also, there might be people that think about some functionality

26:27 → 26:31

that might be useful for them, but it's, I don't know,

26:31 → 26:35

maybe like a one percent or half percent of of a target audience.

26:36 → 26:40

And and then you need to really kind of weight pros and cons if

26:40 → 26:43

you should even go with this feature or not.

26:44 → 26:46

Okay.

26:46 → 26:49

So how not to fall into this trap of, you know,

26:49 → 26:52

focusing too much on everybody's wishes?

26:52 → 26:58

How should you select the the users to test?

26:58 → 27:02

Or maybe what procedures should you follow so as to, you know,

27:02 → 27:04

keep this balance in place?

27:05 → 27:10

So the first thing I would say is to to find some

27:11 → 27:14

the most loyal or maybe most active group of

27:14 → 27:18

users who are very well familiar with with our

27:18 → 27:22

application, who might admite situation

27:22 → 27:27

that we are release directly for them some

27:27 → 27:31

better version and they can test it before everyone else

27:31 → 27:36

that they might be also our ambassadors than

27:36 → 27:39

after being better tested.

27:39 → 27:43

So this is the way how to how to find this group.

27:43 → 27:44

And

27:48 → 27:51

how to not to fall into the trap.

27:51 → 27:54

We need to always wait.

27:54 → 27:57

How many come similar comments,

27:57 → 28:01

similar requests we get, how it will fit into

28:01 → 28:07

our strategy if our in our road map and

28:08 → 28:09

far goals.

28:11 → 28:12

Okay.

28:12 → 28:16

So thinking all about this pros and cons and

28:16 → 28:17

trying to find the goal that you mean.

28:17 → 28:19

Okay. I see.

28:19 → 28:22

And end users are very important,

28:23 → 28:25

sometimes even the most important, as you said.

28:25 → 28:28

But there is also one more group of stakeholders that you

28:28 → 28:32

cannot really neglect, and these are internal stakeholders.

28:32 → 28:36

So managers, C levels, the board members.

28:36 → 28:40

These are the people who should support

28:40 → 28:42

our actions, because without them,

28:42 → 28:47

our modernisation efforts simply will not succeed.

28:47 → 28:52

So from your own experience and to your best knowledge,

28:52 → 28:55

how should you structure this relationship between the

28:55 → 28:58

product team and the internal stakeholders?

28:58 → 29:02

What can you do as the enterprise client

29:05 → 29:09

to help actually structure this relationship that it

29:09 → 29:12

fosters shorter time to market.

29:13 → 29:17

One of the things is that we are talking about the vision, right?

29:17 → 29:21

How important it is that the vision is unified across the stakeholders.

29:21 → 29:25

And and here's where the the kind of role of a good PO

29:25 → 29:30

is such a crucial part of of the project development,

29:30 → 29:33

Because this good PO or the good product

29:33 → 29:37

owner can first talk to all the

29:37 → 29:40

stakeholders, can can unify the vision across them,

29:40 → 29:44

and then can forward this vision or kind of present this

29:44 → 29:45

vision to the team as well.

29:45 → 29:48

And and kind of instead of going back and forth between

29:48 → 29:53

those two sides, he can decide on his own or he and she.

29:54 → 29:55

Yes.

29:55 → 29:59

Product owner has to have this

30:00 → 30:02

decision power.

30:03 → 30:06

It it cannot happen situation when product

30:06 → 30:09

owners decide to allocate some

30:09 → 30:12

resources into one direction.

30:12 → 30:13

And after

30:13 → 30:18

a while, someone from c level, for example,

30:18 → 30:21

comes and say, oh, no.

30:21 → 30:23

No. We we definitely have to change it.

30:23 → 30:26

This is wasting time, wasting

30:27 → 30:30

our opportunities.

30:31 → 30:33

So so definitely

30:33 → 30:38

we need to have someone who is trustable across the

30:38 → 30:41

company, who who knows the product well,

30:41 → 30:45

who who is able to cooperate

30:46 → 30:49

between all the parties.

30:49 → 30:52

One is definitely another stakeholders,

30:52 → 30:56

maybe some other departments who who have to

30:56 → 30:59

deliver some up outcomes for the team.

30:59 → 31:01

So so this is very,

31:01 → 31:06

very important and responsible position.

31:06 → 31:08

Okay.

31:09 → 31:15

And from your own experience, how open, you know,

31:15 → 31:17

the enterprise client outsourcing software

31:17 → 31:21

modernization to actually try

31:21 → 31:24

to incorporate the suggestions of the tech partner,

31:24 → 31:28

considering these organizational aspects,

31:30 → 31:32

the role of product owner and so on?

31:33 → 31:35

I would say it depends.

31:35 → 31:38

It depends of the need

31:39 → 31:42

that lies on the ground

31:44 → 31:47

of the corporation.

31:47 → 31:52

If the company need feel the enterprise company feel

31:53 → 31:57

feels need to change something to to restructure

31:57 → 32:01

the way the they work.

32:01 → 32:04

It's a good good moment to

32:04 → 32:09

to propose some changes, some structure

32:10 → 32:11

revision, and so on.

32:11 → 32:16

If we if we are asked only to to

32:16 → 32:17

deliver

32:18 → 32:21

part of codes, part of features,

32:21 → 32:24

and that's all,

32:25 → 32:30

then I don't see much opportunity to to

32:30 → 32:35

to support this company in in big change.

32:35 → 32:39

We can only support this particular product owner in

32:39 → 32:41

some prioritization

32:41 → 32:45

and and so on, showing some good practices, but

32:46 → 32:49

the field is very, very narrow.

32:49 → 32:50

Yeah.

32:50 → 32:54

From my side, I would say it's changing for the better over

32:54 → 32:55

following years.

32:55 → 32:59

Big companies more often see and realize

32:59 → 33:02

that it's good to to have an open minded set.

33:02 → 33:05

And and they see the value of, you know,

33:05 → 33:08

going away from from kind of waterfall and all those big

33:08 → 33:12

processes in favor of a shorter time to market.

33:12 → 33:16

Seeing, you know, all those good examples of, you know,

33:16 → 33:19

like Spotify or Netflix or other big companies that they

33:19 → 33:21

they work in this way, and it works out,

33:21 → 33:23

and and they have a success in this.

33:23 → 33:27

So so more and more companies also come to software houses

33:27 → 33:31

like us with an open minded and with a lot of

33:32 → 33:35

space for us kind of to

33:35 → 33:41

first learn from us also and then to kind of cooperate on this level.

33:43 → 33:44

Okay.

33:44 → 33:48

Yeah, know that it's quite a complex topic, right?

33:48 → 33:51

Because we, as a tech partner,

33:51 → 33:54

cannot always influence the decisions of the client.

33:54 → 33:58

But I believe that you gave some very far pieces of

33:58 → 34:01

advice to our audience.

34:01 → 34:04

So that should work out to their advantage.

34:04 → 34:07

And before we proceed to the next question I have

34:07 → 34:09

prepared for you guys,

34:09 → 34:13

I'd like to remind you that we are still waiting for your questions.

34:13 → 34:16

So if you have anything you'd like to ask Matti or

34:16 → 34:21

Andrew, please leave them in the chat box. Okay.

34:21 → 34:24

So you mentioned, guys, actually processes and

34:24 → 34:27

workflows a couple of times already.

34:27 → 34:31

And I believe that this thing should be addressed too.

34:31 → 34:35

So my question is, is there any particular methodology

34:35 → 34:40

or maybe approach that is particularly fit for

34:40 → 34:44

making time to market a bit shorter and

34:45 → 34:46

more optimal?

34:47 → 34:49

Definitely.

34:49 → 34:52

Any agile methodology.

34:52 → 34:56

The most popular is scrum can help us.

34:56 → 34:57

So

34:59 → 35:03

the whole scrum idea based on the three pillars

35:03 → 35:07

and those which are strictly connected with

35:07 → 35:09

time to market our inspection

35:09 → 35:11

and adaptation.

35:11 → 35:15

So we all in every period

35:15 → 35:20

in every loop we want to check and

35:20 → 35:23

gather all the outcomes, choose the right ones

35:23 → 35:25

and adapt them.

35:25 → 35:28

And in the next cycle,

35:28 → 35:32

avoid maybe some mistakes or use those

35:32 → 35:36

outcomes to make something better

35:37 → 35:38

faster.

35:39 → 35:41

Yeah, I think you're touching a good point.

35:41 → 35:46

Scrum allows teams to develop features

35:46 → 35:49

and to release features to production much faster than

35:49 → 35:53

regular, let's say, water flow processes.

35:53 → 35:57

And this directly connects to having a shorter feedback

35:57 → 35:59

loop, which

35:59 → 36:01

allows those teams and

36:02 → 36:06

product teams as well to realize if the future is coming

36:06 → 36:11

in the right direction sooner with with Scrum.

36:11 → 36:13

Okay.

36:13 → 36:17

So would you say that waterfall is definitely a no go?

36:18 → 36:21

Is it acceptable sometime?

36:21 → 36:27

I'm a big fan of scrum and I believe scrum

36:28 → 36:30

mostly works everywhere.

36:30 → 36:35

But I would say that waterfall

36:35 → 36:39

might be a good solution in

36:39 → 36:41

some circumstances.

36:42 → 36:47

If our clients are

36:47 → 36:52

focused, for example, on some

36:52 → 36:56

very strict budget, but not

36:58 → 37:02

to having some

37:05 → 37:07

market dependencies

37:08 → 37:09

and so on.

37:09 → 37:13

Maybe if we are working on some very

37:13 → 37:16

tiny solutions,

37:17 → 37:21

I believe waterfall might be okay in in

37:21 → 37:23

such a situation.

37:23 → 37:25

But I in my opinion,

37:25 → 37:29

scrum works works almost everywhere.

37:29 → 37:33

Not only IT, not only product delivery.

37:33 → 37:37

It can be applied to many departments,

37:37 → 37:41

many companies, and many area areas.

37:41 → 37:45

Even, for example, in Netherlands,

37:45 → 37:48

sometimes it it's used in some

37:48 → 37:51

schools and education product,

37:52 → 37:54

education industry.

37:54 → 37:56

That's actually pretty interesting.

37:56 → 37:58

And I believe that it's due to these, you know,

37:58 → 38:02

these pillars and values, you know, the transparency,

38:02 → 38:06

openness, and so on, that it's so universal.

38:06 → 38:06

Yeah.

38:06 → 38:11

I I would say that that scrum

38:11 → 38:14

values are very universal and and

38:14 → 38:18

could be applied to in in real life.

38:18 → 38:19

So so

38:20 → 38:24

being being focused on on the right things,

38:24 → 38:28

having rest respect to to our court because

38:28 → 38:32

who who would be who would disagree that these are

38:32 → 38:35

the the the right factors.

38:37 → 38:38

Okay.

38:38 → 38:43

So we've covered the project management methodology to go for.

38:44 → 38:47

And now I'd like us to focus on tech solutions,

38:47 → 38:51

because I believe that they play a major role

38:51 → 38:55

in how time to market turns out in a mature organisation.

38:56 → 39:00

So, Andrew, I believe that that's something that's the question that you

39:00 → 39:02

will perfectly answer.

39:02 → 39:06

What solutions, what technologies should you

39:06 → 39:10

employ to actually make time to market a bit shorter?

39:12 → 39:15

Yeah, if we are talking about

39:16 → 39:18

the legacy code, for example, as well,

39:18 → 39:20

in order to kind of get out of it,

39:20 → 39:23

it's important to have the right code quality.

39:23 → 39:29

And the code quality comes with not only a clean code, but also

39:29 → 39:32

good processes when it comes to code reviews, for example,

39:32 → 39:37

or developing components in a reusable

39:37 → 39:40

way so that you don't need to, you know,

39:40 → 39:43

duplicate this code just slightly differently for

39:43 → 39:46

a different use, for example, which delays time to market, of course.

39:46 → 39:48

When

39:49 → 39:54

we talk about development, we cannot omit any kind of automation.

39:54 → 39:58

The more automation the more automated stuff you have,

39:58 → 40:01

the the the easier and and the faster you will get to with

40:01 → 40:03

your features to to the market.

40:03 → 40:07

Right? So what we can what are we gonna focus on?

40:07 → 40:09

We can focus on on the the continuous development and and

40:09 → 40:15

continuous integration, and we can automate testing it.

40:15 → 40:20

We can automate micro environments for for different features.

40:21 → 40:23

And we can, for example,

40:23 → 40:27

set up quality gates that automatically check not only the code,

40:27 → 40:30

but also some standards that are in the company when it

40:30 → 40:32

comes to security, for example.

40:33 → 40:35

If we are talking about automation,

40:35 → 40:39

it's very important to mention that

40:39 → 40:43

having some processes, some repeatable

40:43 → 40:48

actions automated allows our team to focus on

40:48 → 40:52

delivering new code, not on doing the

40:52 → 40:55

same things in every cycle.

40:55 → 40:58

So so it might be

40:58 → 41:01

very cost effective.

41:01 → 41:04

So kind of working smart and not really hard.

41:04 → 41:08

So they're doing the stuff that you don't have to do really to

41:08 → 41:10

keep the quality.

41:10 → 41:14

Especially this is important for all kinds of tests

41:14 → 41:17

because once you automate them,

41:17 → 41:20

then you can run them pretty much every time.

41:20 → 41:25

Let's say every code change can be tested

41:25 → 41:28

for multiple, like thousands use cases, for example,

41:28 → 41:32

which wouldn't be possible on a normal daily basis by doing manual work.

41:33 → 41:36

Okay. And how about infrastructure?

41:36 → 41:40

Can you also improve it in such a way so as to release

41:40 → 41:43

new features faster?

41:43 → 41:44

Yes.

41:45 → 41:47

Still kind of couple of years ago,

41:47 → 41:51

most common scenario was that there were few environments

41:51 → 41:55

mostly set up manually by some sysadmins or DevOps

41:55 → 41:56

in companies,

41:56 → 41:59

it was difficult to either change something in them or to

41:59 → 42:01

set up a new environment.

42:01 → 42:05

Right now, and more companies lean towards infrastructure as a code

42:05 → 42:09

approach, where the configuration of infrastructure

42:09 → 42:12

is also inside some repository.

42:12 → 42:16

And you can reuse this code in order to set up

42:16 → 42:19

environments basically on the fly.

42:19 → 42:23

And that allows teams to have dedicated microenvironments

42:24 → 42:29

for their tests, for figuring out integrations between

42:29 → 42:30

teams, for example.

42:31 → 42:35

And one of the common use cases is also usage

42:35 → 42:39

of containers in those environments, which

42:40 → 42:44

helps in kind of it separates

42:45 → 42:48

care for system

42:48 → 42:51

operation system and for the the underlying

42:51 → 42:55

infrastructure so that developers can focus on functionality.

42:56 → 42:59

It also comes with a risk because nowadays people think

42:59 → 43:02

that containers can be set up once and then forgotten,

43:02 → 43:05

and and you still need to to remember that

43:05 → 43:08

that they need to have updates,

43:08 → 43:12

for example, for security reasons.

43:12 → 43:14

Okay, so there are always trade offs,

43:14 → 43:19

but I would say that it helps to such a point that

43:19 → 43:22

actually taking care of it on a daily basis is

43:22 → 43:25

not that much of a pain really,

43:25 → 43:28

because the advantages are significant.

43:29 → 43:31

Okay.

43:32 → 43:33

All right, guys.

43:33 → 43:37

I think that you've equipped our audience with a lot of

43:37 → 43:42

tools for optimizing time to market and for making it

43:42 → 43:44

at least a bit faster.

43:45 → 43:49

So now I'd like to address some questions

43:49 → 43:52

that our audience had for us.

43:53 → 43:57

Okay, so there is one from Wojtek Pigla.

43:57 → 44:01

Wojtek asks, How do you set the goals in

44:01 → 44:02

mature organisations?

44:02 → 44:07

Because we already said that sometimes it's impossible

44:07 → 44:09

to say what the value of the optimal time to market should

44:09 → 44:13

be, but I guess that you should have some goals,

44:13 → 44:17

maybe KPIs, that you set in a mature organisation that you

44:17 → 44:20

need to attain to say, okay, we are successful?

44:23 → 44:25

We we can take,

44:26 → 44:29

I believe, mostly two approaches.

44:29 → 44:32

So independent

44:33 → 44:38

releases so every team can release by themselves.

44:38 → 44:41

So this is one goal to be

44:42 → 44:44

very fast on the market.

44:45 → 44:49

So every team can work independently

44:49 → 44:51

independently.

44:51 → 44:55

For example, our mobile department can

44:56 → 45:00

the the the from my perspective as a scrum master,

45:00 → 45:04

there is no need to wait for I for

45:04 → 45:08

example, web dev development with some

45:08 → 45:10

mobile improvements.

45:10 → 45:13

So so definitely, it's it's one way.

45:13 → 45:17

And another just to make those releases even if we

45:17 → 45:22

release as a whole company just to make them more often.

45:23 → 45:28

Every at the end, everyone will be satisfied.

45:30 → 45:32

Okay.

45:33 → 45:35

Andre, do you have anything to add to that?

45:36 → 45:39

I cannot a little bit kind of put a highlight on the on the

45:39 → 45:41

isolation of teams.

45:41 → 45:42

Sure.

45:42 → 45:43

So

45:44 → 45:47

thing that enterprises especially struggle with when

45:47 → 45:51

it comes to developing features is dependency between teams and

45:51 → 45:53

between different products.

45:54 → 45:57

So setting a goal to improve that

45:58 → 46:01

already kind of a step forward.

46:01 → 46:04

And it will pay off in the future because it will allow

46:04 → 46:08

teams to move independently in their own pace.

46:10 → 46:13

This will mean that they will develop

46:13 → 46:17

things faster because they don't need to wait or be

46:17 → 46:21

dependent on just external people.

46:21 → 46:23

Okay. Thank you for that.

46:23 → 46:26

It's a very insightful thing to keep in mind.

46:27 → 46:28

Okay.

46:29 → 46:32

I can see that there are no more questions from the audience.

46:32 → 46:35

But if you're watching a recording of this live session,

46:35 → 46:39

you can always leave them in the comments and we'll answer it then.

46:40 → 46:44

But to finish off, I have one more question to you guys.

46:46 → 46:50

Because we focused on making time to market

46:50 → 46:53

faster, and that's definitely an issue

46:53 → 46:56

when we are discussing mature organisations.

46:56 → 46:58

But how about going too fast?

46:58 → 47:02

Is it actually possible to happen in a mature

47:02 → 47:04

organisation, in an enterprise?

47:04 → 47:05

Can it be the issue?

47:11 → 47:16

I think we can we can talk about going too fast if

47:18 → 47:19

only in in in, I guess,

47:19 → 47:23

in in rare condition when you when you skip kind of the feedback loop.

47:23 → 47:28

Because then and only after the the product is kind of realized,

47:28 → 47:30

can you can think that somebody was developed something was

47:30 → 47:32

developed too fast.

47:32 → 47:36

Because, for example, you focused on developing a

47:36 → 47:39

feature that just completely missed your

47:39 → 47:40

target audience.

47:40 → 47:45

Although you developed it a month before your competition,

47:45 → 47:48

you actually will lose those clients and potentially

47:48 → 47:52

indefinitely because you just lost their trust.

47:52 → 47:55

That's kind of one of the reason that you might be going

47:55 → 47:59

too fast that you might be losing your clients basically.

48:02 → 48:06

I can imagine also situation when we know that

48:06 → 48:09

to the nearest release left,

48:09 → 48:13

I don't know two weeks and somebody decides

48:13 → 48:19

we need to fit a new feature before the release.

48:19 → 48:22

And unfortunately it's too complex.

48:22 → 48:25

We have not enough time to

48:26 → 48:30

fully prepare it and we agree and do everything

48:30 → 48:34

to to squeeze it in those, for example, two weeks.

48:34 → 48:39

And then we realize after going on

48:39 → 48:43

production that it wasn't well prepared.

48:43 → 48:45

So so in this case, also,

48:45 → 48:49

we we may have situation even in such

48:49 → 48:51

a

48:55 → 48:58

not so often happening releases,

48:58 → 49:02

we can go too fast because because decision

49:02 → 49:05

was was made

49:07 → 49:08

not in the right moments.

49:08 → 49:12

Some somebody took

49:12 → 49:16

took took wrong factors into consideration.

49:17 → 49:18

Okay. Thank you.

49:18 → 49:23

So in short, you should always be careful when you're a mature organization.

49:23 → 49:26

So you can go too fast, go too slow.

49:27 → 49:30

There are certain things that you have to keep in mind if you

49:30 → 49:35

want to still be one of the big players, the successful ones.

49:35 → 49:35

K.

49:35 → 49:36

Yeah.

49:36 → 49:41

I I believe that we can also think of

49:41 → 49:44

situation that big companies

49:45 → 49:48

work in in some kind of bubble.

49:48 → 49:52

They they they are forgetting about their users,

49:52 → 49:55

about asking them about including their

49:55 → 49:59

feedback in in in plans, in company plans.

49:59 → 50:03

So so also so it might be a problem that we are

50:04 → 50:07

focusing too much on our internal ideas

50:07 → 50:12

without listening to to the people outside

50:12 → 50:13

our organization.

50:15 → 50:17

Okay. Thank you very much, guys.

50:17 → 50:19

It's been already an hour.

50:19 → 50:23

I mean, the time flies really fast when you have such an interesting

50:23 → 50:24

discussion going.

50:24 → 50:26

Thank you very much for your insights,

50:26 → 50:28

for sharing your experience,

50:28 → 50:32

and just for accepting our invitation to take part in this live session.

50:32 → 50:34

I hope you had fun.

50:34 → 50:37

Thank you. It was a pleasure and fun.

50:37 → 50:40

Nice to hear that. Thank you very much.

50:40 → 50:42

Okay, so as I said,

50:42 → 50:46

you will be able to watch the recording of this session later

50:46 → 50:47

on at your convenience.

50:47 → 50:50

And if you come up with any questions regarding software

50:50 → 50:54

modernisation or time to market or the related topics,

50:54 → 50:58

just feel free to leave them in the comments or

50:58 → 51:02

just to write us, to message us on social media.

51:02 → 51:05

So see you during our next live session. Goodbye.