Esena Gušić

Product specification As a Product Owner or a similar role that is essentially the interface between the client and the engineering team, you'll often find yourself trying to compromise between one and the other. Challenging situations may happen during all phases of product development, including product specification and product delivery. I will focus on the product specification phase and offer advice based on my experience on how some of those situations could be prevented or handled. What is essential to have the right product? To understand our goal when defining product (features) specifications, we need to set grounds for what we are trying to build. On a high level, there are three main aspects of a successful software product: It must solve a particular problem or bring value to the users It must be easy to use It must be delivered at the right time Everyone who has had experience as a Product Owner knows that in addition to these three main aspects, there is a vast complexity of qualities to consider when building a software product. There are numerous ways to determine the characteristics of good software, but I find these seven most important: Usability - user experience and usefulness Availability - readiness to perform its function when needed Performance - the speed at which software functions are performed Scalability - ability to handle an increasing volume of transactions and data Maintainability - the ease at which it can be changed or extended Security - confidentiality, integrity, authentication, authorization Profitability - ability to bring financial value or reduce the cost of maintaining Often, the client and the team value these aspects of software quality differently. For example, technical debt is significant for the engineering team because the team is aware of the potential problems it can cause in the future. On the other hand, solving technical debt brings little immediate value to the client. Gathering requirements / defining specification During my experience as a PO, it often happened that different aspects of software quality were directly conflicted in a single requirement when both client's and team's perspectives were considered. Each requirement that brought this kind of challenge was particular; unfortunately, there is no straightforward advice that could be applied in all situations. However, there is something I developed for myself as a checklist when considering whether a potential new feature makes sense and whether it should be introduced to the software: Does it fit the product's purpose? - Each Product Owner must know the product vision and have it documented and shared with all stakeholders, including the engineering team. Answering this question means assessing whether the requirement is aligned with the product vision. Does it add value for the users? - In addition to understanding whether a feature is aligned with the product vision, a PO must understand which and how many users will benefit from it. Does it impact users' ability to learn and use a system easily? - This question helps define how generic or specific a feature should be. Does it impact other aspects of software quality? - Here, a Product Owner should consider at least those seven characteristics described above, whether and how each will be affected. Does it add (unnecessary) complexity to the software? - Understand how it impacts code maintainability. Changing Requirements In addition to initial feature specification, changes in existing features' requirements are another integral part of the Product Owner's life. There are different reasons for changing existing features. It could be that business or users' needs have changed. Still, it can also result from a client's indecisiveness, a communication gap, or the inability to reach out to the end users and get their feedback. If requirements change too often, that could lead to the team's discontent. The team feels that there is a lot of throwaway work and no sense of accomplishment when the goal to deliver the desired feature is constantly slipping away. On the other hand, users are also affected by the prolonged time until the value is delivered. While changes in requirements are often necessary, it is good to recognize and prevent the frequent changes resulting from indecisiveness, miscommunication, or lack of feedback. There are several 'tools' a PO can use to enhance the product specification process, which can be used for both initial requirements gathering or changes in requirements: Collect user feedback through various methods such as design demos, usability testing, or AB testing. If end users are not reachable, think of who else can provide valuable feedback. For example, members of the QA team are the ones whose mindset is set to look at the product from users perspective. Perform feature design sprints - a process in which features are designed one sprint ahead of development. During the design sprint, design mockups are created, used to collect user feedback, and refined based on it. Include Dev team members in UI/UX phase - their perspective is extremely valuable and even time-saving when deciding what can be done given the current circumstances - software architecture, hardware capabilities etc. Document conclusions in written form - the benefits of having written conclusions (requirements, decisions and assumptions) are apparent. Still, nevertheless, it's important to emphasize how this habit can be a 'life-saver'. It could prevent unnecessary feature changes when everyone is reminded why certain decisions were made in the past. Refusing requirements Most POs at some point had a situation when a client's requirement made sense, it was completely justified, but the engineering team said, 'No - This cannot be done'. For me, saying 'No' to the client is one of the most challenging aspects of the PO role, but over the years, I've learned that sometimes it is necessary. These are some of the tips on how to either prevent or handle those uncomfortable situations: Inspire the team by helping them understand the larger picture. You can achieve this by inviting engineering team member(s) to some business meetings. It’s probably not efficient to invite all team members to all meetings. Still, having at least a few team members support you in the planning session when the 'unpopular' requirement is going to be discussed is very useful. Hearing from clients directly increases the team's empathy toward their needs. Assess the experience of Dev team members within a given project domain. If necessary, look for the advice of senior colleagues within the company. When saying 'No', explain why and offer alternatives. Arguments, why something can not be done, must be well understood and presented. Also, discussing alternatives that the team finds acceptable and presenting them to the client when saying 'No' is always necessary. Takeaways While it is difficult to summarize all the challenging situations a Product Owner faces when balancing feature specifications between the client and the team, it is helpful to remember some of these tips:  Understand the 'why' - Make sure you always understand the 'background' of each requirement, how it fits the product purpose and what business or personal need it solves. Make sure the engineering team shares the same understanding. Find a 'fine line' between generic features and specific user needs. While generic features are preferable from the point of software maintainability, they might not be quite intuitive to the users. On the other hand, not all very specific requirements have to be transformed into a new feature. Finding a 'fine line' comes with experience, but it's something to have in mind with each requirement. Refrain from being overconfident and making assumptions - after years of experience in a PO role, I've sometimes fallen into a trap that I understand best what are users' and team's needs and so I can make decisions quickly. That caused me to make some mistakes. Always ask for user feedback and team input. Be transparent in both ways - very often, compromises must be made when defining or changing specifications. Make sure that all sides are aware of those compromises and why they had to be made. (more…)

Organising Distributed Teams Working on a Single Codebase Collaboration has long been a main ingredient to high-performing and successful businesses. One of the main table topics today is how to encourage team collaboration in fully remote or hybrid mode of work. To add to the scope of collaboration challenges, projects can be a part of a large, single, codebase to which several dislocated teams are contributing to; teams which use different approaches to work. In this case study, we will describe the challenges we were facing on a project in which multiple teams from different organisations were involved. Each team had its custom sign-off and release procedures, but the code had to be synchronised into a single production release by the end of each cycle. How it started? In this particular setup, three companies with several teams joined the effort on an existing project. The existing software supported a set of features which were shared among services from different business domains. Shared features, as well as services, were all part of a single codebase. Each team was in charge of a particular service, including design, development and testing. There were already established guidelines in terms of procedures and processes all teams were to follow. Main challenges Inherited processes were designed in such way that two versions of the software were worked on at the same time. The focus of the QA team was on the version that is released to Production next. To simplify, we can call it Version 1.0. QA team had two weeks to perform testing for that version of the software. During those two weeks, Dev team was developing features for the version that comes after (Version 2.0). Visually represented, the process looked like this: However, inherited processes seem to have several drawbacks which influenced overall efficiency: Long release cycles - the time between a requirement is received until it could go to Production at the earliest was effectively one month. That seemed too long for a software so actively developed and widely used. Users would benefit from a shorter release cycle. On the other hand, development teams always benefit from the shorter feedback loops. Different goals - with QA team working on one version of the software and Dev team on another, the cohesion between those teams was broken. They worked on different goals at the same time, which was exactly the opposite of what Scrum stands for - the whole team working toward a single sprint goal. Context switching - switching between two versions of the software was inefficient for everyone on the team. Dev team was supposed to focus on the features for Version 2.0 while fixing the bugs for Version 1.0. It always felt like the QA team had to make an extra effort to draw Dev’s team attention to 1.0. For a PO, prioritising between the two versions was also a challenge. Additional problem, not directly related to how processes were designed, was the fact that a bug found in one of the services just before the release would postpone the release for all teams, so it was difficult to establish a regular release cycle. Our first proposal was to have all teams use a regular 2-week Sprint, which would include development, testing and integration stage with other services. However, introducing traditional Scrum proved to be much harder task than we expected as it requires a significant shift in organisational culture. In order to make the changes we rooted for, a different approach was necessary. So we had to be creative in order to come up with the process design that will work for all. Getting to a compromise Some teams decided to keep the release cycle of 2 weeks for development + 2 weeks for testing. At the same time, teams here in Atlantbh started with regular 2-week Sprints during each of those phases. Everything related to the (e.g.) Version 1.0 (development, PR review, testing, bug fixing) was done in one Sprint. This extension of the processes can be visualised as: Even though the idea itself doesn’t sound particularly brilliant in its essence, things got a bit more complex with establishing git rules, having in mind that all teams still committed to a single codebase and used shared features. This is how git flow was described for Scrum teams: Sprint Day 1: service branch is created from the latest develop branch. (Note: Service branch was regularly updated with latest changes from develop, so that changes made by other teams are picked up). service branch name convention: {service_name}-{software_version}. Sprint Days 2 to 7: Service-specific pull requests are reviewed and merged to the service branch. service branch is deployed to each team’s DEV environment, where its QA team verifies features. After all features are tested in service’s DEV environment, the service branch is merged to develop. Sprint Day 7: Final day for merging service to develop branch. Sprint Days 8 to 10:  Regression testing is performed on develop. All bug fixes PRs are merged directly to it. At the end of Sprint, develop is merged to main branch and deployed to Production.  Other teams (with one month release cycle) used following git flow: Development cycle (2 weeks): Pull requests are merged to Project’s feature branch. QA cycle (2 weeks):  feature branch is merged to develop and deployed to QA environment for QA teams to start testing. At the end of QA cycle, develop is merged to main branch and deployed to Production (same step as for Scrum teams). (Note: 1st day of QA cycle is equivalent to Sprint Day 1 for Scrum teams.) Conclusion Even though we made this hybrid model work for some time, ultimately it was decided to split the codebase per services. For most teams this was a significant effort of several months, but it payed off in a long run by eliminating the issue of blocking each-other releases. Individual teams could have independent release cycles and Production deployments. Also, the effort resulted in a codebase that is much easier to maintain and onboard new people. Still, going through different collaboration models taught us a few valuable lessons. Just as we incrementally improved our software, we learned how to incrementally improve our processes and achieve changes in a complex project setup. It took some courage to initiate changes across multiple organisations, but it was also a good practice of open communication and adaptability skills as means of achieving a desired goal. Ultimately, we have reached the model that works best for all the teams involved. We still collaborate very successfully on the same project but with a high level of independence.  

Working in an agile team requires delivering frequent product demos to the client. Whether you are a software developer, QA engineer or product owner, this is an inevitable part of the development process. Here, at Atlantbh, most projects follow the Scrum methodology using two-week sprints. Meaning we deliver demos at least once every two weeks, at the end of each sprint. For most, delivering a demo, or any presentation at all, is not a pleasant experience, and that’s understandable. Usually there is a number of people, many of them managers, listening to you. Any type of question can be expected and you have the responsibility of presenting the work of the whole team in the best way possible. Based on my experience, here are some pieces of advice that can help you: A) feel more comfortable while delivering the demo and B) get the most out of it: Prepare your scenarios well - I know this sounds as me reinventing the wheel, but before we go any further I want to make sure that this step is properly emphasized. It is common sense that good preparation is key to success, but somehow, for different reasons, we fail at this step. Even if it has been a busy day and you are completely confident that you know how certain feature works, try it out before the demo. Write down all the steps and follow the scenario. Even if you think of something really cool during the demo and you badly want to show it to the clients, keep it to yourself. We know we are building high-quality, predictable software but it is just that demo-karma that will make you click on the only button in the application that doesn’t behave as you would expect it to. Unless you are completely sure how the software is going to behave, don’t do it. Some actions take longer to process, data that you expect might be missing and you will end up leaving a bad impression even if you have a really cool feature. Get to the point - In order for your demo to leave the best impression on clients, try to be as specific as possible. So, less talking and more demonstrating. Often we get eager to explain how tricky some feature was to implement, what hardships we went through, basically to explain the whole ‘invisible’ work behind it, but the ugly truth is that the audience doesn't want to hear about that. Not during the demo. Some other meeting might be a more appropriate opportunity if you must share that kind of information. Demos are the opportunity to show the outcomes, to demonstrate different features of your software product, no matter how trivial or complex they were to implement. The most successful demo I had was where we showed a bunch of ‘small’ features that make the everyday usage of the application easier. Nothing too complex to implement… I literally could hear excitement coming from the audience. Tell a story - If your plan is simply to show one feature after another then you might leave the audience wondering how they can utilize the features you are showing. That’s not how you sell it. You have to know client’s needs and their business processes and make a real-life story that your feature fits into. Consider these two use-cases: -  Create a new email notification. Call it ‘Info’. The notification should be triggered by event called ‘Demo’ and sent to a user called ‘Test user’. Voila, everything works! The message you are communicating is that your application is fast and easy to use. - Create an email notification called ‘New job application received.’ The notification should be sent to all HR managers every time a user submits a new job application. This way, they don’t have to remember to log in occasionally to check if there are new applicants. You are communicating not only that the feature is fast and simple, but how it will impact users’ productivity and improve business processes’ efficiency. Bring your features to life by explaining them through a use-case that clients can relate to. This way, you show expertise on how products should be implemented and prove the value of your software product. Collect feedback - This is the most important part of the demo. Demo is not a place to brag about how great our software is and how much we managed to accomplish in a two-week sprint. Make sure that everyone is given a chance to comment on the features you are presenting. Moreover, make sure that you really listen and understand the feedback because this is the perfect opportunity to collect useful ideas which you will use later to tailor your software product to their needs. At the end of the demo it should be clear to everyone involved what further expectations are. If necessary, try to summarize briefly all the comments received during the demo. Demos should be considered as an opportunity to gauge our progress and positioning with clients and benefit from the feedback they provide. Getting this valuable feedback is done by provoking a response from clients. Telling a story that they can relate to in their business processes, brings about this response. We must keep interest by sticking to the point. Lastly, we should be well-prepared and confident with our software product and in that way build mutual trust.