Author: Ben Linders

Copying and pasting code from one Windows folder to another as a deployment method can cause downtime. Jemma Hussein Allen presented how they automated their deployments and the benefits that they got from it at QCon London.

The main challenges with manual deployments of application and infrastructure code were due to environmental inconsistencies that happened due to a range of factors, of which the main one was aligning code deployment with deployments of dependent resources such as databases, Hussein Allen said. Before options such as blue/green deployment became available, changes that were not backward compatible meant brief periods where the database schema and code were out of sync and caused failed requests during deployments, she added.

Hussein Allen mentioned that general human error also plays its part, where certain file updates are missed, or incorrect versions are copied to the new environment. Human error can also be a big factor in testing if there are no mandated safety checks and local testing is the responsibility of individual developers:

Process automation helps to remove the human error component, and with intelligent deployment mechanisms, checks such as file share latency can be checked before deployments to ensure downtime isn’t an issue.

Manual deployment involving file shares can also be a big issue if the timing of file copies is out of sync, as it can result in incomplete deployments, Hussein Allen said. Updates to dependent resources can also be codified and synchronised to ensure changes are deployed in the correct order, she suggested:

These days, with deployment automation and blue/green deployments, new versions can be deployed and tested in a production environment before being made available to end users.

The first stage for automation was to document each deployment step, no matter how small, Hussein Allen said. Some key considerations were whether the step was manual or already automated, any downstream or upstream dependencies on other resources, and any access configuration, permissions, or secrets needed to carry out the step. This gave them a good overview of the current deployment method and highlighted any steps that would take a large amount of work to automate, she mentioned.

After they had a good understanding of the process, they looked into existing available tools to assess their suitability. They also looked at the existing deployment tools in use in the organisation to determine if these would be suitable, as people who were already experienced with the tool are really valuable:

Unfortunately, none of the existing tools were suitable for this type of workload, so we carried out a wider search to assess the suitability of other tools, taking into account support for the workload type and how they integrated with the existing company tooling.

Once the assessment stage was complete, they started to implement a proof of concept in the development environment.

We started with a small part of the application, and once we had successfully set things up in development for a specific application segment, we moved that deployment process to the staging environment.

As staging had slightly more policy constraints than development, testing in this environment was important, Hussein Allen mentioned.

After the proof of concept had been implemented, they then assessed how the solution could be rolled out to other application segments and environments with minimal disruption.

The main benefit from automating deployments is a quicker and cleaner release process, especially when working collaboratively in a team, Hussein Allen said. Centralised change logs and deployment trackers also provide much better deployment visibility across teams, she added.

Hussein Allen mentioned that standardisation of deployment steps can improve familiarity and understanding of a paved road and the components needed to test and deploy quality applications. The CNCF defines a “golden path” as the “Templated compositions of well-integrated code and capabilities for rapid project development“. The paved road / paved path / golden path approach has become more popular with larger organisations as it is a proven method to speed up developer adoption of standardised company processes and tooling, as Hussein Allen explained:

I have seen the adoption of well-crafted templates by development teams majorly increase the speed of utilising company-specific tooling and logic in applications.

Automation will almost always save time and effort in the long run, even if it takes slightly more effort initially, Hussein Allen concluded.

Resolving impediments to flow and removing unnecessary sources of cognitive load can make culture issues disappear in organisations, Nigel Kersten argued. Start with a clear strategy that is easy to communicate, then follow the path to creating stream-aligned teams and platform teams, he suggested.

Nigel Kersten spoke about enabling fast flow in software organizations at FlowCon France 2024.

For a long time, DevOps was useful just to make it clear that you wanted to change the traditional relationship between the teams that built software, and the teams that were responsible for maintaining and running that software, and that you wanted to implement more sophisticated automation, however Kersten says he doesn’t believe that’s the case anymore.

He advised not to focus on “fostering culture” or “fostering DevOps” as a primary goal. Instead, focus on improving fast flow and low cognitive load for your teams involved in software delivery. As you resolve impediments to flow and unnecessary sources of cognitive load, then the “cultural” issues will start to disappear, he argued:

Delivery will become increasingly more predictable, friction between teams will be reduced, and teams will have more time to invest in new skills, automating processes, and implementing self-service interfaces, all of which will continue to free up more time to create an environment of continuous improvement.

Technological improvements like containers, VMs, infrastructure-as-code, software-defined-networking, collaborative version control, and CI/CD can make it possible to fix cultural issues around organisational dynamics and bad product delivery, as Kersten explained in how technology can drive culture change in software organisations.

One of the primary drivers of the early DevOps movement was a complete lack of alignment between the people who built software, and the people who were responsible for running it in production, so we all spent a lot of time focusing on ways to increase collaboration in order to improve software delivery, Kersten said. This was great, but over time collaboration itself started to become the goal, and that’s just not a productive way to run a software organisation, he added.

Kersten referred to Team Topologies and the increased emphasis on platform engineering that we’ve seen emerge over the last few years, which both recognise that collaborative interactions are not universally appropriate:

Collaboration between functions like development and security is great at the design phase for a new product, but the goal should be to move towards X-as-a-service interactions and minimise collaboration over time.

Before you start hunting around for an internal developer platform solution, or reorganising people into stream-aligned teams, make sure that you have a clearly defined strategy that is easy to communicate, Kersten explained:

First, this is more important to get right than your organisation structure and platform team adoption, and secondly, it’s necessary in order to define the right value streams, decide whether you should have a platform team, and define the high-level goals for success.

Kersten referred to the book Good Strategy, Bad Strategy and the model used to define a strategy: a diagnosis of the situation, some guiding principles for addressing the situation, and a set of concrete actions. Strategy without an action plan is just a vision statement, he said.

If you’ve got your strategy and actions in place, then the path to creating stream-aligned teams and platform teams will be reasonably obvious, Kersten concluded. He suggested focusing on creating and amplifying feedback loops, both internal, and external:

Ask yourself: are your developers able to experiment quickly, and share those experiments easily with colleagues and stakeholders? Are your stream-aligned teams aware of upcoming changes to the platform itself? Does your platform team treat their stream-aligned teams as customers? Do they do product discovery and user research to guide their roadmap?

If the answer to these questions is no, then focus on removing whatever barriers are in the way of a fast feedback loop and user outcome-driven culture, Kersten concluded.

According to Benjamin Bischoff, developers find new tools much more interesting than old ones, as they offer an opportunity to learn new technologies and approaches and to expand their tool belt. Using tools that have been around for decades, however, can save time and budget. When evaluating tools, it is more important to understand the problem to be solved than to jump straight into the tools.

Benjamin Bischoff will give a talk about the value of using timeless testing tools at QA Challenge Accepted. This conference will take place on September 28 in Sofia, Bulgaria.

In his talk, he will discuss biases that play a role when favouring a new tool:

For example, there is the “sunk cost fallacy”. This means that you are tempted to use a new tool if you have invested a lot of time and money. This can be training time as well as budget spent on the tool itself or learning materials. It can therefore happen that you close your eyes to the disadvantages of a tool and use it against your better judgement.

According to Bischoff, familiarity is the main reason for using tools that have been around for decades. If the tools are already familiar, their use can save a lot of training time and budget, and also help to achieve goals more quickly. Also, there is a deeper understanding of the potential issues with these tools, which is not the case with new tools:

New tools may suddenly show limitations when they are run in production, which can lead to considerable additional work.

To find suitable tools, Bischoff suggests gathering thorough information and creating proofs of concept to find out which tool is ideal in which situation:

When we were looking for a tool for our API tests, we created and compared three different proofs of concept with different tools. My position at the time was that I was not a fan of the Karate framework. In the end, however, I was convinced by how quickly we achieved a good result with this framework. Looking back, this was simply a prejudice on my part because I simply didn’t have enough knowledge about this tool. That changed during the proof of concept phase.

According to Bischoff, it’s helpful to always bring a healthy dose of scepticism with you and not get carried away by the flashy and shiny hypes. In the end, it’s not about using certain things at the drop of a hat, but rather analysing more precisely what you need and how you can get the most out of technology.

InfoQ interviewed Benjamin Bischoff about testing challenges and using tools to address them and asked him about his experience with AI tools.

InfoQ: What main testing challenges have you faced?

Benjamin Bischoff: I have already had several different testing challenges, specifically technical challenges in the sense of “How can we map this requirement as tests?” and “What technical options are there for this type of test?” Of course, this also includes tools.

For example, we needed a tool that would simplify the testing of APIs for us. The Karate framework proved its worth for us here, as it has a simple syntax, but is very flexible thanks to its extension options. For UI-based end-to-end tests, Selenium fulfilled our criteria as a remote browser control. It was important that both desktop and mobile platforms could be operated and that features such as websites with multiple tabs and windows worked. We also wanted a solution that would accurately simulate users from the outside and not run in the browser like many other solutions.

On the other hand, there have also been challenges due to prejudices against certain roles, e.g. test automation engineers or QA engineers and their goals and intentions. But these problems have disappeared with time and experience.

InfoQ: What tools do you use to address these challenges, and how do you use them?

Bischoff: In our UI-based end-to-end test strategy, we mainly use our in-house Selenium test framework. For me, this technology still has many advantages over the hyped new tools, mainly that it uses the W3C webdriver standard so that all browsers are supported out-of-the-box. It does not need any custom browser versions or has to run within the Javascript context. That means that it behaves like a real user – and that’s what we want.

We also use Bash and Make in the CI/CD context, for example. We have a lot of experience with this and can achieve our goals quickly.

Of course, we also regularly look at new technologies and approaches and consider whether and how we can integrate them into our test strategy. For example, in terms of test frameworks, we have also evaluated Playwright and Cypress, but in the end decided against them due to the reasons mentioned before. However, if we find interesting tools in the future, we have no qualms about replacing existing solutions with them. However, these must offer considerable added value that outweighs the resources invested.

InfoQ: What have you experienced using AI tools?

Bischoff: I use AI tools on a daily basis, both professionally and privately. For development and automation, I often use Github Copilot, Google Gemini and ChatGPT. If you already have experience in a certain area, these tools can be really helpful. But you need to know exactly what you need and how to express it. More importantly, you need to know when a proposed solution doesn’t make sense or might be hallucinated, and express this in a follow-up prompt.

Gradually, you will get more and more useful ideas and solutions from AI tools the more you give feedback. I always say that you have to treat AI tools like advanced rubber ducks.

According to Benjamin Bischoff, developers find new tools much more interesting than old ones, as they offer an opportunity to learn new technologies and approaches and to expand their tool belt. Using tools that have been around for decades, however, can save time and budget. When evaluating tools, it is more important to understand the problem to be solved than to jump straight into the tools.

Benjamin Bischoff will give a talk about the value of using timeless testing tools at QA Challenge Accepted. This conference will take place on September 28 in Sofia, Bulgaria.

In his talk, he will discuss biases that play a role when favouring a new tool:

For example, there is the “sunk cost fallacy”. This means that you are tempted to use a new tool if you have invested a lot of time and money. This can be training time as well as budget spent on the tool itself or learning materials. It can therefore happen that you close your eyes to the disadvantages of a tool and use it against your better judgement.

According to Bischoff, familiarity is the main reason for using tools that have been around for decades. If the tools are already familiar, their use can save a lot of training time and budget, and also help to achieve goals more quickly. Also, there is a deeper understanding of the potential issues with these tools, which is not the case with new tools:

New tools may suddenly show limitations when they are run in production, which can lead to considerable additional work.

To find suitable tools, Bischoff suggests gathering thorough information and creating proofs of concept to find out which tool is ideal in which situation:

When we were looking for a tool for our API tests, we created and compared three different proofs of concept with different tools. My position at the time was that I was not a fan of the Karate framework. In the end, however, I was convinced by how quickly we achieved a good result with this framework. Looking back, this was simply a prejudice on my part because I simply didn’t have enough knowledge about this tool. That changed during the proof of concept phase.

According to Bischoff, it’s helpful to always bring a healthy dose of scepticism with you and not get carried away by the flashy and shiny hypes. In the end, it’s not about using certain things at the drop of a hat, but rather analysing more precisely what you need and how you can get the most out of technology.

InfoQ interviewed Benjamin Bischoff about testing challenges and using tools to address them and asked him about his experience with AI tools.

InfoQ: What main testing challenges have you faced?

Benjamin Bischoff: I have already had several different testing challenges, specifically technical challenges in the sense of “How can we map this requirement as tests?” and “What technical options are there for this type of test?” Of course, this also includes tools.

For example, we needed a tool that would simplify the testing of APIs for us. The Karate framework proved its worth for us here, as it has a simple syntax, but is very flexible thanks to its extension options. For UI-based end-to-end tests, Selenium fulfilled our criteria as a remote browser control. It was important that both desktop and mobile platforms could be operated and that features such as websites with multiple tabs and windows worked. We also wanted a solution that would accurately simulate users from the outside and not run in the browser like many other solutions.

On the other hand, there have also been challenges due to prejudices against certain roles, e.g. test automation engineers or QA engineers and their goals and intentions. But these problems have disappeared with time and experience.

InfoQ: What tools do you use to address these challenges, and how do you use them?

Bischoff: In our UI-based end-to-end test strategy, we mainly use our in-house Selenium test framework. For me, this technology still has many advantages over the hyped new tools, mainly that it uses the W3C webdriver standard so that all browsers are supported out-of-the-box. It does not need any custom browser versions or has to run within the Javascript context. That means that it behaves like a real user – and that’s what we want.

We also use Bash and Make in the CI/CD context, for example. We have a lot of experience with this and can achieve our goals quickly.

Of course, we also regularly look at new technologies and approaches and consider whether and how we can integrate them into our test strategy. For example, in terms of test frameworks, we have also evaluated Playwright and Cypress, but in the end decided against them due to the reasons mentioned before. However, if we find interesting tools in the future, we have no qualms about replacing existing solutions with them. However, these must offer considerable added value that outweighs the resources invested.

InfoQ: What have you experienced using AI tools?

Bischoff: I use AI tools on a daily basis, both professionally and privately. For development and automation, I often use Github Copilot, Google Gemini and ChatGPT. If you already have experience in a certain area, these tools can be really helpful. But you need to know exactly what you need and how to express it. More importantly, you need to know when a proposed solution doesn’t make sense or might be hallucinated, and express this in a follow-up prompt.

Gradually, you will get more and more useful ideas and solutions from AI tools the more you give feedback. I always say that you have to treat AI tools like advanced rubber ducks.

According to Eb Ikonne, leaders should provide a motivating challenge or mission so that the software engineering team understands what success looks like. They can provide an enabling structure for effective teamwork, address things that negatively impact team success, and reduce or remove friction. Coaching can help people discover how to work effectively together.

At QCon London Eb Ikonne spoke about fostering high-performing work environments for software development.

In his talk, Ikonne referred to the five conditions outlined in J Richard Hackman’s book Leading Teams: Setting the Stage for Great Performances:

• The team must be a real team, rather than a team in name only
• A compelling direction for its work
• An enabling structure that facilitates teamwork
• The team operates within a supportive organizational context
• The team has expert teamwork coaching

The word “team” is often used pretty casually in the work setting, often to create a sense of camaraderie between people who have to collaborate in some form or fashion, Ikonne said. As a leader, you want to clarify who is on (and not on) the software engineering team. Everyone must know the people who might help the team occasionally but are not team members. This clarity is vital, he stated.

Ikonne mentioned that leaders must provide a motivating challenge or mission for the team. The software engineering team should understand what success looks like and what they need to do to achieve it:

As the leader, you need to express why the work matters. The direction serves as an enabling constraint for the team to choose between options on how they will go about doing their work.

Every person, in their role, e.g., architect, software engineer, etc, needs to understand how their work contributes to the whole, Ikonne said.

An enabling structure that facilitates teamwork is an important condition for effective teams that leaders often take for granted, Ikonne argued. You want to ensure the team has the right number of architects, software engineers, team leads, etc required to deliver software successfully.

Ikonne said that the broader organization (unknowingly) prevents teams from succeeding by implementing policies and practices that introduce unhealthy friction. We need to address factors that negatively impact team success and reduce or remove friction.

The supportive context needs to reinforce the importance of teams. However, rewards, incentives, and recognition often encourage a focus on individual interests over the interests of the collective, Ikonne explained:

As a leader, I need to ensure we have the right focus. It takes very little to encourage “hero coder” behavior on a team, which is something team leaders should work to avoid.

Ikonne mentioned that the team leader must provide the software engineering team with coaching or engage third-party professionals to help the team develop its technical and social skills. It’s often taken for granted that people will know how to work well together when this isn’t necessarily the case. The coaching required when forming a team will differ from coaching when the team has worked together for some time or when the team reflects on its work processes. As a leader, I’ve had to recognize and adapt the coaching needed to match the situation, Ikonne said.

As a leader, you must continually focus on and work on these conditions. Conditions will not always be perfect; however, you can only improve these essential conditions by working on them and improving them. That is part of leading teams, Ikonne concluded.

Public software platforms should be inclusive and accessible to everyone, where people feel comfortable using them. Aleksandra Osińska and Natalia Sidor gave a talk about crafting public platforms at ACE Conference.

It’s a big challenge to design a platform for everyone, from digital newbies to natives, with varying knowledge and experience of administrative processes, Osińska said. Users can have diverse needs and life situations, for example, a teenager applying for their first ID has different needs than someone doing it for the second or third time.

We should understand that while we can design anything we want and the wireframes can handle our ideas, the actual government platforms cannot. We must explore what’s possible, Sidor said. She mentioned data connection as an example:

Depending on the country’s government system, connecting data from different platforms may be easier or more complex, which affects design and development.

Osińska suggested providing services categorisation by life events with easy navigation. When designing government platforms, we should focus on a content-first approach, hence designing them as an open knowledge hub is crucial, she added.

Government platforms must ensure their users’ trust so that they feel safe using government services online, Osińska stated. More and more public platforms offer a convenient single sign-in. At the same time, they enforce multi-step verification during the logging-in process, such as confirming the user identity through a bank application, SMS, or email.

In terms of public platforms, inclusive design means ensuring everyone feels comfortable using them. The interface should adapt to accommodate all users, regardless of their circumstances, Sidor mentioned.

Accessibility is important for everyone, not only people with disabilities, Sidor said. Everyone benefits from fully accessible products:

For example, we can all experience temporary difficulties, such as a broken arm, conjunctivitis, or simply entering a website on our phone in a crowded bus with our other hand busy. Accessible products mean that all of us can use them, regardless of the situation we find ourselves in.

When creating a public platform, Sidor advised prioritising simple design and interface. There’s no such thing as making the interface too easy, she said; everything should be well-explained and easy to access.

InfoQ interviewed Aleksandra Osińska and Natalia Sidor about designing inclusive platforms.

InfoQ: What can be done to create an inclusive online experience?

Aleksandra Osińska: An inclusive platform should encourage users to find information about services and perform the necessary actions online. You can use a life-event-centric approach to address different needs and situations. Aside from standard categories (e.g. service names), we should also have categories that correspond to life events, like getting married or looking for a job. This way, we meet everyone’s needs, even those who do not know legal or administrative procedures.

Natalia Sidor: For example, when creating a form, we must consider various life situations, e.g., including the possibility of selecting a gender identity in our forms. There are also local and foreign users who have different experiences and legal documentation. We can’t exclude people who, for example, don’t have a PESEL number (an identification number in Poland). Instead, we must address their situation, explain what they can do, and provide alternative identification methods.

InfoQ: What’s your advice for increasing accessibility?

Osińska: I’d advise everyone to test and validate designs and flows with users who have diverse needs to see whether they can easily find needed information and complete a required process successfully. This is the best way to ensure our platform is accessible and user-friendly.

If possible, we should test the product on ourselves, using various methods known to people with disabilities. If we want to test whether a product is accessible to visually impaired people, let’s test it with a screen reader and see if we can use it. This approach validates the designs and empowers us to better cater to the users’ needs.

Sidor: Certain rules ensure a great user experience: appropriate contrast, font sizes, and responsive design elements. But we shouldn’t simply follow the rules; we must empathise with our users and consider their different needs. Accessibility should come first and visual aspects second.

To manage their increased workload effectively and maintain quality and efficiency, a software team decided to become dual-purpose: stream-aligned and platform. They rewrote their main application to be API-first and implemented micro releases with their customer-facing products, to provide value to their end users quickly and maintain a steady flow of accomplishments for the team. Marion Løken spoke about the changes that her software team went through at NDC Oslo.

The mobility market is under significant pressure due to economic downturns and environmental concerns; people buy fewer cars and change less often, Løken said. Schibsted marketplaces across several countries merged:

My team transitioned from selling insights to 1,000 car dealers in Norway to delivering insights to 600,000 monthly users -both private and professional buyers and sellers- and expanding to 1.5 million users in the Nordics, with new revenue streams through third-party integrations.

They used the jobs to be done (JTBD) framework to develop more specialized products for car dealers and evolve into a platform team:

We went from a generic JTBD like “help me sell my product” to more specific ones like “help me sell or buy a car,” “help me sell my car to a professional,” or “help me evaluate a car pool for compliance with financial regulations”. JBTD helps you reframe your team role effectively.

Løken explained that decision support is crucial throughout the user journey, from understanding the market, setting the sale price and choosing where to advertise, to optimizing the marketing budget. Those user journeys are owned by different teams with different products, however, the insights should be calculated and presented in a recognizable way to the end users:

Numbers and statistics can be challenging to interpret, and adding unnecessary complexity by changing the visualization can create doubt and confusion for users.

They transformed into a dual-purpose team: a stream-aligned team, serving their own users, and a platform team, supporting other internal teams:

We are only a small team with four developers; our deep understanding of what our end users want enables us to save other teams time and effort by building solutions that benefit both us and them.

They rewrote their main application to be API-first and used a component library, simplifying their architecture. The API-first shift allowed them to consolidate their services into a single API with access control, eliminating task duplication and significantly improving efficiency. The component library for the front-end also aids their setup, enabling them to reuse the same design across products and user journeys, Løken mentioned.

They leveraged generative AI to enhance productivity and get inspiration for improving the software architecture:

When creating a new invoicing system, we utilized ChatGPT to generate mermaid diagrams that could be directly integrated into GitHub, ensuring clarity in our system design and adherence to SOLID principles.

Software engineers use AI tools like Copilot for coding tasks, which enhances their efficiency, Løken said.

InfoQ interviewed Marion Løken about the changes in her team.

InfoQ: What was your approach for setting up teams to provide decision support products?

Marion Løken: To enhance the cohesion of our decision support products, we identified the need to work smarter and integrate our data products centrally. Delivering data products directly to the end users was not enough; we also needed to provide these products to our internal teams to ensure a seamless experience for our end users.

Additionally, we receive feedback on their products that helps us improve our products across the board. However, we are still too small to fully focus on customizing for the needs of our internal users, the teams we support.

InfoQ: How did you benefit from generative AI tools?

Løken: There’s a definite opportunity to accomplish tasks faster with generative AI when you have a clear understanding of what you want to achieve, what the solution should look like, and the best practices you want to adhere to. With the help of AI, we managed to deliver what the organization needed more effectively.

InfoQ: How do you do micro releases and what benefits does that bring?

Løken: Big bang releases are a thing of the past, and micro releases help boost team morale. Smaller milestones give everyone a sense of progress and achievement.

For example, we planned to deliver five key insight cards in a rotating display. Instead of waiting until all the insights were ready, we decided to go live as soon as one was complete and inform our customers that more were on the way.

As the team manager, I used these opportunities to celebrate with small gestures, like buying treats or sharing “breaking news” in the company channel. These frequent celebrations helped maintain high spirits and reinforced the incredible job the team was doing. I’m glad we didn’t wait for everything to be finished to recognize our progress.

In healthy software teams, people feel psychologically safe to solve problems and contribute, Brittany Woods said in her talk at QCon London. She presented how they do team health checks and the benefits that it has brought them.

The biggest indicator that a team is healthy is the psychological safety of those within the team, Woods said. If not every member is feeling safe within the team to contribute or voice their opinions, it’s not possible for the team to be healthy, she added.

Woods mentioned that this is particularly important in teams where there are mixed skill sets or varied experience levels. In both cases, there is an unwritten power dynamic, so ensuring your team remains a healthy and collaborative team where all members feel safe to solve problems and contribute is very important.

Team health checks are a great way to check in with your software team and get a pulse on how things are going from their perspective, Woods argued:

In my current role, we work with our agile coaches for these health checks, aiming to do them once a quarter.

Woods mentioned that during the health checks, there is time for the team to share things that they believe to be opportunities for improvement along with ideas they may have to solve any identified issues. Their agile coaches facilitate these sessions, making them fun and engaging for the team.

They typically last two hours and they aim for an in-person session, Woods mentioned. Should they do a remote session, they try to ensure all members of the team are remote for a consistent experience across the team.

A typical format would include the following:

• Before the session, they used a survey tool that showed the historical trends and aggregated trends on team health measures, like feeling able to experiment, feeling supported, enjoying the work, feeling trusted, etc. This gave them a baseline of how the team is feeling about the work they are doing. They do this for each health check so they can see if scores are improving or declining.
• At the start of the session, they do an icebreaker to get the team engaged – this can be a game, a fun icebreaker question, or for in-person experiences, they often do the LEGO duck building exercise. This consists of taking 6 bricks and in 60 seconds building a duck. It’s always exciting to see how different people interpret the duck differently.
• The Introduction – the agile coach or facilitator sets the stage for what the session will look like. As an aside, having someone external to the team facilitate the session is important to ensuring a safe and unbiased environment for the team. This also allows the engineering leader to participate as a member of the team.
• The format of the sessions can vary depending on the exercises that would be most valuable for where the team stands in their feedback.

Team effectiveness is very influenced by the overall health of a team, Woods said. From the team environment to quality measures and metrics, team health can either hinder your team’s ability to deliver on their commitments – software or otherwise – or help it, she concluded.

InfoQ interviewed Brittany Woods about doing team health checks.

InfoQ: How does the format of your team health checks look?

Brittany Woods: In our most recent session, we did the following:

• Walk through the survey report, pointing out areas where scores had changed from the previous survey. There was also some unstructured time planned in which each member of the team could review/reflect on the results and put in some sticky notes of their thoughts. We use Miro to collaborate and put in stickies. We then broke out into smaller sub groups and discussed what patterns we found in the data.
• After discussing the survey, we moved into a lean coffee session. Each member came up with topics that they thought would be good to discuss and we voted on those that the majority felt important to spend time on.
• Next, we did an exercise to give ideas on what a good first thing to solve would be when thinking about the feedback in the survey and how the team could improve.

These activities could look different depending on what things are valuable for your team at that point in time.

InfoQ: What have you learned about team effectiveness?

Woods: I’ve learned that to help be a driver of effectiveness, it’s important to foster safe and inclusive environments where there is space to learn, share, and grow.

When every member of the team is able to learn, share, and grow, your team is, in my opinion, at peak effectiveness and in a headspace where they can deliver their best quality work in the best environment possible for them. At that stage, the real challenge begins of continuously ensuring that the team is able to stay in that space.

As leaders, we have to constantly be engaged in building a safe and collaborative environment for our teams.

Platform engineering is about accelerating and empowering developers to deliver more product value faster over time. According to Jessica Andersson, most companies don’t invest in platform engineering until they reach a certain size. At QCon London she presented how their startup adopted platform engineering, what strategy they took, and what they have done to gain platform adoption from developers.

Andersson mentioned that they launched their platform engineering team when the company was two years old and already had software running in production. As soon as you have software in production, you have an implicit platform, regardless if you know it or not, she said. This implicit platform is built in bits and pieces to solve whatever need the teams have at the moment and once it works well enough, whoever built it goes back to building the product, she added.

Starting out with platform engineering they first identified their implicit platform and then started to turn it into an intentional platform:

Basically we took existing things and streamlined, upgraded, and secured them. It’s important here to acknowledge that the implicit platform was built with the best knowledge available at the time and to remember that this was not the main focus for those building it.

It’s important to avoid replacing all tools just because they would not have been your first choice; replace the ones that are insecure or hinder your platform, Andersson said.

The main goal of the platform engineering team is to increase the ability to deliver product value, Andersson said. You can do this through removing bottlenecks and reducing pain points and time sinks:

Some indicators we look for in order to identify where we need to spend more effort are:

• Teams are blocked from performing tasks
• The tasks teams perform take long time
• The tasks teams perform are unreliable and prone to failures

There are always trade offs you need to make; being a small team we definitely can’t take on everything, Andersson said, but we aim to solve the most common and urgent needs.

Treating your platform as a product means building it like you would any other software product. The platform has users, problems that it solves, and a lifespan throughout which you need to take care of both the software and your users, as Andersson explained:

I often see platform teams forgetting about the users when it comes to migrations or switching to new tools, and they deprecate the old thing without providing a seamless transition to the new thing.

Andersson mentioned that you need to keep a focus on what your product is. Working with a product manager in the team is important to maintain that focus:

I try to focus a lot on solving the right problems as well. As a platform engineering team in a cloud native environment there are infinitely interesting problems you can work on; the question is whether you should. So finding out what are the right problems for your organisation and your users is important in order to spend time on those problems.

Platform engineering aims to improve the developer’s experience, Andersson said. Internal developer platforms can help you build a good foundation for good developer experience, helping your teams focus on building excellent products, she concluded.

InfoQ interviewed Jessica Andersson about platform adoption and building trust.

InfoQ: What have you done to gain platform adoption from developers?

Jessica Andersson: Some activities we’ve seen that build trust and thus encourage adoption from our teams are:

• Remove pain points – we show our teams that we care about them and can improve their experience
• Be approachable and helpful – people more likely to reach out to us again, spreading the word to their teammates
• Be proactive – while being approachable we might hear about pain points the teams don’t realise we can solve for them, if we fix it we will gain more trust
• Understand the teams’ perspective – if we understand where they come from, what they know and not, then we can communicate in the same language and better understand their pain points

InfoQ: What role does trust play in supporting a platform?

Andersson: Trust is important as everything builds on it. Adoptions, information, communication: it all comes back to trust.

I believe that as a platform team it’s very important to build a high level of trust with the product teams as it will determine how successful your platform will be.

A challenge that companies often face when exploiting their data in data warehouses or data lakes is that ownership of analytical data is weak or non-existent, and quality can suffer as a result. A data mesh is an organizational paradigm shift in how companies create value from data where responsibilities go back into the hands of producers and consumers.

Matthias Patzak gave a talk about data mesh platforms at FlowCon France.

One of the biggest challenges that companies face when they want to exploit their data and become data-driven is the quality of the data they collect, as Patzak explained:

Have you ever heard the phrase “data is the new oil”? In the late 2000s, it was argued that all data should be stored because it is a valuable resource. But who trusts a 5-year-old S3 bucket when you don’t really know who stored what data and why?

Patzak argued that data is more like wine. Some data, like wine, must be consumed quickly or it will go bad. Other data, if stored and handled properly, can age very well and even increase in value and quality with age, he said.

The fundamental problem, Patzak mentioned, is that ownership of analytical data is often weak or non-existent, and quality suffers as a result. Analytical data is generated by transactional systems. However, the people who know and own these systems and the underlying processes are not responsible for the analytical application of their data, Patzak said. It is typically extracted, transformed, loaded into data warehouses or data lakes, and made available for use by a centralized, highly specialized department. These specialists often don’t have a real sense of ownership, either, he added.

A data mesh is a distributed data infrastructure that puts the responsibility for using and creating value from data back in the hands of the producers and consumers of that data, Patzak said. It eliminates the specialized data organization as a proxy and bottleneck in the communication between producers and consumers. At the heart of this distributed data infrastructure are data products that create tangible business value in their own right.

To build a data mesh, you’d create a domain-oriented architecture in which each business unit manages its data as a product, using a self-service infrastructure and tools for cataloging, sharing, and governance, as Patzak explained:

This self-service infrastructure is built by a data mesh platform and includes cloud services, data orchestration tools, and CI/CD pipelines, supported by federated governance policies for security and quality, and observability systems for monitoring.

Patzak mentioned that access is controlled by robust security mechanisms, and the entire data infrastructure is automated and maintained through Infrastructure as Code practices. Crucially, domain teams are equipped with the necessary skills through targeted enablement and training programs provided by the platform teams, ensuring that the technical setup facilitates a culture of autonomy, quality and collaboration, he added.

The benefits of a data mesh are faster implementation times and less cognitive load for producers and consumers, consistent tools, and standards for the company, Patzak concluded.

InfoQ interviewed Matthias Patzak about creating a data mesh platform.

InfoQ: What’s needed to create a data mesh platform and what benefits does a platform bring?

Matthias Patzak: From a technical point of view, everything is available to build the core services of a data mesh platform. This is just busy work. As with any platform, the challenge lies in ensuring that the platform services are accepted and used by the users. This is achieved by letting the platform users prioritize the platform backlog and by involving developers from the user teams in the development of platform services by means of job rotation.

InfoQ: What’s your advice to organizations that want to exploit their data using a data mesh?

Patzak: Don’t boil the ocean! Start small with a specific use case and pair of open minded producers and consumers and leverage the decentralised approach of data mesh. Even start before you are ready and become ready by starting. Finally, develop the platform in parallel with specific use cases.