Good morning.
Advertisement
(Picture: stephan mintert ,
Stefan Mintert works with his clients to improve corporate culture in software development. He currently sees the greatest potential in leadership; Regardless of hierarchy level. He set himself the task of taking advantage of this ability with some career changes. Originally coming from a computer science background with many years of consulting experience, he initially founded his own software development company. He found that leadership has to be learned and good role models are rare. It became clear that their customers’ greatest need for support in software development was not in producing code, but in leadership. So it was clear to him where his company Kutura was going: Improve leadership so that the people developing products can grow and develop themselves. Stefan has been writing for Heise as a longtime freelancer for iX since 1994.
Are you also operationally blind? Silly question, right? If you knew this, you wouldn’t be blind to the company. So the answer can only be: it can.
I encounter operational blindness in software teams in the form of working agreements. If they are known to every team member, ideally well documented and actually practiced, they are valuable and useful. But there are still procedures, rules and traditions that are that way because they are Always Were like this. Or the root cause has been forgotten. It’s also popular to mindlessly adopt best practices you’ve learned from somewhere.
An example of my own operational blindness: In 2010, Vincent Driessen wrote an article titled “A successful git branching model” wrote. His suggestion was named gitflow. I read the article shortly after it was published and was immediately convinced. We took this same approach in our team at the time and it helped us move forward.
It depends on the context
In the years that followed, I recommended Gitflow here and there. Some teams adopted it, others did not. This is normal. However, one thing is often overlooked: what problem do you really want to solve? And how well does it actually work with the proposed approach?
In short: Looking back, I suspect that Gitflow was implemented by my recommendation too often and sometimes for no logical reason. It wasn’t until a developer once told me that Gitflow was not a good choice for their team because… I realized that I had repeatedly and unthinkingly used something that worked well in a certain environment in new contexts or was recommended as one of the best practices; today i don’t believe anymore Best Practice.
I’ve noticed the same principle with some customers. I think this is human nature, and it’s generally a good idea to stick to tried and successful practices. never change a winning team This is not a meaningless phrase. Otherwise you will question everything every day and achieve nothing. Unfortunately, sometimes the context changes and so-called best practice is no longer even good practice.
asking questions helps
To prevent this from happening, I recommend spring cleaning your work contracts. This means: Over a period of a few months or perhaps a year, a team should question the known and invisible working agreements:
- How do we work together?
- What does value creation look like in our team?
- How do needs, desires, stories and ideas come to fruition with our help?
- What are the intentions behind this and are we (still) achieving the goal?
They can also be very specific questions, which of course vary from team to team, for example:
- How will we handle hotfixes? Why like this? What goal do we want to achieve and will we achieve it? How else can we achieve our goal? Which method is better?
- We have been doing test-driven work without compromise for five years. Why did we introduce it? Does it work? Do we still need it today? What will happen if we relax the rules?
- Analog: What coding rules do we have? Why? For what reason? ,
When questions like this are asked, sometimes it is clear that there is no common understanding within the team for individual working agreements; So there really is no consensus. Then it’s not initially about the question of what is good and what is bad, but more fundamentally: how do we actually do this as a group?
You don’t need a team leader, manager, or coach to ask these questions and test working agreements. All you need is a dedicated developer and away you go. You suggest topics in Daily or set appointments in Calendar. If you choose a formulation that arouses curiosity or is even provocative (“never test-driven again” or “only test-driven from now on”), responses and participation are likely to be higher.
lessons learned
Dialogue within the team should question fixed opinions and established beliefs. You can also learn this from the above example of my own operational blindness:
While Gitflow became very popular in its time, years later it clearly became considered bad across the board. If you search this word on Google today, you will find, among other things, a word Article from AtlassianWhich states in the introduction: “Gitflow is a legacy Git workflow that once represented a disruptive and innovative strategy for managing Git branches.”
I don’t recall Gitflow ever being worthy of the adjective disruptive; But the terminology is at least somewhat appropriate for the popular term bingo. I am more critical of the classification as an older and earlier novel. What role does age play? Perhaps 20 years from now there will still be teams and functions that can work excellently with Gitflow. It’s not about old or new. There are no best and worst practices. Rather, it’s about how appropriate something is for an individual use case and context. Each team can evaluate it as best it can for itself and question the agreements previously made at larger intervals. Especially when the reasons and context of the decision have been forgotten. Off to spring cleaning!
read first, then listen
on podcast Escape the Feature Factory I take selected topics from the blog and discuss them with the guest. Through exchange I discover another perspective. The podcast is available here spotify, Deezer, amazon music, apple podcasts and above kutura.digitalThere you will find, among other things, workshopsWhich address the topics of the blog.
(rme)
