Agile product development: How do you plan the unplanned
Agile product development: Scrum Master Sarah Schnur & Head of Product Owner Steven Kolbenschlag answer the most important questions.
Developing software solutions doesn't start with coding and it doesn't end with the transfer of the source code - at least not in our opinion. As a development partner for large and medium-sized companies in the engineering, manufacturing and construction industries, we have more than 20 years of experience in developing customised software. The last few years in particular have shown us that software development must be seen as a holistic process. In an interview, our CTO Sebastian Betzin explains the company's new direction and what's really important in software development today: "Simply taking a finished specification sheet and turning it into code is no longer enough. You may end up with a product, but it will most likely not be what the company really needs. "
“Simply processing a ready-made specification sheet and pouring it into code doesn't work anymore. This will result in a product, but it is highly likely not what the company really needs. ”
(Sebastian Betzin, CTO generic.de)
Sebastian Betzin: Our world is becoming increasingly complex - especially in industrial environments. Digitalisation gives us endless opportunities to redesign and optimise processes. It's impossible to keep track of everything and stay on track - at least when you're on your own. As a development partner, we want to be involved much earlier in the development process than when it comes to programming. Simply taking a finished specification sheet and turning it into code is no longer an option. You may end up with a product, but it will most likely not be what the company really needs.
Sebastian Betzin: The earlier there is a common understanding of the product vision, the sooner we can participate in brainstorming and defining requirements. And thus help plan product development from the ground up. After all, it's not about developing just any software product, but the right product — for the company and future users. To do this, we must be able to answer which users have to perform which tasks, which data they need and how the software supports them in their work in the best possible way. Once these basic questions have been answered, we also produce much more efficiently and can therefore bring the software product to market faster. At the same time, this deep integration allows us to develop a holistic understanding of the product, the customer and the industry. We're talking about domain knowledge. And that is essential for the operation, support and possible further developments of the solution.
“After all, it's not about developing just any software product, but the right product — for the company and future users. ”
(Sebastian Betzin, CTO generic.de)
Sebastian Betzin: At Invent Our aim is to work out a working product idea together with the customer based on their business case and their rough vision. Or — if they already exist — to test and validate the idea.
We then help our customers steer the product idea in the right direction. We call that as Explore. You could also call it guided requirements engineering, although that falls short. Rather, it is actually a kind of research trip in which we want to get to know and understand the company and, above all, the future users. Our UX team is increasingly involved in this phase. They take a close look at users, analyse their work processes and use this knowledge to develop the first click dummies — i.e. clickable interface designs of the solution. Our solution architects, on the other hand, look at the technical side and design the software architecture. The initial work is now complete, and we will of course continue to “research” our customers in the following project phases.
developing describes the agile processes that are necessary to actually create the product — i.e. coding, testing and UI design. In doing so, we work together with our customers in an interdisciplinary project team. For example, we define the special requirements for a feature, implement them in code and UI and test the whole thing together. Our software developers work according to the principles and practices of clean code development. This is a value system that is designed to write sustainable source code. We are also talking about high internal software quality: The more clearly and readable the code is written and the higher the test coverage, the better it can be modified, adapted or extended in the future — and the more durable the software product is.
After all, that also plays for us at Received into the cards. This is because everything revolves around the operation and development of the product. This is where our DevOps way of working comes into play: we combine the disciplines of development and operations. And of course: the cleaner and more modular the source code is, the faster and cheaper new features can be implemented.
For us, this is the golden path of digital product development. For now, at least. After all, you never know what tomorrow will bring.
Agile product development: Scrum Master Sarah Schnur & Head of Product Owner Steven Kolbenschlag answer the most important questions.