Moin.
Advertisement
(Bild:
Stefan Mintert
)
Stefan Mintert works with his customers to improve the corporate culture in software development. He currently sees the greatest potential in leadership; regardless of a hierarchy level. He gave himself the task of leveraging this potential after a career path with a few changes of course. Originally coming from a computer science background with several years of consulting experience, he initially founded his own software development company. He discovered that leadership has to be learned and good role models are rare. It became apparent that the greatest need for support from his customers in software development was not in producing code, but in leadership. So it was clear to him where his company Kutura was headed: improve leadership so that the people who develop the products can develop and grow themselves. Stefan has been writing for Heise as a long-time freelancer for iX since 1994.
Sometimes people ask me what’s so bad about developing features. There’s nothing wrong with it if there’s someone who wants and needs the features. But is this actually the case in your own work? This is hardly noticeable in the proverbial feature factory. For many people, it doesn’t feel right to be churning out tickets that third parties say are useful. Assessing how valuable your work is can be difficult for many reasons. One reason: You don’t work on a product, but on a component of a product.
I like to use the (simplistic view) development of a car as an example. Assume that development takes place in three teams: one for the engine, one for the body, one for the chassis. If each team is just doing their own job and the complete car is nowhere to be seen, it’s not actually car development. In each of the three reviews only individual components can be seen and they do not solve the original problem (“Get people from A to B”). You also can’t ask (car) buyers how they find the status of the car.
For internal company stakeholders who are interested in the car, this means they have to go through three reviews and use a little imagination to mentally integrate the components.
I think this way of working is so absurd that I always think that companies are long past this stage. In the agile context, the scaling frameworks help each other to avoid, among other things, the scenario described. However, I still encounter isolated component teams. So the question arises, what can I do as a member of such a team to get out of the silo?
Here are a few tried and tested suggestions:
First. Go to the reviews or similar meetings of the other component teams. If you have to cross carefully constructed silo boundaries (aka department/team boundaries), your sensitivity is required. It can happen that other people are irritated. In such a case, I first politely ask if I can listen. That’s mostly ok. I only very rarely encounter rejection.
It is also good to pay attention to how the teams have been coordinated so far. Who carries the information from one side to the other? Who cuts the tasks into component tickets? Many roles come into question here. Maybe the product owner or a software architect does it? Talk to this person to avoid stepping on their toes!
In the second step, you can invite colleagues from the other component teams to your review. This can then lead to irritation among your own people. Here too, it helps to prepare the ground beforehand. Tell your teammates that you would like to get feedback from neighboring teams during the review.
Once both behaviors are accepted, the next step is to try to organize or be invited to a meeting where you can admire the complete and integrated product. In many cases this already exists because, after all, someone has to do the integration. If there is a QA department, a testing department, or similar, it’s a good idea to find out about their work. Maybe that’s where integration takes place.
In rare cases I have experienced that there was no proper integration during development. The plan was that the integration would only take place once all components were ready. The focus was on working on the interfaces and the component teams tested exclusively against mocked interfaces for a very long time. I hope this is the exception.
Conclusion
With any luck, this blog post won’t be of interest to anyone. However, I am amazed to see that there are still companies in which multiple teams work on a product or service without the team members being able to have their own(!) experience of the entire product they are working on. But no one has to wait for the next reorganization of the company.
Don’t stay alone in your team, build your internal company network and exchange ideas with the other teams! It’s not just product development that will benefit. You also feel much better when you experience your own contribution in the context of the integrated product. (rme)
To home page