Software Bauhaus concept: One team to build it all

In principle, developing customised software is very simple, isn’t it? After all, all it takes is a clearly formulated idea and a qualified team of experts to implement it. And thanks to lightweight, agile development methods, it doesn’t even take weeks or months of planning and specification. Brave new agile world.

Let’s take the young, innovative start-up “Green Leaves” as an example. The two founders Svenja and Lars have the vision of revolutionising the care of green plants in cities with a unique application. Thanks to a well-funded innovation prize, the two now have the best prerequisites for putting their idea into practice as quickly as possible. For the development of their novel online platform, the two want to spare no expense and effort in hiring the most experienced people.

So they are initially looking for a system architect, senior back-end and front-end developers, a Scrum Master and two experienced testers. Although they all come from different service providers because of the short notice, each of them is highly qualified and experienced. That’s it – the high-performance Scrum team.

They deliberately do not hire the Product Owner externally, but provide him themselves: Lars takes on the task. After all, no one knows the technical domain and the vision better and the doctrine also says that a Product Owner is ideally the customer himself. Lars presents the product vision to the freshly assembled Scrum team, translates the requirements into user stories and in just a few sprints it will be ready: The potentially shippable product will see the light of day. Or not…

Anyone who has ever accompanied a software project knows that it is not quite that simple in practice!

Challenges when working with software development service providers

There are many problems when working with the new team. For example, the edited user stories regularly do not make it through the acceptance process. Obviously, the acceptance criteria leave room for interpretation, because Lars had imagined something completely different for some features than what was implemented by the developers. From her point of view, however, important special cases and alternative scenarios were not specified precisely enough.

The testers are also not satisfied with the quality of the software – they find numerous bugs because the frontend and backend do not seem to work together without errors. They are also dissatisfied with the development process as such. They would like to be active earlier rather than just before the stories are accepted.

After several sprints, Green Leaves is disillusioned. The founders have to realise that the team of experts has not come as far as they had hoped. The originally planned roadmap is outdated, the go-live is a long way off and the mood in the Scrum team is at rock bottom. But what exactly went wrong here? After all, only the best of the best were hired for the team.

This example, albeit exaggerated, makes clear a few fundamental problems and risks that often occur when software projects are assigned:

• A Scrum team is only as strong as its weakest member and a group of experts does not automatically guarantee a high outcome.

A really high-performing team is one thing above all: well-rehearsed. Only when the members know each other and their working methods, trust each other and know where each other’s strengths and weaknesses lie, can work packages be realistically estimated, quickly planned and efficiently implemented.

• The interaction of experts also takes time.

Time that our experts have most likely not yet had the chance to spend together. Until they achieve the expected results, several sprints and their retrospectives have to be completed. As in any other context, a team of developers goes through the usual phases of storming and norming until it can actually work “at high performance”.

• The risk of failure lies with the client.

If part of the newly formed team drops out due to illness or resignation, a replacement must be found and the team-building process begins anew. Stagnating velocity, moving targets and frustration in the team are then often the consequences. The risk of failure in such cases is often borne by the client.

• The time factor and methodological expertise on the part of the client

The idea that the Product Owner is provided by the client is of course a good one. After all, the product owner knows and understands his or her own idea, vision and possibly also the technical domain best.

The problem is often the time factor. Being a Product Owner, i.e. being “responsible for product success”, is a full-time job. Especially in the early phases of a software project, it is important for a team of developers to have a permanent contact person on the technical side.

In addition, the preparation, planning and acceptance of work packages require both technical and methodological expertise.

• “How do I present and sharpen the product vision?
• “How do I find and specify valuable, implementable user stories?”
• “What do helpful acceptance criteria look like?”

Especially when the idea is still very fresh and unclear, a Product Owner needs good answers to these and other questions. Reality shows: Time availability and methodological expertise are often not sufficiently available. And the risk? Once again, that lies with the client.

A team from the idea to maintenance

After ten years of experience as a service provider in the software sector, our ambitious project as QualityMinds was to provide an adequate answer to these very challenges. Our software construction concept addresses exactly these problems.

The basic idea follows the philosophy of the eponymous Bauhaus, founded by Walter Gropius in 1919:

Functional design in the sense of the user grows out of skilled, interdisciplinary cooperation.

For us, this means: we provide our clients with a complete, well-coordinated team and accompany them from the initial idea through to commissioning and maintenance. In this process, we distinguish between a discovery phase and a build phase.

In the former, we explore the idea together with the customer and ensure with the help of proven methods from UX, as well as classic and agile requirements engineering, that it is also mature enough for implementation. As soon as this is the case, we derive an initial backlog from the results and start with the implementation in the build phase; always as far and as long as the customer wants.

The promise here is: at every point of the development, we make sure that the right people work together in the team.

For our Green Leaves example, a Bauhaus scenario could look like this:

Together with Svenja and Lars, we hold some discovery workshops. Here we “knead” their idea, which means we play through the various main and exception scenarios, identify important system constraints, identify potential risks and sketch out possible solutions in terms of a suitable user interface.

It is important for us not to be fixated on a specific technology stack. We only make a suitable choice once we have penetrated the problem. All team members and their perspectives are involved from the beginning in order to create as holistic a “big picture” as possible. Our goal here is to make Svenja and Lars’ vision our own as well. In our experience, we always deliver the best possible work when we can identify with the product ourselves.

Nevertheless, we welcome Lars’ decision to take on the role of Product Owner himself. In this case, our experts for requirements engineering and UX see themselves as a kind of sparring partner for Lars, supporting him with methods such as user story mapping, specification by example or story splitting heuristics and helping him to write valuable stories and plan the product roadmap. In doing so, they make sure that they are always ready to stand in for him in case of doubt and represent the business side to the team should Lars himself not be available.

But even if he and Svenja are busy with other issues in the course of development, we always maintain communication between them and the team. With full transparency on progress, they decide at each point what will add the most value to their product. Unlike other times, they don’t have to worry about personnel. We take care of fail-safety and the right know-how in the team – always with the guarantee: this team knows each other and works together effectively. With this promise, Svenja and Lars can concentrate on what is important – their idea.

Advantages of the Software Bauhaus concept

From our point of view, the Software-Bauhaus concept has several advantages over self-orchestrated staffing by clients:¹

• We make the vision our own, not only to work in a project, but to identify with it. In doing so, we bear part of the risk together with stakeholders and founders. They have full insight into the product development at all times with a minimum of time. Whether in the role of Product Owner themselves or as the main stakeholder – they receive the necessary methodological support and are always involved as much as they want and are able to be.
• Requirements engineers and UX designers ensure at all times that the team knows all the necessary technical details to be able to work in a goal-oriented manner.
• The composition of the team is always aligned with the upcoming focal points (design, development, operations) and without significant time expenditure for re-staffing or familiarisation; because the employees in the Software-Bauhaus know and understand each other.
• The team members are more motivated and committed than in individually “thrown together” teams, because through the early participation in the discovery phase, they have the “know-why” as well as the self-evident know-how and can thus contribute technical solutions to problems from the technical domain on their own initiative.
• Last but not least, users benefit from this approach. For one thing, the software quality of a constant, well-coordinated team is demonstrably higher than in “loose” project groups. On the other hand, end-to-end responsibility from the idea to operation guarantees better maintenance and care of the software.

Notes:

[1] Detailed information on the advantages of the Software Bauhaus concept can be found at https://qualityminds.com/services/software-development/agile-software-development-teams/.

If you like the article or want to discuss it, feel free to share it in your network.

You can find more contributions from QualityMinds on the t2informatik Blog:

t2informatik develops and modernises software as a service provider. Click here to learn more.