Hi everyone, my name is Patrick Akew and have you ever seen an
organization deliver feature after feature after feature in
their software with seamlessly no issues.
I have and you do that with mature software delivery which
is exactly what we covered today.
Joining me today is Elias Nogueira and it was a real blast
learning from his way of working what quality is in software as
well as how to collaborate with product enjoy beyond coding.
I was going to say I just joined recently a new client and the
person there, the product manager and he also did most of
the scrum master rituals. His preference was really having
a physical board. So then when kind of a Sprint
cycle changed then everyone would be in the office and I
agree with that. I think that has my preference
as well. And there was one problem still,
because we had people that would either join remotely and then a
physical board doesn't work. As soon as it hit hybrid, there
were pain points because then it's like, what do you want me
to put on the physical board? Like it didn't work anymore.
Yeah. Yeah.
So that I thought that was funny.
Yeah, when I was working the in the previous company before I
moved here, we had a lot of teams like initially doing scrum
and for them to learn in the process and like visualize it,
that was was like really the a bad a best decision Doing this
like in a formal way like with stickers, yeah and everything.
So they can like OK they they can understand the flow, they
are actually doing something. I don't know if like probably
learn a little bit faster like by doing things instead of just
like created some abstraction and it was really easy because
after a while they like OK, they were master.
It's not that difficult but it's good because as well like it's
not just like that stand up meeting that you just talk but
you talk and do something and you talk about you get a sticker
note and talk about the sticker note.
This is the thing. Yeah, this is we are doing and
it's it's different. It's just different than you are
in online with a board like OK, talking about the tasks, it's
completely different, but it's it's the, yeah, it's the
nowadays. We have to ish.
Yeah. I I almost forgot about that.
Like when I when I first learned about Scrum and that way of
working, I love the physical board.
It made so much sense to me and we could do that because
everyone was in the same room. Now with that history, I can do
it digitally and I I we know kind of that routine and that
way of working. But yeah, people coming into it
and then just staring at a digital board, I think that is
kind of the loss of magic. Yeah.
And it's different like because
we are seated all the time. So, OK, let me check the board.
It's just a different tab. Yeah.
So physically you, you stand up,
you go there, you think, OK, you, you're thinking more you,
you ask someone to join. And OK, what do you think about
this, this and that? So yeah.
Yeah, yeah. And you don't have to ask a
person to move it. You can actually go and you move
the thing yourself. You like.
Yeah, yeah, people move there and stuff.
Yeah. Yeah, I love that.
Are you there to or have you facilitated those sessions as
well when it comes to either a planning or retro or?
Yes, yeah. Do you like facilitating?
I like facilitating, yeah and the way like for me I I I work
at at some point with like with Agile coach but more for
technically in this, in this way, not for all the the the
framework and formalities but more.
OK, let's try to combine that is for me is the real agile.
Let's combine what the frameworks do does with the
technical part or we can technically now can do those
things in a gyre way with some technical practice.
And one of the things I was doing, I was the only one during
the planning session was guys, we will have one day planning
session, the timing slot will be the whole day and we will just
stop when we have everything. If you don't have everything the
next day we'll plan again. Why is that?
Because for me, time boxed plannings are not that good.
We can have refinement sessions, etcetera.
But if you have everyone thinking about all the
possibilities together, like without interruptions, it's
better and it's faster actually than you breaking down in like
different refinements than a planning session then you start.
So after a while, in the beginning wasn't like like
wasn't good enough because yeah, the whole day was starting and
some we were distracting a lot. But after a while, most of the
people understand this, Yeah. And they can like of course,
like taking 2-3 hours and it's done.
I like that they have everything they talk about, all the
problems, possible problems, edge cases and so everything
basically, yeah, and it's good. Just to to play devil's
advocate, did you see that people would get drained during
that kind of one day? Sure, after after 3-4 hours Max.
They are Jesus Christ. Yeah.
Let's do any other thing, yeah. Yeah, yeah.
But they would stick with it and they would reap the benefits,
yeah. Yeah, yeah, few teams did it
with me actually. But the teams that they stick
with it like they they they really saw the benefits.
I like that a lot. I might try that out.
What we have now is I'm coming into a role and I'm, I'm taking
up that facilitation mantle. And I like the idea of looking
at what's there first and then being like, OK, how can we
change this and how can we prove this?
And how can we try things out like a dedicated day and we go
until we're finished? Because from a focus
perspective, I like that. Otherwise you're going to switch
and you're going to start working and then you have to get
back into refinement mode and what did we discuss again?
And that's all going to take extra time.
So I really like that dedicated focus approach.
But do you have this as well as a as a facilitator, Sometimes
you see some problems. The guys are not seeing the
problem. You're seeing the problem.
At some point it needs to tell them guys this is a problem no
one is seeing. Is that true or not?
So they. Yeah, we we forgot about it.
Yeah, forget about it. Sometimes I do this.
Not sometimes a lot. I do this a lot.
Yeah. When I do, when I'm
facilitating, like I try more doing facilitation than more
like mentoring because it's it's different.
It's a different approach. Yeah.
You get more people involved instead of like kosher mentoring
individually and initiatives that I'm running.
I'm trying to be the the facilitator all the time instead
of like telling the guys, guys this is the direction this is
what we need to do etcetera. What is your opinion.
So instead of me seeing what they are opinion first I was
given the all the possible cases it's good let's say it, it will
depends right. It will depends the seniority of
people you have, the team you have.
But what I'm learning all this to hear more from them and then
I can give them, OK, this is a missing piece you guys are
forgetting etcetera. Yeah, so but for me it's still
difficult. So I still want to facilitate to
to give them the answers you know.
Of course you have to hold yourself back.
Yeah, I I one of the reasons I really like facilitating is
because I get the best what I think.
I get kind of the best experience understanding
everything. If I'm not facilitating, I feel
like I just do my part of the work and I I explained that and
I understand what others are doing but not into the detail of
when I'm facilitating that type of stuff.
Doesn't matter whether it's a retrospective, I feel like in a
retro, I really get a sense of the team as a whole or it's a
planning or it's a stand up even.
I get better insights. That's why I like facilitating
and because of that I don't want to hoard that just with me.
So then I think maybe other people want to do it.
If they don't then I'll gladly take it.
Yeah, but it does come with maturity.
And then Even so, I feel like not everyone likes facilitating.
Like even the most senior engineers, they don't really
mind if someone else facilitates.
Like it doesn't. It's not a thing that goes hand
in hand necessarily. It can, but it doesn't have to.
And there's a funny thing I believe like some companies are
have this approach to they have the team and any different way
of facilitating for everything they are rotating.
And this is one of the worst options ever because you maybe
will force someone that doesn't doesn't want to do that or not
that good and wants to focus in another thing.
So if you got the people that OK I in the team I can see one or
two that likes facilitating, let's stick to it instead of
like having everyone create these opportunities to everyone.
Sometimes they don't want to focus on that and focus on other
things. So yeah, it's tricky, right?
It could be the maybe the people that have had that.
It's either the fair approach, so everyone does it, so it's
fair for everyone, or that no one wants to do it, so then we
make it all equal. So then it's equal
participation. It's like one of those.
But I I I agree with you. If one person really likes doing
it, I like doing it, then yeah, let that person do it.
People will be happier doing what they.
Love. Exactly, Yeah.
Yeah, yeah. I wanted to cover mainly kind of
mature software delivery with you.
And I think we already sliced open way of working.
I think everyone has kind of their own way of working, things
that they've seen in the past and things that they're going to
bring with them in the future in ways of working.
But especially when you come together as a new team or an
existing team, if you don't have a way of working yet, there's
going to be opinions conflicting.
When you say we want, I want a dedicated day because I've seen
that work best and other people like no, that's going to drain
me. I want fragmented things and
stuff like that. From your experience, how do you
usually consolidate into like a team way of working that is
really effective for that team? What I think my context now they
have I have 14 teams. So for me like I need to have a
bare minimum process set for all the teams.
So I need the same way of working for some aspects, let's
say in the the in the development process equally like
distributed equally and then in the same way so I know like I
can predict if they have an issue.
The main benefit that I'm telling them is the.
How I can say this is the they can help each one in different
things, like 100 people can help each one because when you have a
problem everyone is doing the same thing in that way.
So they can help each other a little more faster, faster
actually than if they are doing a different way.
So the guys needs to stop analyse and we spend a little
bit more time. But you you could, you could say
to me that OK, this would break like somehow the innovation or
bring up like bring to the process new, new process, new
approaches, new aspects, but for me bare minimum process
established. Then you open up for teams to do
this differently. OK And of course you need to
give them time to do this differently even though it's
that that process is working and one team thinks OK, this process
might be done differently. I would say OK, do this in your
team first, do a POC, runs it and then share the experience.
Other people, other engineers will evaluate, will ask
questions, etc. And if you say that it's
beneficial, instead of rolling outs to everyone, let's adopt to
one more 234 teams and then yeah, we roll out to to
everyone. But I believe like being open
and have this opportunity to have this freedom to change
things is is the main is the main is the main aspect, of
course, because otherwise we would work like 4 years doing
the same boring stuff, let's say in this sense, right?
And there, there will be no innovation because you are doing
the same thing over and over again.
But like the set of bare mining process for me is good, yeah,
but open to everyone to try out anything they they want.
I really like. That I I had a problem in one of
the teams that we are we were doing this one team wasn't doing
like this OK, not even the bare minimum.
Not even the bare minimum because the main engineer in
that team was saying OK, I have better ways to do it.
Of course we know in that engineer was really smart and
OK, first, why why would you like try?
We were saying like try first doing what all the teams are
doing. Then you apply what you're
suggesting in your team so you can prove like in this way you
can prove that's working. It's there's a lot of benefits
but no, no I will do my way. My way is the same, OK?
The end goal will be the same. We will.
We will deliver software in the same way.
But in the end you were doing like in a super over engineered
way, OK, that he had the same results, sometimes even faster,
but the cost for that was higher in terms of development.
Yeah, so that's that. That's why I'm thinking it's
like proving to the other teams. Actually nowadays that's OK.
It's not good if you try to do everything alone and if you if
you don't follow the the bare minimum process.
You need to follow bare minimum process 1st and then you bring
bring like to the table net new things.
Yeah, yeah. I mean, I I love that approach,
especially from you overseeing those teams and then helping
when they're it's necessary. Even teams Co creating and
collaborating and helping each other when it's necessary.
As long as we have the same bare minimum, then you know the
processes that are in place. Yeah.
And you can adapt to anything that is new, that's built on top
of that. Yeah.
Could you give like an overview of the bare minimum you're
talking about? In terms of what we do nowadays
in the end to end process in a super short way, we do have like
we start developing an API with like the services with unit
testing, integration tests. In integration test part we
divide in two different areas, the integration between the
integration between the service and the mocks and we have the
database part as well. So instead of doing this any
database loopy grade migration etcetera, we do have this
integration layer because we have all the scripts, everything
we know everything that will be changing in advance.
So we do this in integration layer as well.
So we when we run the full set, before we merge anything, we run
integration tests for all the supported database for all the
tests we do have in parallel to minimise the the, the, the, the,
the time. And then we run all those
database migration, zoopy grades etcetera just make when we have
one. Of course just to prove OK
everything is fine so we can go to the next step.
Next step for us we have somehow the we call the capability
testing but it's the end to end API test.
So we deploy an environment, an ephemeral environment, and then
we run the same, not the same set of tests, but the test
without the mocks. But with the real integration we
exclude the mocks, we put a real service there communicating with
each other. Then we test that part and
basically we are doing all the front end scenarios that the
user would do, we are doing through the APIs.
Perfect because nowadays like everyone like a front end web or
mobile consumes those APIs. If I guarantee that I'm testing
this for the API layer and there's no issue, probably there
will be no issue in the front end when the user as a user
would use that. And then we have the set of
tests in the front end, but in the front end it's the same as
the back end unit integration. Then this part without mocks
which we have the environment with the front end and we can
test things. But the number of tests we have
in this last part, in the end to end is far, way less than the
than the API layer because we try to balance those things and
we know that we spend a lot of time in the front end because
it's flaky. It's it's difficult to spend an
environment, not difficult to spend an environment with the
front end, but it's more time consuming because you need the
front end, you need to interact with the front end.
It's not that fast than the API itself.
You need to do the flows, you need to wait for each page or
each interaction. So it takes more time.
Yeah, built up and yeah. And we need to be really smart
on which type of test and kind of test we had there.
Yeah. Yeah.
I really like that. Just kind of a great overview of
the quality and the baseline that is there and then teams
probably built on top of that based on new functionality that
comes in. Yeah.
And for example like before this part with the database we had
after the full end to end APIs and now we were thinking, OK,
but we have all the technology to do this beforehand.
Yeah this integration layer yeah so we started something we call
it like that we have the shift left testing approach that
everything that we can shift left like at the beginning of
the process not only technically like writing code word anything,
any practice we start earlier instead of start later and we
start a technical approach on the shift left testing like
seeing OK what everything we can do to shift left and we saw like
two things one was this database migration and integrating
everything and another like in this end to end API test we were
doing a single calls to the API instead of test integration.
So OK, this doesn't belong here. This should be before.
Yeah, so we're starting this. And actually we could reduce a
lot the whole full cycle of testing because yeah, we are
doing tests like faster and all the time.
So we can get the issues first in advance and then we focus on
what we use, let's say the customer's focus perspective or
customer tests or anything like this like OK, I will think like
a customer and I will apply those tests to anyway.
Yeah, the actual unit, user journeys.
User journeys, yeah, yeah, perfect.
Has, has there ever been a way or not really a way, a scenario
where people would cut corners basically in that testing suite?
Because as new functionality comes in, and especially with
pressure from the business to deliver, people might think that
delivering the software without tests or without accommodating
for integration or users user journeys is faster.
But obviously you and I know that for the long term it's it's
actually quite harmful. I'm blessed that in this current
company the the product people knows the benefits of doing
this. First.
Yeah, so they really knows. And actually they ask when when
they are running these sprints and everything that the quality
engineer does like it's we have quality engineers back end and
front Enders. So and they work in, they
distribute the load. So during the plane sessions
they talk OK those acceptance criteria, this one will be done
in the front end, in the back end integration layer only.
There will be no end to end test for that, OK.
But this and that we will have end to end tests and they start
developing at the same time. So quality engineers start at
same time as the development. So even there is no like let's
say they start one day behind basically right.
Because like when they start, OK, there is nothing to do in
the quality part, but as soon as they have some code, they start
together with the back end developers or front end
developers doing this. Yeah.
And we started in full automation like mode in this way
we almost don't do manual test, OK, Only few verifications in
the front end and we focus more on the estimation because we
know all the benefits. And actually the product
managers, product owners, they during this print, they check
OK, are you doing the automation for this feature because they
know that's like you do one time and then you have the benefit
later. Yeah.
Then they don't have to do it. Exactly, Yeah.
And this was a problem as well because everything basically is
is automated and they were not doing like the, we call it PO
Shack. This is good because they were
trusting the team that the team's doing this and testing.
Everyone is testing this but at some point it's good to have the
the owner of the product like taking a look at the product
before we can deliver instead of after because it was happening
after after we we was delivering the process the the the the
project itself the product owner few days later.
OK guys but this like this should be changed it.
That should be changed it, but OK, we just delivered that.
Yeah, you are in another iteration.
So why you are like it's too late.
It's too late. Yeah.
What happened? And we have this of course
discussions with the field. So nowadays they can see this
benefit. Of course they need to see
during the development process how the software is being built
and I believe this is a it's my personal opinion, it's kind of a
a general problem because some some POS I believe are not that
involved during the development cycle.
They wants to. They wants to see the final
product. Like a stakeholder.
Yeah, yeah. Not during the development.
Yeah, it's, it's interesting, right?
Because if you're creating the tests, let's say on an end to
end perspective or on a user flow perspective, your
assumptions or how you think the world works is going to also be
in there. And if the PO trusts that what
they think is right, everyone thinks is right, then then you
have no issues. But that's like that's really
hard to achieve. Like that's almost impossible.
That's why you always need kind of that that second pair of eyes
that sanity check to go over it and especially from the PO role,
that is just the responsibility that lies there.
So then to do it as a stakeholder instead of kind of
during that. If you don't do it during, you
don't get the ability to steer left or right and then you do it
after like any other stakeholder.
And sometimes they are like at least in our process, they are
creating this idealization first with the designers and then can.
They can see the software, but they cannot touch.
They can see all the designs, everything.
And they are imagining, OK yeah all the mockups, OK, this might
work because it's they they create this idealization of the
project, of the feature. Of course they know everything,
but it's different when you start using it.
So all the benefits you get when they start using it and they
started having a second thoughts.
OK, this is not that good as I was imagining using the mock up,
you know? Absolutely, yeah.
Yeah. The pain points arise when you
actually fiddle around with the tool and stuff pops up.
They will always pop up in development after like it's I
think it's inherent and as long as you take kind of this
iterative approach that whatever we have can still adapt in the
future, I think is better. There are two things that I
always say is that there are two things that will never change.
Bo will change something later and when they are experimenting
of course, because they can change their mind as well of
course, yeah, this is one and 2nd, we will all the time
deliver some issues. It's impossible to deliver no
issues. We aim to it what we deliver.
So if we start thinking about it and we starts to OK being fine
with that, the whole development process interactions if everyone
will be easier. Yeah, it gets easier.
I I've never, because I heard you mention that before.
I've never worked with specifically the term quality
engineers within my team. Have you.
Do you think that's a great way of working when you mentioned
front and back end and then separate quality engineers?
Yeah, I I've been like working this term, not working this term
because that is determined the market.
But what I'm truly believe in, at least I'm following my teams
and I I influencing my teams that you have a group of
software engineers, back end, front end and quality.
So a quality engineer is also software engineer is not like
that. We know from the past like a
tester that does do more manual testing than the other thing.
No, it's a software engineer that knows software engineering,
knows a little bit of programming back end and front
end and nowadays like knows a little bit of DevOps.
But his specialization is quality like a back end back
end. But the back end there knows
testing, knows DevOps, knows a little bit of something.
The same for quality engineers. The quality engineers for me is
like the software engineers with quality specialisation and from
company to company it depends. So the the the where is the
focus right? So in some companies more
towards the front end, in some companies more towards the back
end, some companies are more DevOps.
In our case it's a mix of everything.
So because like we have this quality here to advise the the
the other engineers in the way of quality and where we should
like if we need to add more tests, we are missing some edge
cases, more techniques we can do it faster but also helping them
to create those test automation sometimes not creating itself
because sometimes the back end developer needs to create all
the integration tests. But we are trying, we not
trying, but we are looking at the the tests and say OK guys,
this test is the test that we have defined it but it's not
covering everything we should cover.
So they can double check and they can like pass this do this
mentoring part in quality. All the developers.
Yeah. And for me like this is the way
that all the quality guys should do like nowadays I really I, I,
I really think that everyone has an should be an engineer in
position. We are adding to the titles
right, DevOps engineer, back end engineer etcetera.
Yeah. But we need this engineering
part, the basic of engineering and this is something missing a
little bit in the quality area because we have still this
quality people working more towards to the product as well
sometimes and work more in the working more in the front end
part, not in the back end or different aspect that are
important for the, for the, for the product, yeah.
The ones I've seen more from history and then I'm talking 5
plus years ago would only test indeed like a regression test
from a user perspective, so go through.
Overflows. Click and click.
And drag basically and then after each iteration, after each
Sprint delivery, do that again and then again.
And then throughout the years I've seen that evolve into
automation. And then as you say, yeah, I I
do see that component of quality more so being prevalent more and
more within engineering. The only part it was where my
where I didn't really understand what the quality engineer does.
But now that you explained it, it's still hand in hand, right,
with a focus on quality, but engineering as a core, Yeah.
And I think with that explanation that makes a lot of
sense. Yeah.
And there's a second thing like we still, the market still
thinks that the quality engineers are quality people
needs to be more in the product side, OK.
And I disagree. OK, I also disagree, I think.
Yeah. Any engineer should know about
the product, absolutely not the quality engineer with the
product owner. Everyone needs to understand
equally the product so we can better develop that product.
If we think like no, let's try to create this separation.
Quality engineers will do the front end testing like manual
automated and we'll talk more to the people about the features
and see all the edge cases. This is in the end of the
process. We should bring to the like, we
should push the left the shift left testing or shift left
mentality and then we like together with the PO everyone
should understand the products and then we can build the
product in a better way. Yeah, interesting.
As kind of a thought experiment, have you seen, Let me take a
step back for me, when there's more roles and responsibilities,
When people get a title like DevOps front and back end, they
put themselves more so in this box.
Yeah. And then when work pops up, work
gets basically grab based on those boxes if it's front end or
back end. But then what slips through is
the work that's kind of in the middle.
So especially when you have a new role like quality
engineering or have you seen people say, oh, that's kind of
their job and I don't do that or how do they still kind of
cooperate and get stuff done? Because those titles, they
sometimes do make a difference. Yeah and the the most common
behaviour or bad behaviour is that when you have a quality,
when you have a specialized engineers right back end, front
end and quality and if you don't have the good or good mentality
or quality mentality across the team, the back end there will
see the word test quality in your.
Job scooch it. Front end will say, OK, we need
to test something in the front end.
We have a college engineer for that and they are just like not
doing actually their job that they should do and should be in
cooperation. That's why we divide the work
there. Those kind of things like
integration, it's a core for each engineer like the back end
engineer knows how to do integration.
The front end knows the quantity in you shouldn't be involved of
creating it, But reviewing it and talk to them and say okay,
are we covering all the possible cases.
Let's talk together. Let's see because this is the
shift left. Yeah.
And then Okay what is more ends to ends or has more integration
or any kind of test like performance tests or sensibility
testing or any kind of like no functional test, we can give it
to the quality engineers and they can help the team to
deliver this because they have more like they have more
knowledge on that so. Exactly.
That's their focus. Yeah, it's yeah, what makes
sense. Yeah, it makes sense I think.
Have you ever been in a situation because especially you
mentioned quality engineers advise, but with the role of an
advisor can also people can also say, well we take that advice
but we still do this and that can have consequences And then I
think your culture is kind of make or break there because if
it's a culture of blame and I told you so, that's very
harmful. No.
Yeah, it's it's not a coaster of blame.
Thankfully, all the teams are super cool in this way.
That's good. But this happens sometimes.
Yeah, right. But we most of the time we send
like reminders. So OK, the team decided that we
won't do this, this and that, or we would add one or two edge
cases. It's fine.
But normally we see the problems later.
We see one like later, not in the next iteration but like
months later. And we are just setting a
reminder guys, we discussed about it and we didn't do.
So let's try to next time, let's try to implement.
You do take more 10 minutes, 15 minutes doesn't matter but we
can prove that you take less time.
Now we are discussing more than 10 minutes just because we
didn't do this before. And and there's a second, the
second thing for me in the terms terms of teams, it's not fully
related to quality, but it's also related to quality.
It's given this opportunity to, OK, I don't want to do, I don't
see the benefit, OK, let's don't do it.
And if we fail, we fail. We learn with that failure, we
see what we can improve and then we improve later.
So this culture of like more cultural failure, for me, it's
really good. Not because you won't deliver
anything, but like allow them to fail in interactions and try to
see the problems. You know, we try to find a
solution. It's the best so they can learn
really, really fast. Yeah, I feel, I feel like I've
I've heard that more and more and I feel like sometimes it's
hard to put in practice. But I think the more people have
that mindset of failing is OK and it's a it's a way to learn
and progress. I think it's like at the heart
of engineering culture because what we do does not come without
fail. Fail is always there.
It's always going to be there. You also mentioned we're going
to deliver software and it will have issues.
So if we accept that it has issues, we can accommodate for
that and we're not surprised when it actually does have
issues because it will happen. I feel like that's very
important for a team to kind of mature and also in their
delivery. Yeah, and even for people that
never did something, we are saying OK, do this and they say
OK, maybe I will fail, maybe this will be a problem for other
teams do. If it's a problem, first
acknowledge the problem. Second ask for help.
Then a lot of different engineers will jump in to help
you and this is what happens. Actually, that's great because
we have this kind of fear that OK, we did a mistake, we need to
hide ourselves first, right? Yeah, yeah, we need to talk to
the team. OK, I have this problem, like
please help me to fix. But actually, if we allow
ourselves to say, OK guys, hey, I did this mistake, it was me.
I'm sorry, but I need and I need help to fix because I don't know
how to fix. A lot of engineers will say, OK,
yeah, it's a normal thing. No problem, no problem.
Let's jump in and let's fix it. And as soon as you allow this as
well and it's a, it's a it changed your mind a little bit.
Right. Because most most of the people
don't want to show up show and say, OK, it was me.
Yeah, scary. And when we allow this and
people say, OK, I I was sharing that, it was me.
No one blaming me. Nothing happened.
And they they are more comfortable doing these mistakes
and actually they will next time when they are doing they have
like a different opinion and maybe this will fail.
They are doing the same thing before.
So they are going to the channels and guys I will deliver
this. I don't know if there's probably
there's a problem and not seeing it.
Please help me. The engineers will jump in the
same way if if they had the problem.
Yeah, Yeah, absolutely. I like that we covered and
started with kind of way of working and then we delve more
into the quality aspects of software.
I think when we're talking about really mature software delivery,
a big aspect is the collaboration between
engineering and product and making sure that that is a
smooth operation that there's trust on both sides and that you
can also deliver based on that with realistic expectations.
I don't know where it sometimes goes wrong if the if the product
side is kind of lacking that engineering mindset or if the
engineering side is going to lacking that let's say
functional requirement in the business mindset and the value
that they need to deliver. I feel like it's always going to
be somewhere in between. But I think I shared with you
before from my side now I'm I'm moving from engineering to
product just to kind of experience that and it is fun
having seen kind of both sides in the pain points there.
What are the some of the pain points you've seen in the past?
Yeah and and it's both ways right.
Yeah because we don't actually the the the the main thing for
me it's the we don't know how to communicate between between each
other yeah because the yeah because the the the the all the
jargons and everything is different.
So we need to learn this like a new language to communicate 1st
and then we can not the not only the the way we they talk about
the product or we talk about tech, but also understanding the
keywords of the benefits. So for me if you tell product
people, OK I have this I cannot deliver this on time because
this will impact X days in the process and or this if I just
take one more day to finalize all the things, yeah this won't
have this issue in the customer which will stop the customer you
preventing the customer using it and maybe this will give them a
loss of X millions or anything like this.
They will get your they will get your attention.
They will you have their attention.
It's their language. If you yeah, when you start like
understanding their language OK customer money things like that
that actually product right. So OK they will stop and they
listen to you and they will help you actually.
And for me the the when I talk to product people most of the
time I talk about the problem. Of course we have a problem.
This is the problem. This is the context.
I I love like when I write a message to everyone like it's
like a chapter. Like I give the context, I give
the what is happening, why that's happening, what are the
possible solutions, what is the impact of that And most most
important for other people, the impact and I say guys, this is
the impact, the risks and I cannot take this, this is risk
alone. So it needs to help me to
understand. And for me in the end product
people have the decisions of course because it's product and
that's why it's there's a steering wheel for the company.
So they know the direction, they know what the customer wants
etcetera. And the the main, the the other
problems we do have it's this kind of fighting between each
other because we don't understand each other, right.
So we are fighting why they are needs to change this one one
classic thing product people in the middle of the interation is
printed etcetera. They wants to change something
or they wants to add something in the middle.
Something urgent all of a sudden.
Yeah. But what we do, we complain
instead of, OK, sit with me, explain why this is good.
No, no, OK, I understood, understood.
But explain me a little bit more.
Yeah. Because maybe that requirement
that the customer is selling to the product is not fully, fully
ready as well. So we need to understand as
engineers first why that's happening and then OK, it's
makes sense. So let's stop what we are doing.
Let's do this new thing to collaborate with product in the
same like in the same way. One of the problem, not problems
but learnings we are having together there is that we have
this tech versus product all the time and most of the time
probably the people they have their their their calendar, they
they they backlog for like 3-6 months, one year like planet,
right. And but at some point tech has a
lot of things in the middle, not the the development process but
we have OP grades. If we have new approach we want
to apply to reduce the time of development or to increase the
quality etc. And we need to start
negotiating, yeah it will impact their backlogs.
This is kind of a problem, but a good problem to solve as well.
And this solves with communication and actually this
proper communication. Just saying that is that
important. It's it won't be listening.
No, because everything is important.
Everything is important. But as soon as you OK, this is
the benefits, this is the impact, this is the risk, they
start listening to you again. So OK, they they try to
understand. They they will try to understand
all the time. The problem is more this
communication and OK, how we can understand each other.
Yeah, I think the the more we indeed focus on language, the
better we can understand each other.
And then it's at the end still about trust, right?
If someone says no, you can still work and you can still
commit and you don't have to butt heads when people disagree.
Because I think always that's that's within a team of
engineers and especially engineering and product people
will still disagree and people will have a different vision on
how we should move or if we should move left or right,
especially when it comes to product decisions.
And at the end of the day, it's all assumptions anyway and we
will have to make decisions. And then if it turns out to be
wrong, exactly as if as if how you would treat engineering when
when a mistake happens, you pivot, you say, OK, we've made a
mistake, we've learned from that, you pivot and you go the
other way. I feel like the more we realize
that that it, that it is iterations, the more flexible
you'll be as a team. What I'm struggling with still
is people that kind of like that or that don't like that
iteration. I feel like sometimes I've
worked with engineering both in teams and from outside of the
team, working in people that want to do one thing and then
have it be right and then not have it be changed basically,
and that's really hard I feel like, to achieve.
And I'm reading a little bit more about this this topic, this
product minded engineers that normally what I have in the
teams technical minded engineers right?
Because we we see the the feature or any change, we
instantly start thinking about technically how we can approach
that. But we are not thinking OK, how
the user we've approached that, how the product we've approached
that and then I will create the technical solution.
So they are the product minded, they will OK, why we are doing
this? Yeah, for which customer, what
are the benefits, which way they are using and then they start
thinking about the solution. This you can see this more in
the architect. For example, when you talk to an
architect, the architect normally will say, OK, what the
use case what the user will do, yeah what is the known function
requirements because they have this full experience on this.
They know how to prevent this kind of problems.
Yeah but engineering the teams don't have this and as soon as
we have like trying to influence the the the engineering the
teams to think about the product first, then they can like deep
dive in the technical solution. Better.
Yeah, better. Yeah, I agree.
It's funny because I'm I'm now in that product seat and I'm
looking back in my experiences and as a personal preference, I
I always went for solutions I didn't have to build because I
think that would be more valuable, right?
The less code we have and the more problems we solve without
kind of technical solutions, that's better because that gives
us room to improve and to expand in the future without kind of
having this weight of code. Because I feel like more code
you have it is kind of a wait and at some point you can do
things of standardization and accommodation, but it is still
weighing you down in some degrees.
So the less functionality and the less features you have.
I think the faster you can keep going because it it at the end
of the day it's a marathon. But now that I'm in the product
seat, I do see that, OK, Even from design, when we see a
problem, everyone loves coming up with solutions.
We can do that. We can do that and then that.
And the people fixate on that. And I'm like, yeah, but is this,
is this really a problem we should be solving?
Because not every problem I feel like needs to have a technical
solution. No.
And that's the realisation, yeah, that I think a lot of
engineers can do well with. And even like I have this, this
kind of discussions as well because we trying to follow
indirectly the zero bug policy. When we deliver something, no
issue should be delivered. If we find that issue we fix
then we deliver. Yeah, but at the end, like for
me, I changed my mind in this way because I was thinking all
the time that no, we should deliver with zero issues.
But when we start talking to the product people and say, OK, we
have this issue and we have this deadline and we need to deliver
the software, this feature, what do you think?
And they can give an awesome insight.
They will say, OK, this issue like 1% of the customers will,
will, will hit this, this, this point.
So let's deliver because of the time of restrictions and another
thing constraints and then we can fix it.
So this kind of prioritization is good as well because as a
quality engineer we don't want to see anything being delivered
with bugs or failures. But like as soon as we start
talking to product people, they have all insights, they can even
see like a small issue that is not blocking issue, but OK, this
is important, no. And we need to fix that.
So from from my perspective was like looking but this is not
like stopping anything but this is an issue but maybe for the
product people, no, this is a huge issue this differently
because I have this, this and that's inside.
So it's it's good also to have this kind of, it's not good that
we that we think and we deliver software with issues, but it's
good to have the conversation with other people to understand
what is the impact, right. Of course, of course when you
have something blocking that you know that will block the
operation and the customer will stop of course will fix right
away. But other things just talk to
product people and it's hard when we say OK we are delivering
things with bugs it's it's really hard.
We don't want this because the whole, the whole like the the
whole area, the whole IT area, it's telling you all the time we
need to deliver without any issues.
Yes, like a professional pride. Yeah.
And as soon as we Start learning a little bit more about it's
talking more with the product people to understand this, it's
it's become easier actually to deliver software, right?
Yeah, yeah, absolutely. It's, it's funny because you
really made me reflect on kind of the gaming industry.
When I'm thinking back when I had like APS One, I would have
this disk and then that would be that and all the bugs that would
be on that video game, it would be there forever.
Forever basically. And nowadays you download your
software, you don't even have like a disk anymore or or ASD
card or anything. It comes and as soon as it hits
release, it already comes with an update patch.
And then probably the next day another update patch.
Because somehow with a certain button combination you can clip
through a wall and then you're out of bounds.
And then oh, they fix that with another patch and things get
released with more bugs. And I especially see it in the
gaming industry, sometimes with too many bugs.
But then immediately they hit you with upgrade patches where
all of a sudden it looks like a really good game again.
Yeah, yeah. And it's tricky because when I
play as well, sometimes I'm playing playing something and
I'm not, I'm not seeing that issues and some players are.
So it's exactly like this like the I try to try to combine with
the what I was saying about product.
So maybe the product will say, OK, this issue only 10% of the
players will will reach this point.
So let's deliver and then we patch.
Yeah. Because most of the users, most
of the players won't won't reach that point.
So it's fine for now. So we need to have this balance
as well, right? Of course we don't like it when
as soon as we see it right, as the players let's say.
But yeah, it's the it's the time to market we.
Know everything? Yeah.
I think the the hard part or like the downside would be
because people also estimate then their releases on that.
Let's say if we're still taking the video game example, oh, we
did that in the past, then yeah, we can still make these
deadlines because everything looks.
Similar. The problem is the reality is
not always similar. So then all of a sudden you
might have to release or you might have a deadline which is
actually not feasible anymore. And then you can do two things.
I think I've seen from engineering position you can
really do everything in your power work day and night and try
and make it happen and then you still have that kind of make or
break moment or you have to push back and say listen, I can't do
it. If you want go ahead even though
they they cannot do it because they're not technical minded.
But you have to have that conversation and those
conversations can be quite hard. Yeah.
Yeah, I feel like exactly as you said when you're asking for
help, you did your homework, right?
You said why? You said this is the urgency.
If we don't do this, then these are the consequences.
That really helps when driving those conversations.
But at the end of the day, I feel like with mature software
development with mature engineers, a skill is also
putting your foot down and saying no sometimes.
Yeah, that's for sure. And we have a lot of ways to do
it like even during the interaction let's say if you do,
if you use like sprints for example, if you use scrant, we
know the front scrant that OK, you can add as much as features
as possible during the the this time frame like can be one week,
two weeks, etcetera. But we know that we can
prioritize one or two and the PO can say those are the real
priorities from this iteration. So let's focus on this first.
If we focus on that first and we see problems, the PO knows that
other features are not that important than that one.
Yeah, so we can we can have even ways to try to avoid some most
of the problems of it, but it's still it's there.
So the the communication part, right.
So this, this, this must happen with product.
And this is also communication problems, right?
Because we have the deadlines, we have issues and sometimes we
don't know how to express when we are having issues and we say,
OK, this product or the interaction for this feature
cannot be delivered or won't be delivered on time.
We don't know how to express the problem to the product people
and say, OK, those are the implications, those are the
risks, those are the problems. So in the end, actually
basically almost everything is communication, right?
Yeah, yeah, I think so too. And I think the hard part is,
and and maybe this is a cop out, a lot of communication skills, a
lot of that kind of business language, that way of working
comes with experience, right? You have to have been in a team
where there's a mature level of software development and
delivery and milestones that get hit time and time after again
that you see, oh, there's a dialogue that's happening and
we're not just executing. I feel like if you find yourself
in a team that's just executing and that is bumping heads and
then that's a symptom of a dialogue that's not happening
and it it needs to happen for things to progress.
I feel like, yeah, I really enjoyed this, man.
This was a blast. Yeah.
Was this kind of what you expected coming into this?
Yes, it was. Yes.
Because like, this conversation is like going to different
directions. It's good because yeah, we can
talk about basically everything, right?
Awesome, cool. Then I'm going to round it off
here. If you're still listening, let
us know in the comment section what you thought about this
episode. And with that being said, thanks
for listening. We'll see you in the next one.