Irma Smajic

Uniting different skill sets, experiences, and perspectives through engineering collaboration is a process that brings complex challenges, but also can forge innovation through synergy if done correctly. Atlantbh had a chance to work on such a project where close day-to-day collaboration with an external development team was needed for successful delivery. In this case study, we'll explore how we collaborated to update the system's architecture, handle changes in technology and onboard to Elixir, and navigate the business landscape while nurturing a partnership built on adaptability and shared knowledge. The problem The client had been developing a backend system for a number of years, for which they realized that the initial architecture and application model were no longer suitable to their current needs. As the business was spreading, this implicated a rise in the number of end-users and different use cases which haven’t been foreseen and didn’t fit in the current architecture. To bypass system limitations, numerous temporary solutions needed to be implemented to address these gaps. Unfortunately, when the system outgrows its initial architecture and temporary solutions come into play for a longer period, at some point the development team finds itself fully consumed with fixing production issues that arise due to this very situation, as was the case with this particular project. Consequently, a decision has been made to rewrite the old backend system using a more appropriate tech stack and to create a flexible model capable of accommodating all use cases. In search of a partner, the client was looking for someone who would invest considerable time and expertise in analyzing the requirements, learning both the business and new technology, collaborating closely with the internal technical team, and successfully integrating into the existing ecosystem. Challenges During the initial weeks, we devoted time to gathering and analyzing requirements. Additionally, we have invested efforts in familiarizing ourselves with the legacy application, and the whole ecosystem into which our service would integrate, addressing technical challenges, and gaining an understanding of the client’s expectations. The team was faced with the following challenges: New technology stack - Elixir. The transition from Java (our usual choice of technology) to Elixir required learning and adapting to the new technology and frameworks. We did have expertise in Ruby which is a similar programming language, but not with the particular one. What also helped is the fact that our software engineers are full-stack engineers, and are used to adopting different technology stacks. Event-driven model approach. Adopting an event-driven model for software development introduced a paradigm shift in our development approach. It already helped that we had expertise in event-based communication, designing asynchronous workflows, etc. Complex ecosystem and business logic. Our software was part of a larger ecosystem, including multiple interconnected services that shared data and events. We did have experience in working with different teams in large ecosystems, but this one was quite different in size and complexity. We had to find the best collaboration model which would work for both teams, to understand dependencies and common practices.  Approach Our journey with Elixir The client offered assistance in knowledge transfer and onboarding to the new technology stack to address these challenges. We conducted knowledge transfer and pair programming sessions, sharing expertise and guiding us to avoid common pitfalls when starting with this stack. The team was grateful for such an opportunity, which leveraged our efforts later. We continued independently familiarizing ourselves with Elixir, and started the development of standalone features. Collaboration model The chosen collaboration model involved regular communication and coordination between the teams: Daily sync calls were conducted, with representatives from both teams sharing updates and discussing progress.  Weekly sync meetings between the product manager, technical lead, and our service lead helped align expectations and address any concerns.  Planning and breakdown sessions were organized as needed to ensure efficient project management and decision-making.  All parties were open to constructive feedback, which helped us overcome challenging situations and manage expectations. Development and delivery In collaboration with a product manager and technical lead, we defined the scope for the initial version of the product, ensuring it would provide immediate value to the users. Our team was responsible for the backend service which would replace a specific segment of the old system. As the business logic defined was unlikely to undergo significant changes in the future, we have agreed on the approach that involved implementing the defined functionalities one by one, in detail, incorporating comprehensive logic and thorough unit and integration testing. To document the system behavior, we adopted the Gherkin language which was already being used in the rest of the ecosystem, ensuring clarity and future stability. While this approach demanded more time for development and delivery upfront, the client was aware of the long-term benefits of investing in a solid foundation. As of now, our service has been successfully deployed in production, catering to a small user base. By diligently gathering feedback and continuously adapting to improve our service, we are moving on our way to transition to larger user groups. The feedback received thus far validated the stability and reliability of our core logic.  Conclusion Each new project presents its unique challenges, but a willingness to embrace new approaches and technologies brings significant advantages to software companies, broadening their horizons and knowledge base.  Throughout this endeavor, our team demonstrated key characteristics that played an essential role in a successful partnership with our client. Our expertise in software delivery, profound technical knowledge of design principles and software engineering, problem-solving skills, and readiness to embrace new methodologies and feedback were instrumental in achieving positive outcomes. Technology stack: Elixir, Phoenix, HTML, CSS, Rabbitmq, Gherkin Project duration: 1+ year

The Scrum Guide teaches us that a Product Owner is accountable for maximizing the product's value. However, how this is done in reality may vary widely across different organizations. In Atlantbh, a Product Owner is accountable for prioritizing the backlog to bring the highest value to the end customer as early as possible, but also for managing the team, client's expectations, and overall project success. This blog will focus on the segment of the product delivery process, which includes walking on a thin line between client and team contentment while making an effort to deliver valuable increments in time. Balancing these three defining properties of a successful project takes work, especially considering difficulties that will inevitably occur at some point. Here are only a few examples of the roadblocks we might face during the process: A team member or the majority of the team gets sick while we're preparing an important release of a product increment, A team member that was planned to play an important role in future activities is informing us that they are leaving the company, Sprint plan needs to change due to a production issue needing attention, An urgent change in priorities or requirements coming from the client a few days before release, Third-party service our product depends on just stops working at an essential time, etc. The sooner we accept that these situations are a normal part of our lives, the easier it becomes. What we can do is find a way to handle them in the best way possible. When problems happen, it's crucial to stay calm and focused. We need to remember that the team feels the energy we are spreading and wants to avoid causing additional chaos. Handling the problem we are facing is already enough. Ask yourself the question, "What is the worst-case scenario"? Maybe the impact is not that bad. Consider alternatives. Ideally, we will be able to overcome the situation by changing the scope and priorities in the sprint or moving the release date. Very often, this would work and is the way to go. Stay in control. Everyone will feel much better when we have the attitude that we are in control of the problems and capable of solving them. We acknowledge them, create a step-by-step plan for overcoming them and communicate all of this in the same manner. Although we cannot anticipate every problematic situation that might come our way, the good news is that there are things we can do to alleviate or avoid them altogether. In essence, we need to set things up right from the start. Building a Foundation We want to invest in the relationship between the client and the team in order to establish trust. The most straightforward way to gain trust is having the team understand the client's needs and relate to the product we are creating as much as possible. This leads to commitment and a sense of partnership. I have extracted important principles that can help build this foundation, relevant both for the client and the team. Defining the process It's essential to have a straightforward process of work and a collaboration model defined. Among other things, this can mean defining the methodology (e.g., Agile), frequency of releases, preferred communication channel, must-have documentation, amount of client involvement, demos, etc. Understanding the bigger picture If we understand the vision and priorities well enough, we will be able to: Bring constructive ideas and proposals in cooperation with the client, Better understand decisions, Organize the backlog, Convey the product vision to the team. We also want to keep the team in the loop with this information. Working in hybrid and remote mode makes this more difficult. We should work to keep the team informed, whether they are physically present or not. To passionately work on something, people usually need to understand the purpose. Great teams don't just do something because they have been told to; they want to work with a clear purpose and understanding of the end goal and the bigger picture. You want to be surrounded by people who challenge you and the client and always have the context behind some decisions. Expectations and risks management In order to have the client's trust and a happy team at the same time, we need to be able to manage expectations and risks well. Below you will find some tips that can help: Be aware of priorities, must-have items, and desired timelines. Define a clear goal you want to achieve in the coming period together with the client. Prepare a rough plan and revise it regularly. This will help define clear expectations. Be smart, and don't make too optimistic plans. Remember that problems happen, and they will happen, and consider that when doing the estimation. When planning, avoid having the team work in parallel on several extensive features because it is challenging to focus on all of them simultaneously (we are talking about the teams having standard scrum team size). Even though it would be obvious to always tackle top priority items, if you can tackle high priority items with some lower priority items, it would relieve some pressure and give the team some buffer in case of unexpected circumstances. Spread the knowledge in the team and try to be independent of one person. We all know the feeling when that one person goes on vacation or gets sick, and everything stops. To avoid this from happening, you need to work on empowering your team constantly. It implies taking more risks with people and project timelines, but it will pay off in the long run. Transparency We should be transparent and keep the client informed about current activities and problems when they happen. Even if we made a wrong estimation, introduced a bug in production, or delivered a wrong feature. As long as we analyze what happened, why and how we might avoid it in the future, and as long as we, as a team, figure out the next steps and a plan B, the client will most likely accept the circumstances. On the other hand, team members should be informed about good and bad decisions and have a sense of control over decisions that affect them. Feeling of accomplishment We should use every chance to celebrate milestones achieved in the team. It can be a big release launch, new members joining the team, small team building, etc. We should never forget how important it is to have this feeling of accomplishment. At that point, we look back to the work done and allow ourselves and the team to be proud of it. In addition to all of this, there are some things that we can do for our team in a role of PO, especially when planning the work: Try to find a way for our team members to work on the tasks interesting for them, following their personal growth, Trust them when they are ready to take on larger responsibilities, Take care of the load put on the team and make sure that the team is not constantly working under pressure, Value the team's opinion when planning the work, Protect the team from noise and unnecessary information. Summary When starting to work as a Product Owner, it takes some time to see the results of your work because they are not easily visible at first. If you ever asked yourself what your contribution is, please remember that if you create products that bring value to your customers and make both the client and the team happy while allowing your team members to grow, you're doing great! (more…)