Agile product development today
Software is developed in an agile way these days. Everyone knows that. It makes sense. In today’s world, requirements change so quickly that there’s no other way to keep up. And you want to release every two months. New features, fixed bugs. That’s what customers want. Thanks to current technologies, this is possible. This has also reached the upper echelons of the many companies that are increasingly having to become software manufacturers due to digitalization in all industries. And the competition is doing the same. So buy scrum masters, retrain product managers to become product owners, read 1-2 blogs, restructure the software department a bit and off you go!
What doesn’t sound like much at first, however, still turns out to be a major challenge more than 20 years after the Agile Manifesto was published. Even if the agile software methodologies of the masters of the Agile Alliance in the 90s and early 2000s do not seem overly complex, it is precisely the simple-sounding principles and values that are very difficult to anchor in our analytical and structured process thinking. Many companies quickly introduce agile methodologies and tools, which every employee then has to use (“doing agile”), but forget that the most important thing is to think agile (“being agile”). And this cannot be implemented so quickly, because it requires a change in culture. And culture always changes slowly.
In addition, the quality standards of software, especially with regard to the user interface and the user experience, have developed further and awaken the needs of customers and companies. Because the establishment of UX design not only makes marketing happy, but also saves money by making employees more efficient and satisfied, by freeing up capacities in many other areas that can be used elsewhere, and customers are also more satisfied with the product being sold. But how can you manage all this if you can’t even get the agile mindset established effectively?
Bringing together what belongs together
If you look at the Wikipedia articles on Agile software development and User-centered design, you quickly notice that they are two separate worlds: There are no direct references to each other, and UI design on the one hand and agile development on the other are each treated only stepmotherly. Yet you can’t have one without the other these days. Is everyone so busy trying to get at least one of the two topics up and running in their company that no one has time to adapt the Wikipedia articles to the present time?
When we are called in as a service provider for UX design for the development of a software product, we are almost always confronted with agile development processes whose characteristics and maturity could not be more different. We get to see first-hand the problems that arise from establishing agile principles in a company and have to bring our user-centered approach to this complex situation marked by upheaval. However, we should not reinvent the wheel, because in both worlds there are methods and practices that have proven themselves. They just need to be brought together, even if they sometimes contradict each other. For example, the universally popular process framework Scrum calls for cross-functional teams in order to minimize dependencies within the development team. An absolutely correct basic idea of minimizing risk by reducing dependencies – but who seriously wants to see user interfaces designed by software engineers?
“We believe in an approach that unites people from different disciplines in one team and allows them to act together effectively and efficiently despite any dependencies that may arise, so that the added quality to the product from the different expertise outweighs the risk that arises . “
At Centigrade, we do not believe that one person can master all process steps of the product lifecycle (from requirements engineering to UI design to implementation and maintenance). We believe in an approach that unites people from different disciplines in one team and allows them to act together effectively and efficiently despite any resulting dependencies, so that the added quality gain for the product from the different expertise outweighs the resulting risk. And this interdisciplinary composition of teams has proven to be useful in many areas, be it in films, which are also made better – or only possible at all – by many different disciplines working on them, or soccer teams, which also do not only consist of strikers.
When we come into a UX project, we also don’t want to smash existing structures and raise the Scrum master finger if no Scrum is done “by-the-book” at all. We want to integrate established methodologies and tools from the UX world “leanly” into existing agile processes and encourage and maintain collaboration between all disciplines and stakeholders involved in the development in order to add value as quickly as possible for the ultimate users of the product against the background of a defined business goal. This is what is meant by the four principles of the Agile Manifesto: people work together collaboratively to produce working software as reactively as possible. And if we also design this software to deliver great UX and be well received by the market, then we’ve made it.
Establish UX across the entire agile product development cycle
“The decisive factor for users is that UX is not only discussed at the beginning of a project, but also finds its way into the product during the process.”
Over the years, we have developed a flexible process toolbox, Continuous UX, whose process modules make it possible to adapt an agile UX approach to the iterative and incremental processes of our customers and to establish it throughout the entire agile product development process. Continuous UX, analogous to Continuous Integration and Continuous Delivery. The decisive factor for users is that UX is not only discussed at the beginning of a project, but also finds its way into the product during the process.
To ensure that the application succeeds, we not only bring our many years of experience in UX design to the table, but also apply our expertise in agile product development and agile project management in the same way. This results in the role of Continuous UX Advisor for us, whose most important responsibilities when accompanying a project are as follows:
1. Project Scoping
This is where the foundation for the project is laid. We first illuminate exclusively the potentials prevailing in the context of the product to be developed from a business perspective, jointly define a corresponding business goal for the current project stage, and look at which minimal product approach (MVP) can fulfill the most important needs of the most important user in a specific context of use. The important thing here is to think as small as possible in order to achieve effective results quickly without forgetting the big picture.
2. User Requirements Management
Validated user needs are important for a user-centered approach. They are decisive for the prioritization of the functionalities of the product to be developed and thus specify an order for the development. It is important to check them again and again, to maintain them, and also to reconcile them with other requirements, such as technical restrictions or organizational specifications.
3. Ideation und User Story Workshop
In addition to the initial exploration of the solution space and the initial prioritization of user needs, it is important to choose the right level of abstraction of user needs at all times. At the beginning, they should be abstract enough to provide a good overview of the needs identified in the application context of the most important users in order to differentiate and prioritize them against each other and against other requirements, as well as to be able to empathically understand the usually frustrating status quo of the users and their “User Journeys of Pain”. However, when it comes to the concrete development of solutions, whether in conception, visual design or software engineering, a lower level of abstraction can help to communicate and implement solutions as completely and precisely as possible. Choosing the right flight level is a challenge and a decision that only needs to be reviewed again and again and adapted to the current context.
4. Stakeholder Management
The user-centered approach seems very altruistic at first. But of course it must be acknowledged that there are economic interests behind every project and product. Therefore, the exclusive focus on users is not helpful, especially not for the users themselves. Without, for example, money-giving stakeholders, there is no project and no product that solves a problem of the users at some point. It is therefore advisable not only to involve stakeholders in the regular coordination of requirements, but also to give them the opportunity to participate and contribute to the entire agile product development process.
5. Empowerment of the Development Team
Once the project framework has been defined, it’s time for implementation. For this to succeed effectively and efficiently, a capable and committed development team is needed. This can be empowered and managed using standard agile practices. It should be noted, however, that this is an interdisciplinary team whose focus varies widely in how it performs its tasks. Here, too, it is advisable to remain true to the principles of the Agile Manifesto and to support the team as a social fabric in such a way that the existing expertise jointly develops great value for the product at each increment.
6. Establishment of Sprint Cycles
Organizing the work and necessary alignments in short, effective sprints helps to motivate the development team, involve stakeholders, and minimize risk through continuous delivery of working software. It is crucial that all disciplines work in parallel and in close alignments with each other to continuously add value to the product. This ensures that development is more effective (more complete and accurate), less risky (continuous fulfillment of user needs) and more controllable (adaptation to context changes) than in traditional ways of developing software, such as the waterfall model. Capacity management is not always easy. But it is necessary to ensure high product quality. From a Continuous UX perspective, Continuous Delivery means, among other things, that the work of a conceptual designer does not end with the handover to software engineers, but that it continues in the form of in-depth reviews of the potential new increment.
“Internalizing and taking to heart the principles of the Agile Manifesto not only help to develop software in an agile way, but also promote the integration of a continuous and holistic UX approach, which is essential in today’s world and contributes significantly to product success. “
If these building blocks are applied correctly, as we also train them in our Academy Training “Scrum meets UX”, the interaction of UX design in a user-centered approach and the ubiquitous, agile product development succeeds. Internalizing and taking to heart the principles of the Agile Manifesto not only help to develop software agilely, but also promote the integration of a continuous and holistic UX approach, which is indispensable in today’s world and contributes significantly to product success.
We have aroused your interest? Take a look at our services !
