Introduction to APIs and API versioning for Agile Coaches with Maciej Gowin

A comprehensive introduction to APIs, detailing how they facilitate data exchanges between different systems using protocols like HTTP and formats like JSON. It covers the principles of RESTful API design and discusses how APIs can be developed and refined iteratively, including the challenges and strategies involved in managing different versions of an API.

Agenda
• What is an API?
• Data exchange between systems – frontend and backend
• What are HTTP and JSON?
• RestFul API basics
• API versioning options and challenges

Maciej Gowin
Developer, practitioner, easily accessible knowledge-sharing enthusiast. Head of Java Development at Ryanair Labs. Former programming teacher and PhD student at Jagiellonian University.
Currently a lecturer and co-creator of the postgraduate program “Programming in Java” at WSB Merito University in Wrocław and Warsaw, Poland.
Promoter of the idea of learning based on embedding subjects in the context of their actual application.

Find us here: www.agileleanireland.org

Transcript

Our tonight's speaker is Maciej Gowin, Head of Java Development and Triangle Labs. I had the pleasure of working with Maciej and know he's super funny, friendly, and easy to work with. But most importantly, he's passionate on the topic and can explain very difficult topics in simple and enjoyable way.

Maciej is a former programming teacher and PhD student at Jagiellonian University. Currently, he's a lecturer. and co creator of the postgraduate program, Programming in Java at the Polish universities. And he's also a promoter of the idea of learning based on emptying subjects in the context of the actual applications.

Very fancy. It's basically making learning fun and connecting theory with practical implementation of it. And in many organizations, API development takes place ahead of sprint work. So ready APIs is part of the definition of ready to start the sprint. Today Maciek will share with us whether it's possible to develop APIs iteratively, and if you can develop them in a sprint in parallel with other work.

Without any further ado, please let me introduce Maciek Gowin. 

Thank you. Hi guys. Very nice to meet you. It's a pleasure for me to be here. So I got the amazing introduction. So we're going to talk about the APA version and you, as you heard, I'm a technical guy, right? But at the moment I'm not only coding, but I also have the exposure to the business guy.

So I tried to connect two worlds where you have the backend developers. And you have the business guys who are trying to understand what is the magic that we are doing. So today we're going to be talking about the API versioning and the iterative approach to the to, to these APIs. Oh, wow. I got the introduction already.

My name is Maciej, I'm the head of Java development. I'm also. A mentor at CoderBrother. And the last thing, I'm a lecturer in WSB Meritoc, which are the Polish universities across the whole Poland. What we're going to be talking about today I'm going to give you a very brief introduction to the APIs and what we're actually doing as backend developers.

And then I'm going to jump in into the Agile approach and to the Scrum methodologies, how we. Try to approach these things from the backend guys perspective. Okay. If you have any questions, please ask me this question straight away. I'm always happy to answer the questions. And I think that this may be available as we go.

So the first we're going to start with the introduction to the APIs, then how we exchange data between the systems. Quick basics on JSON, which are the basics of the APIs, if you've never heard about it, and then the way of versioning and APIs and incremental APIs which are developed during the sprints.

And the most important thing, what are the major challenges that we encounter while developing the APIs? So what is an API from the backend developers perspective? It's just a simple interface that allows us to interact between the systems. So when you think about the API, it's like yourself driving a car.

When you drive a car, you don't think of all the details that are happening under the hood. You just have a simple interface where you have your steering wheel and you know how to accelerate and you know how to stop the car, right? So you have the interface which gives you, let's say three, four basic actions.

And what happens under the hood is just the internals. So this is how the system operate and how they use APIs, where they exchange data between between various parties. So you just have the interface, which lets you communicate and in the standard web applications, you have the website, which communicates with another server, which has the data.

So if you look at the Rhino website, we have the website. Which calls the backend system, which returns the data and that backend system, which returns the data. We call it a web API. It returns data in the known format that is understandable by the front end. Of course the API itself the API that, it's not.

only tightly coupled with the web API. We have various types of the APIs. So when you say, when you use the term API in front of the backend developer, it can be of course the web API, which is used to serve data to the website or the mobile, but you might also have the library API. So if we develop things For other developers, we also expose libraries, which can have its internal logic, but also they expose the interface that can be used by other developers.

Then you also have the operating system API. So if you work with your Windows, MacOS, Linux, You work with the abstraction layer, which is the API and then the API hides the details of how the system works. But of course, we're gonna only focus on the web APIs. But I want you to know that it's not only related to the way web API.

And what is the web API, basically, the API is the type web. A p is the type of the API, which operates over dub over the web, right? And it enables developers to integrate functionality. And I mentioned that it may be communication between the website and the server. But you may be heard about the concept of microservices where we have multiple back end systems that talk to each other and this back end system that talk to each other, they usually also communicate with each other.

over the web API. So web API is just a way of exchanging data between system. And what are the key characteristics of the web APIs? They communicate over the web using the protocol HTTP, HTTPS. I'm going to get back to it in a second. They work in the Request and response model as a simple web, you enter an address to a web browser, you press the enter button.

There is a request that is going to the server and then the server response with the data and of course endpoints. So all the resources over the web are identified by the endpoints. It's like an address of your home, right? Each resource in the web has an address. And that address defines the data that's going to be returned.

Okay, and the last thing that is important in terms of the web development is the separation between frontend and the backend. When we talk about the frontend, it's the part that is exposed to the end users. And which is usually working on your mobile device or on your computer and the backend system is a system that is serving serving the data as an example of the, of Ryanair website, we have a front end, which is the website and the front end development is mainly responsible for operating over the over the UI.

And then you have a backend, which is serving the data. For the front end. Okay. And, of course, web APIs, they also have different categories and you might heard about RESTful APIs and this is the most common way of exposing the APIs. The RESTful API is widely used over the integrations that we do between front end and the back end.

It relies on the HTTP standard. All right. HTTP is a protocol that is used to exchange data in dub. It's stateless. It means that each request

is not correlated with the any following request. So if you make one request to The server responds with the response and forgets about the request that was previously made. And then we usually use two major data standards, which is Jason and HTML to expose the data through the API.

There are other types. I just wanted to mention about them that there's other API, API types that are. used by developers, but these are mainly used by the backend developers to communicate between backend systems. So you have a SOAP. It uses also HTTP to communicate. So it also goes through the web, but it's a bit more formalized and it's used XML.

Then we have also GraphQL. It's got a bit of traction recently the GraphQL differs from the REST API in the way of exposing data RESTful APIs they mainly have the model, which is tightly coupled with the endpoints with GraphQL. The model is a bit more loosely coupled where the front end developer can explicitly define what are the data that.

He or she wants to retrieve from the backend system. We also have a WebSockets in the standard web, you have a website, which is calling the backend system to retrieve the data, but if you ever heard about WebSocket, it allows you to do for the bidirectional communication. So you might have. Website, which is calling the server, but the WebSockets are also allowing the server to send the notification to your website.

So if you see, ever seen a push notifications being sent to your browser, it's usually done through the WebSocket API, which is also an example of the Web API. I've mentioned about HTTP and whenever you work with the APIs and you try to understand the nature of the APIs, incremental changes to the APIs, It's good to know what the HTTP is in the web.

We work with the levels of abstractions. If you think about your cable that connects two laptops, the cable sends the data using a binary code. So it's just in the low, very low level is the stream of zero and once. And then we build abstractions over the basics. which allows us to easier communicate and describe the communication in the most abstract way.

And HTTP works on the top level of the abstraction where we define how the data can be exchanged between systems in In the very high level way. It is the basic of the dub. So you might see that when you enter the website, you always start entering the website with HTTP or HTTPS under the hood, the browser converts.

the text that you enter to the browser into the HTTP call to the backend service. So the front end communicates with the backend using HTTP. It is mainly a protocol to transmit the data between resources. And of course it uses the request response model. So you ask for for the resource and you get the resource in the response.

And it's of course stateless. Each request it's separated. Requests are using methods. The methods define the action that you want to do on the resource. So when you enter the website, when you enter the backend system, you retrieve the data, you're using a get method. When you want to send the data to the service, you use the post method.

It is very important in terms of the versioning of the APIs, how you structure the APIs and how the incremental changes are made. Gonna affect your systems. Then you have the URL. The URL itself identifies the resource that you want to retrieve or update. And then you have additional data such as headers which are acting as a metadata that can be sent to our service.

Then in the response, HTTPS response, you usually get the status that lets you know if your request to the service was processed properly or it gives you the error message which lets you know that something went wrong with your request. And as a response, you're also getting data. When you look at your website, you do the request When you look at the browser, when you do the request to the service, it goes to the server, the request goes to the server processes the request, and responds to your browser with the HTML, which is actually responsible to to print the website.

So we have various methods. I'm going to mention only two of them. We have a get method, which, Let us to retrieve the data from the server, and we also use post method to send the data to a server. There are various status codes. We have three major status codes that the server can respond with. Status code 200.

It means that our website, our service, sorry processed the request and ended up with the successful processing, which usually returns some data. Then you might have client codes, which starts always with four. As an example, four, four, not found, you probably notice that sometimes you enter. the URL that is not found on the server.

So the server usually responds with 404 if the resource is not found on the server. And then you might get 500 errors, which are more server errors, where server tried to process the request, but something went wrong under the hood. Sometimes you are getting service not available, which means that the server has a problem with processing the request.

It's not the client while the four or four or four O errors are more about the client doing some wrong action. So if you enter the resource, which is not found, it's your fault.

itself. The last thing is the actual data format that we use to exchange data with the websites or the mobile. This is JSON. And the JSON is the standard that describes the structures in the key value purse. It looks like a dictionary. So you have a key such as first name. My first name gets a value, which is Machi.

Then my last name also gets a value, which is Machi. But of course JSON allows us to do also the structure embedding. So I can have a property, a key that, that's value is another structure. So as an example, I can have a phone, which is composed of another structure, which has another properties.

And why we as developers, we like JSON and exchange data using JSON, because it's very lightweight. It's easy to read, but humans only by looking at it, you straight away know what this is describing. That model is this describes the person, right? So it's easy to read for, by the humans and it's easy for machines to parse that format.

Let's say that you wanted to use an Excel as a format, right? Excel is error prone. There's loads of mistakes people do with Excel. With the JSON, it's just a plain text that allows you to exchange data. It's widely used and it's language agnostic. There's loads of libraries in every language that can easily process JSON and converse the JSON.

Into the language specific objects. So how do we combine all these things together before we jump into the versioning? Whenever frontend either it's website or a mobile wants to retrieve the data from the backend system, we usually start with the resource that we want to retrieve. The resource is identified by URL.

So as an example, I have a resource. Which describes a person, I created a name point, which defines a person, which is sorry, not the person, the customer. So I want to retrieve a customer identified by the ID ABCD1234, then I have the identifier of the resource. I use the HTTP operation to tell the servers that I want to retrieve that resource.

So I'm going to use the getHTTP verb. Then as the response to that call, my server is going to tell me, Okay, I processed your request. I found the person and I'm giving you status 200 because your request was valid. And then I'm going to send you the response with the details of the person in the JSON format.

Okay. So imagine now that there was a mistake in your URL and you ask the server for a person that does not exist. In our database, then my API would return as an example, status code 404 with some kind of error message saying the person was not found, then you might have another problem, you call the server, but there's so many calls to your server, the database, cannot handle that many requests, you might get a 500 error from the server saying there is something wrong, sorry, with processing requests because there are so many requests coming to a server.

And this is how we work. We usually work with the APIs by defining the locations and the resources and the resource describes the structure that's going to be returned by the server. Okay, so as an example, how we structure the URLs. So imagine that we have a customers. When you think about customers, what are the operations that you want to do with the customers?

Probably you want to, so let's say that we do a simple admin tool, which lets you operate with the customers. You probably want to retrieve all the customers. You might want to retrieve a customer by its ID. You might want to create a new customer in the system. You might want to update the customer details, and you might want to delete the customer.

These are basic operations, which we call crude operations, basic data exchange between front end and the back end and how do we design these APIs? So for retreating customers, we're going to use resource, which ends with the customers world. We usually use plural verbs. To list multiple users and to retrieve the data.

We're going to use the HTTP verb called the get. So if the website wants to retrieve all customers, it's going to do the HTTP call to get customers the same for the mobile. We usually design APIs to be agnostic of the platform. That's going to call it. Okay. The way I do the APIs, it's going to be the same for the web, it's going to be the same for for the mobile, and it's going to be the same if I want to have the backend to backend communication.

Then if I want to get a specific customer, you need to have the unique identifier of the customer. I'm going to call it ID. So I'm going to use another resource, another path resource. It's like a directories. You have a di directory of customers where you have all files. But if you want to get a specific file, use the path to the specific file, which always start with the directory, and then you have a file name.

In here, I'm gonna have customer name, which is gonna be identified by name. I'm retrieving the resource, so I'm gonna use, I'm gonna use the gi. Then creating by using a post. I'm sending a model of the customer to the resource customers. And then under the hood, the backend service gonna create a resource.

And I have a put for updating, I'm updating specific person, which is identified by the id, and I'm delivering a person which is identified by ad. And these are all the basic. And when you think about the backend development, the magic happens around how you define the resources. How you versioned the resources and how you mapped the business requirements into This magical API's that can be consumed by the mobile guys.

So API evolves and may require changes. I gave you an example of the customer which is identified by, let's go back here. I gave you an example of the API. Which gives you a customer identified by ID and the name, but what happens if you want to change the API and let's say on the front end, we had just one screen that was showing us a name, but we want to change something in the API.

So API evolves and may require changes. but these changes might be incremental. As an example, what if you want to add a date of birth to an existing API? First problem. The second problem, what if you want to split the name and return first name and last name separately? Looking from the business perspective, we change the screen from having only a name, to a screen which has a name and the date of birth.

This is the first problem and the other screen is going to be with not only the name but separate values. You're going to have a first name and the last name. So let's add the date of birth to the model. So how this can be done? We also have the request to the get customers identified by the ID.

We have name as it was before. I want to highlight it. It's the same name as we had before and we add the new property which is called date of birth. The question is, if frontend previously assumed that we had the model with ID and the name, if I add a new property called date of birth, if it's going to break the contract that was previously used, what do you think about it?

So let's say I have a consumer that consumed my previous API and now to that response, I added date of birth to the model. It depends. It depends. Yeah. Great. But in general, if we have wise front end developers. It should not break the contract, right? So if we had a front end developer who was reading the name and the date of birth just to display it, we are just displaying it.

I want to simplify it. I don't want to go into many more details. This should not break the contract. This change should be background compatible because if the user was just reading ID and the name, if we just add the new field to that call, it brought, it shouldn't break the previous previous view because I still have the name.

I haven't changed the model. Okay. So usually if we have additive changes, These are the changes which are not breaking the contract. The problem starts with replacing the API. So imagine that previously we had the name, but now we want to return not name, but first name and the last name separately.

So previously the frontend was displaying the name from the JSON object, but now we change that resource to return first name and the last name. And what happens here? We break the contract, right? So if we simply introduce the change to the model, this is going to break the the front end who was assuming, which was assuming that we're going to have a name, but now we are serving the first name, last name.

So if we start making changes like that, we need to start thinking how we can actually.

Implement the incremental changes of the APIs of the resources. So we still have the resource, which is called customer, but now the customer has a bit different, a bit different structure. So the answer to that is the API versioning and the backward compatibility. So we introduced the version and the version of the APIs and the resources.

And there is a few approaches that we can take to version our resources. So the first approach that we are taking to version our resources is the URI versioning. So what we do, we add the version in the in the URL of the API. So let's assume that we had a customer, which was identified by the ID and had only a name.

And we say, this was the first version of the API that defines the resource called customer. And then if you want to change the model, We're going to introduce a second version of the API of the structure called customer to add the new version. We simply change the URL to include v2 in the path.

Is this. Clear? I hope yes. Okay. So then this is the most common used approach to API versioning, but of course there are other ways to do the API versioning. So we have also a query parameter versioning. As you can see, we are still referencing to the customers by ID, but the version is not part of the URI.

It's not part of the path. It's part of the query parameters after the question mark. So we can have a version one and we can have a version two. This is the second approach. There's another approach where some developers, they prefer to send the version using headers. I'd mentioned about the headers.

Headers are a metadata that can be sent. with the request. If I reference to, if I do the reference to the given resource using the URL, I can tell the server to give me a model of the cluster structure of the customer in a given version. And the version is defined by the header that is sent to the server.

So I can say, give me the version B1 or give me the version B2 using the headers. I want to highlight the URL is the same. Subdomain versioning. This is for me, this is the least used approach where the version of the model is defined by the domain of the service. It's the hardest to implement in IBM and I've never seen it in use, but it's also doable that we add the version as a part of the domain.

So instead of having a Coderbrad domain, I'm going to have the version in the name of the domain.

Okay. The truth, how do we choose the strategy? There is, there's a few things that factors that we need to think about. The first one is clarity. We need to make sure that everyone understand how the versioning is done. So the front end and backend developers, they agreed, and it's clear for them how we're going to structure the versioning and how the versioning is going to evolve.

Then the flexibility, it needs to be easy to add the new versions. We As an example, the query parameter, sorry the URI version where we have v1 slash customers and it's easy to manage, it's easy to update and then to add a new version. It's just simply by adding a new new keyword to the URL, then backward compatibility.

Does the approach that we are taking supports the background compatibility? The most wide, the most widely used approach where you have the version in the URI. It's backward compatible. We can maintain multiple versions. So we have v1, v2, v3, and we can maintain more than one version.

Sometimes it's tricky to maintain more than one version because of the because of the underlying backend services, but it's not the topic of today's talk and then simplicity. And the question is how simple it is actually to implement. It if you think about adding the pi variable, it's easy because it's just a part of our system.

If you think about changing the domains for the different versions, it might be more difficult because it usually relies on the infrastructure team to actually create a new domain, which might be more difficult. And how to deprecate the APIs. This is also a very important thing. So let's say that we have V1, V2, and as we go, we develop new things.

We had the V1, V2 website moved. to version two of the API. So then we say, the question is, can we deprecate v1 and remove the version one from the server? So it's not serving the data anymore. If you think about web, once web is fully moved to the new version, it's okay to deprecate the old version of the API.

But when you think about the mobile, it's all about the adoption of The new version of the app. So imagine that you install the new app. So you switch to the new version of the API, but you might have another customers which are still using the old version of the app. And if you don't have any mechanism to force the users to download the latest version.

You need to maintain the old version AP old version of your AP, as long as they are using that old version of the app and then how to trace it. We have a tools on the backend that let us measure. Which APIs are used, which are not used. And what is the percentage of the traffic that is coming to the given given version of the API.

Okay. And then API and Springs, there are various approaches, how we build the APIs together with we back end developers together together with with the front end guys. And Joanna already mentioned about it. How to combine the back end work with the front end work in the one sprint. So when you think about incremental APIs, there's a few approaches that I take, and then it depends on the team, right?

Joanna already mentioned about back end being one sprint ahead of front end. So we do the API. One sprint before the front and start works. It has its own drawbacks. For instance, there is some small change to the requirement that we need to where we need to adjust the API. Then the second approach that I usually take with my colleagues is that we define the APIs before we actually start and, or, and it works.

We started Sprint we sit down together for 15 minutes. We define the URLs that they're going to call, the methods they're going to call. We define the JSON model that we're going to exchange. And we both code backend and the frontend against the model that was defined together. And then the third way is mocking the API.

So there are tools where I can create a fake service that's going to serve a fake data to the API. Based on the API models that I agreed with the mobile with the front end guys. So they actually they actually code against the mock the data that that the fake service server is serving.

Yes. Do you have a dedicated event devoted to this API discussion and who should facilitate it? Okay. Yeah. I believe in the team spirit and this is how we do. Okay. So in our, like in various teams that I work with, we usually talk together. So we start the refinement. We start on the refinement.

We see, okay, this is going to need a discussion because we don't know how we're going to exchange the data. We, and we usually work in the corporation. So let's say that we work on the new screen. We see the screen we front and the backend, we know that we need. A, B, C, D on the screen and we jump on the discussion and we together try to identify and I'm going to get to this in a second.

Also, identify what are the resources that we will need to expose to the front end. That's gonna facilitate all the views that were defined by the business. And then we sit down together and try to define what are the endpoints and what are the data models that we can exchange. So I'm far away from having a backend developers looking only on the screens and UIs.

Defining the models because there is a valuable input from the front end developers who know all the transitions, how are we going to go through the screens. So it's easier for us to understand the flows and how to define the resources, URLs, and the potential issues that we're going to have. And then.

If it was on the other side, if it was only the front end guys defining the APIs, they might, may not understand the complexity on the backend that is needed because sometimes with the customer is super simple, but under the hood, I might need to call 20 servers and 20 systems to collect the data to actually expose simple first name and last name.

So there might be a bit more complexity than. We might, at the very beginning, we might think that it's going to be just one API that we need to call to, to populate the data for one screen. But as we go, we notice that it's actually three endpoints that we need to call. Okay. So we usually, after the refinement meeting, we usually have a 15 minutes call to, with where we try to identify like a brainstorm meeting where we try to identify what's going to be needed.

Of course, it's going to, usually it also evolves, right? So it's not, it's never rock and stone. It goes it also evolves during the sprint as we go. And we always try to update the models using the tools that can be, that allows us to share the models. across the team. Okay. So longer answer. I'm not sure if it's okay.

Okay, great. So planning and versioning incremental change is crucial from the team. And there's loads of challenges that you, that you might actually encounter while you work together with front end, back end and the business. And what are the main challenge that we have. The finding clear and this is going to be, these points they're gonna be related to what actually Oleg asked.

First of all, when you work on the APIs and the incremental APIs, the challenges that How clear are the requirements. So when we meet together with the front end and the backend developers, we need to clearly understand their user stories. We need to clearly understand what we want to achieve because.

The description of the story can affect the way we gonna plan our APIs. So we need to collaborate with the business to clearly understand what we want to achieve. Then the second point, which is challenging is the increment or is the incremental delivery. First of all, we want to have small changes and the business, they usually look at the software from the UI perspective.

So they see one screen where you just have a first name and last name, but under the hood, you might call 20 APIs because you need to authenticate the user. You need to load the data of the user. So we need to wisely think which IPIs needs to be delivered first and how we And how are we going to progress with the work so we do not stop front end from delivering the business value.

Then version and backward compatibility we mentioned about it. We need to sometimes skip the old version and we need to measure, we have to have a way to measure which versions of the API is used because it's not feasible to maintain 10 versions of the API. So what we like to do is usually graduate, deprecate the old version of the API.

The managing dependencies it's to Oleg's point, this is the coordination between teams where we have a Clear collaboration between front end and the back end that we discuss what is needed so we know that we can get to the point where we end the sprint and we delivered the value that was that can be presented to the business.

The fifth point are the NFRs. As the API evolves, it might get more and more traffic. So we need to be prepared to scale the APIs and prepare properly. test the APIs. The sixth is testing and automation. Usually when you want to present the API, there's nothing to present. Business is not interested to see the JSON, right?

And the endpoints. They usually see the UIs, but we need to also have a way to test our APIs. So the APIs are usually tested while you test the UIs, but we tend to also have a separate team Which is only responsible for testing the APIs and doing an automation over the APIs. The seventh point is the documentation.

So I mentioned that we meet together with the front end guys and we define the models. So once the models are defined, we try to document document the API and the data exchange. And we have tons of tools to do that to, which help, which helps us to do it. For instance there's Swagger, which helps us to describe the models.

Then managing technical depth as we evolve, as we introduce new version, you might have a technical depth that you need to work with. So there, there needs to be always a time. To step back, relax a bit and try to improve the things that we know that are a bit Shaggy, okay coordinating release cycles, creating new version of the APIs that are aligned with the customers.

And the releases must be synchronized with the new versions of API. So if there's a new version of the API, there are tools that can help us to enable and disable new version of the APIs and new functionality, such as feature flags. And the last thing is the changing requirements. So I said that we agree on the models at the very beginning of this print, but if something changes over.

And during the sprint, there are some new requirements that are coming. I do work. We have everything planned, but the reality is that things are changing even during the sprint, right? So we need to be prepared for the changes and the API needs to be done in the way that it's flexible. If we want to add.

new things to the API. Okay. And it took me a bit long but I really wanted to bring a bit of technical introduction. And this is my approach to the APIs and versioning of the APIs and the challenges I met over my 15 years long career. This is how I do with my friends in Ryla. Do you have any other questions?

Okay. So in the meantime, when we don't have questions, when we are waiting as the public warms up, I would have one question. So as a non technical person, you're looking from the scrum master perspective or Azure code perspective, you're coming to the team and the team is, the APIs are developed ahead and there is like strong belief that no, like we will never deliver anything within two or three weeks of a sprint if we'll be delivering API.

in time with other development. So what would be your starting point? What's your obviously we heard improve your refinement session, start collaborating together, put contracts in place, use mock mocking, services to, to speed up Nobel two to facilitate enabled that process, but what would be your starting point when you meet some resistance to working that way, what, where would you.

Would you think would be the starting point?

Oh, tough one because I, I got used to it. So I work actually right now with it on the functionality that we work together with the mobile teams. And the starting point. Yeah, like when you get to the time, I'm sure like, think about all times because, over the decade, like we know each other like around decade, but we work then.

But before then, like it's still many organization, you go somewhere and they work the old ways and they are like, no, we will never deliver everything. We cannot do that way. So what would be your advice? Where would be the, what would be the first step towards shifting to this way of working?

Maybe starting small, have you ever tried to actually get like a very basic functionality and try to encourage team to deliver that small maybe the problem with the back end developers that it's hard to talk to them and they're pretty stubborn and I used to be stubborn, right?

Saying, Oh no, you can't do it. But when you ask them if you ever tried to do it, they say no. And then they, like the problem I, the main problem that I encountered was that I'm going to ask in a different way. So when I proposed doing the model agreement the major problem I had was that it was usually myself speaking.

And defining the model because the guys were used to that. The back end guys were defining the model, but then what I encountered was that the back end guys were defining the model and then the front end guys were hacking the back end model because it was not a suit for purpose. So we, this is a good good from a starting point saying, Okay, you defined the APIs, but the APIs are not working as in the way they should be.

And then it might also be the case that even if your API Was done the sprint before it happens to you that approach needs a bit of rework in the next sprint because you forgot about ABCD. So maybe you want to try to sit down together with the front end developers and try to rethink the way you work and how I started.

And when we jump on the 15 minutes, a minute call, I ask everyone to switch on the camera. I'm going to be honest. I'm not a big fan of working remotely with all the cameras off. Because whenever your camera is off, you lose the identity. Then I usually start these meetings with only two backend developers and two front end developers that I know that are heavily involved in the project.

And then no, they know the business requirements. And then when you go through the APIs, I usually ask everyone to prepare the idea of the API before they joined the meeting. Then we all present the way how we see it. And then we try to get it to find the common way. Okay. But the major problem I noticed with the backend being one sprint ahead is that usually they need to do a bit of rework if they don't plan it properly.

Okay. They need to do a bit of rework the next spring because they missed some requirements or the requirements change a bit over the time. And then what I also noticed is that sometimes the backend is not prepared in the way that fronting expects it. So then fronting needs to be a bit of hacking, which is also bad, right?

Where the data needs should be actually exposed in the way that it's. easy to parse and process by the front and you shouldn't be doing any hacks. All the processing should be happening on the back end, but it's very tricky. Yeah, perfect. But basically, the basic advice for Scrum Master Raja coach is to, again, to back to the same thing, look at how you working, improve your backlog, refinement, collaboration, and think how to do it rather than why not.

And to move from there. Yeah. Did I summarize it correctly? Did I hear you correctly? Yeah. But have you ever do you have these problems? Do you have these problems? Where you see the stubborn and they want to go the old way, I would say, but it's, it goes against the Azure, and the scrub. So this is funny that we want to do the iterative changes, but then if the backend is one sprint, ahead, it means that we're not doing it because we're not delivering the full stack and to end solutions, right? Correct. Correct. And I'm going to, I'm going to, the last comment, I'm going to even, I'm going to even go further.

So in the team right now, we do the collaboration within the sprint, and we also have automation testers doing automation tests. just by knowing the contract I'm building. Okay. So they're even prepared. We are like even one step ahead that we're preparing the automation against the model that we proposed.

And then by the end of the sprint, it somehow works together. Yeah, because that's very interesting. We have literally two minutes, two minutes for this question, but I've noticed that on pro on challenge number six, you mentioned separate. team looking at automation of testing of those APIs. So how does it work if it's a separate team?

Like why it's not done within that team? Okay. So it's the wrong word. It's the person is within the scrum team, but you have the front end developers, you have the backend developers, and you have also testers, which are automated. Testers, which are, of course, they are part of the scrum team, but I said I would call it another speciality.

So the automation of the API is not done by the backend guys. It's done by the guys who are responsible mainly for automating APIs. Okay. So this is what I meant. Perfect. Thank you for clarifying. Okay. We are coming to the end magic shirt, the QR, if you want to share again, if you have any further questions, please feel free to contact him.

He's very, he's highly approachable. The last one here. Yeah. Yeah. It's going to take me a while. And thank you very much for spending that, that time with us. And thanks Maciek for sharing your knowledge with us. Again, that's been long time ago. We will work together, but it was always a pleasure.

So thank you very much for sharing what you know with us tonight. Thanks. If you have any questions, I'm always open to answer. There it is. You can find me. My name is Maciej Gowin. You can find me on LinkedIn. Any questions, I'm always open to answer any questions or share the knowledge, which is always good.

Especially if I have a chance to talk to the guys from other specialties, which is always challenging, but I love it. Thank you guys.