Clarity and orientation in software development

‘I need to understand. Always.’

I adopted this principle a long time ago. It has helped me in many situations, such as with difficult issues in software development, unclear requirements, conflicting expectations, technical dependencies, lack of prioritisation, conflicts between team members and scarce resources. In all these cases, one thing is clear: what counts is clarity. This clarity provides orientation and enables action. It helps managers and employees alike.

As a manager, you can make a difference through your own understanding. When you gain clarity, you create the basis on which those around you make decisions, take responsibility, and develop viable solutions.

The following guide shows you how to make complex situations visible and tangible. Step by step, you bring structure to problems and open the way to solutions. It starts where everything begins: with a clear view and genuine insight.

Guide to greater insight and clarity in software development

Complex situations often seem chaotic and unmanageable. The following guide will help you bring order to this chaos. It consists of four steps that are deliberately kept simple yet have a profound effect. By understanding situations, revealing connections, identifying the core issues and analysing them systematically, you can create a common understanding. This understanding is the basis for clarity, orientation, and sound decisions.

Step 1: Assess the situation

Start with a complete overview. Make the invisible visible by gathering all relevant elements.

• Give the topic a name and write it in large letters on a whiteboard, flipchart, or A3 sheet.
• Ask the question: Who or what is involved? For example, people, roles, teams, departments, objects or components.
• Write down each element on a separate sticky note. In addition to the name, add the type, such as person, team, role, object or component. Optionally, you can add a symbol so that the type is immediately recognisable.
• Check whether anything relevant is missing and add to the diagram if necessary.

Step 2: Make connections visible

Show how the elements relate to each other and bring order to the picture by visualising dependencies.

• Question: How are the elements connected?
• Draw the connections.
• Label the connections with relevant details.
• Arrange the sticky notes so that as few lines as possible overlap.

Step 3: Localise the topic

Focus on the core of the problem by marking the crucial points and making the actual topic tangible.

• Question: Where is the topic, problem or challenge visible in the visualisation?
• Mark these points directly in the diagram.
• If you cannot clearly mark the topic, relevant elements are probably missing. In this case, return to step 1 and add them.

Step 4: Analyse systematically

Now examine in detail and clarify responsibilities, dependencies and uncertainties in order to reveal causes and starting points for solutions. To do this, ask the following questions:

• What tasks, responsibilities or competences does this element have?
• Which tools or technologies are relevant?
• Are there any ambiguities or uncertainties?
• Are all dependencies to and from this element clearly named and defined?

And for each connection, ask:

• Are the details of this dependency clarified, for example, time requirements, sequence, data, information, communication channels, protocols or technologies used?

Note any ambiguities directly on the visualisation, because this is often where the true causes of problems and conflicts lie and, at the same time, the first starting points for viable solutions.

Practical example: A product owner at their limit

To make the method more tangible, let’s look at an example. It shows how an overworked product owner gains clarity through the four steps.

Step 1: Assess the situation

First, take a look at the issue: ‘Backlog chaos and lack of planning reliability’. Then collect all the elements involved:

• product owner
• project managers for products A, B and C
• development team
• platform
• shared backlog
• backlog item

Write each of these elements on a separate sticky note and add a symbol so that the distinction is immediately visible.

Figure 1: Assess the situation

In the next step, you make the dependencies clear. You draw the connections and label them:

• Project managers A, B and C enter requirements into the backlog.
• The backlog feeds the work for the development team.
• The product owner prioritises the backlog items.
• The product owner plans the next versions and sprints.
• The development team works on the platform and creates new versions.

This creates a picture that makes the connections clear.

Figure 2: Making connections visible

Now focus on the actual problem areas:

• There is no joint prioritisation; the product owner cannot and should not prioritise alone.
• The project managers do not coordinate with each other. Before requirements are added to the backlog, synergies could be exploited and common features for several products defined. This responsibility should not lie solely with the product owner.
• The planning of the next versions and sprints is not coordinated with the project managers. They do not know when their wishes and features will be implemented.

In this way, you highlight the critical points and create a clear basis for the subsequent analysis.

Figure 3: Localise topic

In the final step, you go into detail and examine the individual elements:

• Product owner: What responsibilities do they have, how do they decide on prioritisation and with whom do they coordinate?
• Project managers A, B and C: What responsibilities do they have, how do they influence prioritisation and how do they ensure that their requirements are implemented?
• Development team: How do they deal with different requests and how do they ensure that project requirements are implemented in platform features?
• Backlog: How is it structured?
• Backlog item: What information does an element contain, is it ready for implementation, and how are similar requirements from different projects made visible?

You also take dependencies into account:

• Are there rules for how items are added to the backlog and prioritised?
• Are criteria defined for selecting the development team’s work, such as definition of ready or priority?
• How are versions planned?

Note any ambiguities directly on the visualisation.

Conclusion from the example

The analysis reveals the key obstacles:

• A backlog without clear responsibilities
• No binding procedure for prioritisation
• Project managers who submit requirements and lose transparency
• Platform development that lies almost exclusively with the product owner and the development team, even though the projects’ perspective is needed for common features and variants

The four steps described above will help you lay the foundation for targeted improvements: clarify roles, define prioritisation processes, systematically manage requirements and variants, and make the planning of platform versions transparent. Sounds good, right?

Final thoughts on clarity and orientation

The example comes from an organisational situation involving a product owner, but the four-step guide is equally applicable to other roles or areas of responsibility, design issues, architectural decisions or bugs that are difficult to trace. In all these areas, you as a manager can provide support, guidance and clarity.

Clarity is key: it reveals connections, reduces uncertainty and opens up paths to meaningful solutions. If you adopt the principle of ‘I must understand. Always.’, you will not only gain insight yourself, but also enable those around you to act effectively and make better decisions. Give it a try.

Notes:

The complexity of projects, especially software projects, is constantly increasing due to growing diversity, dynamics and networking. Employees with different backgrounds have to work together effectively to achieve the project goals. It is becoming increasingly difficult to maintain an overview.

Matthias Kuenzi is happy to help you bring structure, systematics and methodology to your undertakings. If you are interested, just talk to him. And if you are interested in smooth software development and well-designed software, then it is worth taking a look at the blog of visuellklar.

And if you want to gain even more insight, we recommend the Fuehrungszirkel Software-Navigator.

Would you like to spread the word as an opinion leader? Then feel free to share this post within your network.

Matthias Kuenzi has published two more articles on the t2informatik Blog: