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.
As a feature factory employee, you may be familiar with the following management goal pattern:
“We are rolling out our products in 29 more countries next year.” The fact that it has taken five months for roll-outs in three countries so far does not seem to play a role in the planning. “Our new product has to come onto the market in eight months in order to achieve our sales targets.” The fact that the sales targets were set without even speaking to the product developers is obviously not a problem. In short: an ambitious goal with a time component that was set without any basis.
What should you do with it as a developer? Ideally, you can influence the planning, you can raise concerns that are really heard and taken into account. But what if that’s not the case?
At least you can reduce the foreseeable disappointment caused by the unattainable goal by focusing on your own progress. I recommend the following approach:
Connect the given project goals with your own personal goals. What do you want to achieve for yourself at the milestones and end date? What expertise do you want to build? What personal development would you like to undergo parallel to the project? What progress do you want your career to make or what foundations for progress do you want to lay?
Why does this help make better use of time in a feature factory? I often see developers who are faced with unrealistic goals in unproductive environments. The frustration is great and attempts to improve the situation come to nothing. And yet the focus remains on changing the status quo or endlessly complaining about it. This is followed by resignation of the type, “I’ll just do what I’m told.” Also popular are “You can’t change anything here anyway” and similar beliefs. Most of the time I try to show both my customers and in this blog options for action that… challenge established beliefs. But let’s just assume that “you really can’t change anything.” Then it helps to shift the focus from the deplorable circumstances to personal development.
What is your topic? What would you like to be able to do? What would you like to improve on? Software architecture? Continuous deployment? Test automation? Generation of software documentation? Presentation techniques? Communication skills?
Set goals! Make it concrete and measurable! How do you know you have achieved your goal? There can be different answers to this. Some examples:
Attending a training course, obtaining a certificate, publishing an article in a magazine, or giving a talk at a conference or meetup.
If your topic should (also) help your career, make sure that your goal achievement can be included in your CV. Maybe it belongs in the personnel file so that it appears in the later job reference. In this way, internal company measures can also serve as measurable goals.
Conducting training courses for colleagues. Publishing an article in the company magazine. Don’t you have one? Then: Founding a company magazine. A lecture in a suitable community of practice.
Once you’ve defined your goals, comes perhaps the trickiest part: connecting the goals to the project you’re working on. What’s tricky about it? The argument can be tricky: Why do your own goals and project goals match? If you want to learn to play the violin, it will be difficult to argue. Building test automation know-how should be easier to explain in most cases because the know-how is genuinely useful for the project. Since superiors like to talk about annual goals and the like anyway, there should be no resistance in personal conversations.
If you know your goals and, if necessary, they have been agreed with your manager, the next step follows: Break your goals down into tickets, create them in the backlog and assign them to yourself (I don’t like tickets very early on). Assign to person, but that’s fine for personal goals, right?).
For example, the tickets that do not contain any features or requirements from the client are called “dev stories” or “technical stories” by my customers. I would only name the topics in the tickets, not acceptance criteria. If you want to become a master in test automation, write that down, but don’t mention that your personal goal criteria is to give a talk at a conference. The lecture only serves to measure goal achievement. Only the topic belongs in the ticket. Otherwise, you could rightly be asked what the talk has to do with the project. You should clarify everything that happens outside of actual work (lectures, publications, etc.) with your company in advance. Can you appear at a conference on behalf of the company? If not, take a day off. The same applies to publications.
Once the tickets are in the backlog, it’s just a matter of pulling them; for example in the sprint, if you work like that. When your tickets represent many small steps, you can pursue your own goals with regularity and make progress that means something to you.
(rme)
To home page