Reading time 7 min

Dorien Jorissen

In software development, assumptions can have a serious impact and we should always be on the look-out. In this blog post, we talk about how to deal with assumptions when developing software. Imagine…you’ve been driving to a certain place A place you have been driving to every day for the last 5 years, taking the same route, passing the same abandoned street, where you’ve never seen another car. Gradually you start feeling familiar with this route and you assume that as always you will be the only car on this road. But then at a given moment in time, a car pops up right in front of you… there had been a side street all this time, but you had never noticed it, or maybe forgot all about it. You hit the brakes and fortunately come to a stop just in time. Assumption nearly killed you. Fortunately in our job, the assumptions we make are never as hazardous to our lives as the assumptions we make in traffic. Nevertheless, assumptions can have a serious impact and we should always be on the look-out. Imagine… you create websites Your latest client is looking for a new site for his retirement home because his current site is outdated and not that fancy. So you build a Fancy new website based on the assumption that Fancy means : modern design, social features, dynamic content. The site is not the success he had anticipated … strange … you have build exactly what your client wants. But did you build what the visitors of the site want? The average user is between 50 – 65 years old, looking for a new home for their mom and dad. They are not digital natives and may not feel at home surfing on a fancy, dynamic website filled with twitter feeds and social buttons. All they want is to have a good impression of the retirement home and to get reassurance of the fact that they will take good care of their parents. The more experienced you’ll get, the harder you will have to watch out not to make assumptions and to double-check with your client AND the target audience . Another well known peril of experience is “ the curse of knowledge “. Although it sounds like the next Pirates of the Caribbean sequel, the curse of knowledge is a cognitive bias that overpowers almost everyone with expert knowledge in a specific sector. It means better-informed parties find it extremely difficult to think about problems from the perspective of lesser-informed parties. You might wonder why economists don’t always succeed in making the correct stock-exchange predictions. Everyone with some cash to spare can buy shares. You don’t need to be an expert or even understand about economics. And that’s the major reason why economists are often wrong. Because they have expert knowledge, they can’t see past this expertise and have trouble imagining how lesser informed people will react to changes in the market. The same goes for IT. That’s why we always have to keep an eye out, we don’t stop putting ourselves in the shoes of our clients. Gaining insight in their experience and point of view is key in creating the perfect solution for the end user. So how do we tackle assumptions …? I would like to say “Simple” and give you a wonderful oneliner … but as usual … simple is never the correct answer. To manage the urge to switch to auto-pilot and let the Curse of Knowledge kick in, we’ve developed a methodology based on several Agile principles which forces us to involve our end user in every phase of the project, starting when our clients are thinking about a project, but haven’t defined the solution yet. And ending … well actually never. The end user will gain new insights, working with your solution, which may lead to new improvements. In the waterfall methodology at the start of a project an analysis is made upfront by a business analist. Sometimes the user is involved of this upfront analysis, but this is not always the case. Then a conclave of developers create something in solitude and after the white smoke … user acceptance testing (UAT) starts. It must be painful for them to realise after these tests that the product they carefully crafted isn’t the solution the users expected it to be. It’s too late to make vigorous changes without needing much more time and budget. An Agile project methodology will take you a long way. By releasing testable versions every 2 to 3 weeks, users can gradually test functionality and give their feedback during development of the project. This approach will incorporate the user’s insights, gained throughout the project and will guarantee a better match between the needs of the user and the solution you create for their needs. Agile practitioners are advocating ‘continuous deployment’; a practice where newly developed features will be deployed immediately to a production environment instead of in batches every 2 to 3 weeks. This enables us to validate the system (and in essence its assumptions) in the wild, gain valuable feedback from real users, and run targeted experiments to validate which approach works best. Combining our methodology with constant user involvement will make sure you eliminate the worst assumption in IT: we know how the employees do their job and what they need … the peril of experience! Do we always eliminate assumptions? Let me make it a little more complicated: Again… imagine: you’ve been going to the same supermarket for the last 10 years, it’s pretty safe to assume that the cereal is still in the same aisle, even on the same shelf as yesterday. If you would stop assuming where the cereal is … this means you would lose a huge amount of time, browsing through the whole store. Not just once, but over and over again. The same goes for our job. If we would do our job without relying on our experience, we would not be able to make estimations about budget and time. Every estimation is based upon assumptions. The more experienced you are, the more accurate these assumptions will become. But do they lead to good and reliable estimations? Not necessarily… Back to my driving metaphor … We take the same road to work every day. Based upon experience I can estimate it will take me 30 minutes to drive to work. But what if they’ve announced traffic jams on the radio and I haven’t heard the announcement… my estimation will not have been correct. At ACA Group, we use a set of key practices while estimating. First of all, it is a team sport. We never make estimations on our own, and although estimating is serious business, we do it while playing a game: Planning poker. Let me enlighten you; planning poker is based upon the principle that we are better at estimating in group. So we read the story (chunk of functionality) out loud, everybody takes a card (which represent an indication of complexity) and puts them face down on the table. When everybody has chosen a card, they are all flipped at once. If there are different number shown, a discussion starts on the why and how. Assumptions, that form the basis for one’s estimate surface and are discussed and validated. Another estimation round follows, and the process continues till consensus is reached. The end result; a better estimate and a thorough understanding of the assumptions surrounding the estimate. These explicit assumptions are there to be validated by our stakeholders; a great first tool to validate our understanding of the scope.So do we always eliminate assumptions? Well, that would be almost impossible, but making assumptions explicit eliminates a lot of waste. Want to know more about this Agile Estimation? Check out this book by Mike Cohn . Hey! This is a contradiction… So what about these assumptions? Should we try to avoid them? Or should we rely on them? If you assume you know everything … you will never again experience astonishment. As Aristotle already said : “It was their wonder, astonishment, that first led men to philosophize”. Well, a process that validates the assumptions made through well conducted experiments and rapid feedback has proven to yield great results. So in essence, managing your assumptions well, will produce wonderful things. Be aware though that the Curse of Knowledge is lurking around the corner waiting for an unguarded moment to take over. Interested in joining our team? Interested in meeting one of our team members? Interested in joining our team? We are always looking for new motivated professionals to join the ACA team! {% module_block module "widget_3ad3ade5-e860-4db4-8d00-d7df4f7343a4" %}{% module_attribute "buttons" is_json="true" %}{% raw %}[{"appearance":{"link_color":"light","primary_color":"primary","secondary_color":"primary","tertiary_color":"light","tertiary_icon_accent_color":"dark","tertiary_text_color":"dark","variant":"primary"},"content":{"arrow":"right","icon":{"alt":null,"height":null,"loading":"disabled","size_type":null,"src":"","width":null},"tertiary_icon":{"alt":null,"height":null,"loading":"disabled","size_type":null,"src":"","width":null},"text":"View career opportunities"},"target":{"link":{"no_follow":false,"open_in_new_tab":false,"rel":"","sponsored":false,"url":{"content_id":229022099665,"href":"https://25145356.hs-sites-eu1.com/en/jobs","href_with_scheme":null,"type":"CONTENT"},"user_generated_content":false}},"type":"normal"}]{% endraw %}{% end_module_attribute %}{% module_attribute "child_css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "definition_id" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "field_types" is_json="true" %}{% raw %}{"buttons":"group","styles":"group"}{% endraw %}{% end_module_attribute %}{% module_attribute "isJsModule" is_json="true" %}{% raw %}true{% endraw %}{% end_module_attribute %}{% module_attribute "label" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "module_id" is_json="true" %}{% raw %}201493994716{% endraw %}{% end_module_attribute %}{% module_attribute "path" is_json="true" %}{% raw %}"@projects/aca-group-project/aca-group-app/components/modules/ButtonGroup"{% endraw %}{% end_module_attribute %}{% module_attribute "schema_version" is_json="true" %}{% raw %}2{% endraw %}{% end_module_attribute %}{% module_attribute "smart_objects" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "smart_type" is_json="true" %}{% raw %}"NOT_SMART"{% endraw %}{% end_module_attribute %}{% module_attribute "tag" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "type" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "wrap_field_tag" is_json="true" %}{% raw %}"div"{% endraw %}{% end_module_attribute %}{% end_module_block %}

Reading time 4 min

Gregory Van Dorpe

OutSystems: a catalyst for business innovation In today's fast-paced business landscape, organisations must embrace innovative solutions to stay ahead. There are a lot of strategic technological trends that address crucial business priorities such as digital immunity, composability, AI, platform engineering, Low-Code , and sustainability. OutSystems , the leading Low-Code development platform , has become a game-changer in supporting organisations to implement these trends efficiently and sustainably. OutSystems enhances cyber security As organisations increasingly rely on digital systems, cyber threats pose a significant risk. Additionally, digital engagement with customers, employees, and partners, plays a vital role in a company's well-being. The immunity and resilience of an organisation is now as strong and stable as its core digital systems. Any unavailability can result in a poor user experience, revenue loss, safety issues, and more. OutSystems provides a robust and secure platform that helps build digital immune systems , safeguarding against evolving cybersecurity challenges. With advanced threat detection, continuous monitoring, secure coding practices , and AI code-scanning, OutSystems ensures applications are resilient and protected. Furthermore, the platform covers most of the security aspects for project teams, enabling them to focus on delivering high value to end customers while best practices are recommended by the platform through code analysis using built-in patterns. OutSystems simplifies cloud-native infrastructure management Cloud-native architecture has emerged as a vital component for modern application development. The OutSystems Developer Cloud Platform enables teams to easily create and deploy cloud-native applications, leveraging the scalability and flexibility of cloud infrastructure through Kubernetes . It allows companies to: Optimise resource utilisation Auto-scale application runtimes Reduce operational costs Adopt sustainable practices (serverless computing, auto-scaling, …) All this without the need for prior infrastructure investment nor the deep technical knowledge required to operate it and the typical burdens associated. OutSystems: gateway to AI and automation AI and hyper-automation have become essential business tools for assisting in content creation, virtual assistants, faster coding, document analysis, and more. OutSystems empowers professional developers to be more productive by infusing AI throughout the application lifecycle. Developers benefit from AI-assisted development, natural language queries, and even Generative AI. Once ready with your development, transporting an app to the test or production environment only takes a few clicks. The platform highly automates the process and even performs all the necessary validations and dependency checks to ensure unbreakable deployments. OutSystems seamlessly integrates with AI capabilities from major cloud providers like Amazon, Azure (OpenAI), and Google, allowing project teams to leverage generative AI, machine learning, natural language processing , and computer vision . By making cutting-edge technologies more accessible, OutSystems accelerates digital transformation and creates sustainable competitive advantages. OutSystems enables composable architecture for agility Composable architecture and business apps, characterised by modular components, enable rapid adaptation to changing business needs. OutSystems embraces this trend by providing a cloud-native Low-Code platform using and supporting this type of architecture. It enables teams to easily build composable technical and business components. With the visual modelling approach of Low-Code, a vast library of customizable pre-built components and a micro-service-based application delivery model, OutSystems promotes high reusability and flexibility. This composable approach empowers organisations to: Respond rapidly to changing business needs Experiment with new ideas Create sustainable, scalable, and resilient solutions OutSystems enables the creation of business apps that can be easily integrated, replaced, or extended, supporting companies on their journey towards composability and agility. OutSystems facilitates self-service and close collaboration Platform engineering, which emphasises collaboration between development and operations teams, drives efficiency and scalability. OutSystems provides a centralised Low-Code platform embracing this concept at its core by being continuously extended with new features, tools and accelerators. Furthermore the platform facilitates the entire application development lifecycle until operations . Including features like Version control Automated deployment Continuous integration and delivery (CI/CD) Logging Monitoring Empowering organisations to adopt agile DevOps practices. With OutSystems, cross-functional teams can collaborate seamlessly, enabling faster time-to-market and improved software quality. By supporting platform engineering principles, OutSystems helps organisations achieve sustainable software delivery and operational excellence. OutSystems drives sustainability in IT OutSystems leads the way in driving sustainability in IT through its green IT Low-Code application development platform and strategic initiatives. By enabling energy-efficient development, streamlining application lifecycle management, leveraging a cloud-native infrastructure , and promoting reusability , OutSystems sets an example for the industry. Organisations can develop paperless processes, automate tasks, modernise legacy systems, and simplify IT landscapes using OutSystems 3 to 4 times faster, reducing overall costs and ecological footprint. By embracing OutSystems, companies can align their IT operations with a greener future, contribute to sustainability, and build a more resilient planet. Wrapping it up In the era of digital transformation and sustainability, OutSystems is a powerful ally for organisations, delivering essential business innovations, such as … High-performance Low-Code development Cloud-native architecture AI and automation Robust security measures Collaborative DevOps practices Take the OutSystems journey to align with IT trends, deliver exceptional results, and contribute to a sustainable and resilient future. Eager to start with OutSystems? Let us help

Reading time 10 min

Dorien Jorissen

Suppose you’re a Product Owner in an Agile delivery team, ready to get working on your product. In order to do that, you’ll need to give your development team a goal and a list of things to work on. If you use SCRUM as the framework, you’d call that list of things to work on a Product Backlog . From the SCRUM guide: The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when “Done”. Okay, so you need to start with a backlog, prioritize as you see fit and then build the highest priority items first. SCRUM – and Agile development in general – is both incremental and iterative (see here or here for a good explanation of those terms). Let’s illustrate this with an example. When a customer orders a car – and we use SCRUM to implement it – we might iterate on the chassis and incrementally build the car, like this: However, as a Product Owner ( the role you take as a Product Manager), you’re left with a few questions: Where does the backlog come from? How can I be sure that it solves a need of the end user? How can I be sure that the development team will actually deliver my interpretation of the requirement? How can I be sure that I adapt to changes and still give my architect a clear (less evolving) set of parameters to work on? In this blog post, we’ll try to gradually answer those questions. Focus on the customer's underlying need Let’s start with the second question on our list: how can I be sure that it solves a need of the end user? Henrik Kniberg correctly points out: We start with the same context – the customer ordered a car. But this time we don’t just build a car. Instead we focus on the underlying need the customer wants fulfilled . Turns out that his underlying need is “I need to get from A to B faster”, and a car is just one possible solution to that. Compared to our previous example of a customer ordering a car, it would now look like this: Said plainly, this means that you first need to unravel the real problem and adapt as you see fit . The unraveling of the problem is iterative in nature: as long as you don’t get confirmation that you’re solving a real need, you need to change and adapt. You present the end user with a best guess of what a solution might look like. As long the user is not satisfied, you have to dig deeper and come up with alternatives. Ultimately, you hit the sweet spot and get confirmation that you understood the problem. This confirmation can be based on real usage data, qualitative insights or a combination of both. SCRUM doesn’t indicate how you should implement Henrik’s idea. My understanding is that there is a preference for developing software and focusing the sprint on ending with an increment . This means working software is used as an artefact during the iteration towards defining the problem. The drawback, however, is that the team needs to re-work already implemented increments, as they need to adapt to new insights. I checked the software development wastes and identified the potential ones: Estimation not possible due to poor analysis/information gathering (Partially Done Work). Technical complexity not analyzed properly (Partially Done Work), because it doesn’t make sense to do so during an iteration. Wrong choice of technology or solution (Defects), because the non-functional requirements are a moving target. Redesigning due to missed requirements (Defects). These are still concerns to be addressed which can be solved by a proper product discovery step . Let’s first revisit the questions a Product Owner might be left with and indicate which ones we’ve solved: Where does this backlog come from? How can I be sure that it solves a need of the end user? ✅ We start with an idea and iterate until we find a solution that fulfills a need. We keep doing this until we get a confirmation. How can I be sure that the development team will actually deliver my interpretation of the requirement? How can I be sure that I adapt to changes and still give my architect a clear (less evolving) set of parameters to work on? ❌ This makes the problem bigger: the development team now needs to do (at least some) more rework to cover up all the changes. Discover your user's needs In order to eliminate the potential wastes with Henrik’s example, you need to split the iterative part (finding out what the user needs) and the building of the software (crafting a solution for the problem). Finding out what the user needs implies a so-called discovery step . Marty Cagan , the “most influential person in the product space”, agrees : In Henrik’s example, the team is working to simultaneously determine the right product to build, and at the same time to build that product. And they have one main tool at their disposal to do that: the engineers. So what you see is a progressively developed product, with an important emphasis on getting something we can test on real users at each iteration. Henrik is emphasizing that they are building to learn, but they are doing this with the only tool they think they have: engineers writing code. If you read carefully, Henrik does mention that the engineers don’t actually need to be building products – they could be building prototypes, but with most teams I meet, this point is lost on them because they don’t understand that there are many forms of prototypes , most of which are not meant to be created by engineers. That’s right: writing software might be a good solution to find out what the user wants, but more often than not, it is the most expensive way to get there. With a discovery step, you can focus on the objectives of a product: is it valuable, usable, feasible and viable? This step is mostly iterative. The end result is a clear definition of the problem and hence a possible solution to that problem; one that has a high probability of solving a user’s need. Because you took a discovery step, this means you can describe the real problem to the engineering team. You can also describe the problem in more detail and also describe what kind of properties you expect from the end solution, e.g. a fitness function which places the solution in context. The development teams then figures out how to build that solution. This is the delivery step and it is mostly incremental. Product discovery track versus delivery track With the product discovery and delivery steps, there are two tracks the team must consider: a product discovery track and a delivery track . Let’s revisit the Product Owner’s questions a third time and indicate which ones we’ve solved: Where does this backlog come from? How can I be sure that it solves a need of the end user? ✅ ✅ We start with and idea and iterate until we found a solution that fulfills a need. We should really spend more time with our end users to really understand their problem. We should try to do this as fast as possible so that the engineering time doesn’t run out of work. How can I be sure that the development team will actually deliver my interpretation of the requirement? In terms of problem description, I’m able to provide more detail and give more context. How can I be sure that I adapt to changes and still give my architect a clear (less evolving) set of parameters to work on? The engineers really know it’s going to be a car before they can come up with a suitable architecture up to the task, and they may in fact choose to implement this architecture with a different delivery strategy than one designed to learn fast. As the risks are tackled in discovery and the necessary delivery work becomes clear, that delivery work progresses much faster than it would otherwise. Dual Track: product discovery and delivery happen simultaneously Discovery work focuses on fast learning and validation. But how do you chain that together with delivery work? When a project starts , you might do discovery first and then – somewhat later – let the engineering team start. It becomes like this : That looks a lot like Waterfall ! But it doesn’t have to be like this. Jeff Patton , a veteran Product Manager and writer of the book User Story Mapping , says it is all happening at once (Dual Track). Instead of a waterfall, we get a loop. A discovery learning loop looks a bit like this: It starts by describing what we believe is the problem we’re trying to solve and for whom, the solution to solve the problem, and how we’d measure its success. Product discovery loops chain together like this: Discovery work uses irregular cycle lengths. It’s ‘lean’ in the sense that we’re trying to make the discovery cycle as short as possible. Ideas in discovery mutate and very often get abandoned, which is the best move forward into more deliberate development cycles. Takeaway In order to eliminate potential risks, you need to be aware of both the discovery and delivery steps . The discovery step focuses on the objectives of a product: value, usability, feasibility and viability and is mostly iterative. The delivery step focuses on how to build a product and is mostly incremental. While the steps are separate, the tracks happen at the same time, which we call Dual Track. Jeff Patton’s article on Dual Track also mentions a few important points. These two tracks are two types of work performed by the same team. Discovery must check regularly with the team on feasibility, correct implementation and technical constraints that affect design decision. Delivery uses insights from discovery during development. Discovery focuses on the riskiest assumptions first, i.e. user problems of which we have low confidence they solve a real user need (or the need is unknown). Delivery focuses on solutions for which we have high confidence that it solves a user’s problem. The confidence might come from validated learning during discovery. Or we start – e.g. in the beginning of a cycle – with backlog items for which we think no discovery is needed, such as technical work or features of which we already have high confidence they solve a user problem. The two tracks are done in parallel : Discovery / Iteration : focus on the riskiest assumptions (problems of which we have the least knowledge of) and try to define them with the least effort possible. Delivery / Increment : focus on a well-defined solution (we have high confidence the end user needs it) and tackle the ones with highest value first. The tracks don’t stop as soon as you’ve discovered one problem to fix. The next problem is already looking around the corner. In our example with the customer ordering a car (“I need to get from A to B faster”), we might also think the user needs shelter, which can range from a simple hut to a castle. A final remark: this blog post started with SCRUM as the delivery framework, but the method ology doesn’t really matter: it could be Kanban, Crystal XP and even Waterfall as long as the team is able to keep pace in the two tracks. But of course, since the discovery part focuses on learning fast , an Agile methodology suits better. Left-over questions Let’s revisit the Product Owner’s questions one last time and indicate which ones are solved now. Where does this backlog come from? ✅ The backlog comes from assumptions which are validated during discovery. However, there is a new question: how do we identify the list of assumptions to focus on? Where does the list of Opportunities come from? ❓ How can I be sure that it solves a need of the end user? ✅✅✅ We start with an idea and iterate until we found a solution that fulfills a need. I should really spend more time with my end users and really really understand their problem. I should try to make this as fast as possible, so that the engineering time does not run out of work. Do this in parallel, with the whole team. How can I be sure that the development team will actually deliver my interpretation of the requirement? ✅ In terms of problem description, I can give more detail and give more context. Involve (at least part) of your engineering team in discovery. This way, they get in touch with the real end user get a better understanding of the user’s real world. How can I be sure that I adapt to changes and still give my architect a clear (less evolving) set of parameters to work on? ✅ The engineers really know it’s going to be a car before they can come up with a suitable architecture up to the task. They may in fact choose to implement this architecture with a different delivery strategy than one designed to learn fast. The risks are tackled in discovery and the necessary delivery work becomes clear. The delivery work can now progress much faster than it would otherwise