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.
In the good old days, when agile teams worked together in one place, boards consisted of boards that could not only be written on, but also used with magnets. Tickets were made of paper and for each team member there was one (and only one) magnet on which a photo of the person in question was stuck.
Every now and then someone would get up, move a card to another column, drag a ticket from “To do” over to “In progress” and – most importantly – fix the card with their own magnet. It was clear to everyone who was working on what. One look was enough. Cards in “To Do” were tasks for the team; everyone could use them freely.
Today, teams work with Jira, and some believe the equivalent of the magnet is the Assignee field. Not even close. What I’m observing today looks like this:
Team A assigns the tickets to people in sprint planning. Sometimes each developer already has “his” ten tickets in planning. In team B, a developer puts together “his” sprint before planning; After a few minutes he says in planning with an undertone that is reminiscent of “do what you want, I’m out”, something like “Well, my sprint is already full.” Team C understood the cross-functional teams to mean that work packages tailored according to the individual skills of the team members. And then you can assign the assignee in the refinement.
Overall, I can say that for years I have invariably seen teams where people have dozens of magnets (aka assignees). Or, as I see it, they become possessed by the magnets.
Your own likeness is emblazoned in countless places and says: “Work faster in the feature factory, the assembly line runs and runs and the next tickets are already rolling towards you!”
Sprint goals, teamwork, value-generating work? I don’t have time for this nonsense, I have to implement it.
If you want to get out of the feature factory, you should try the following; Combining the suggestions is permitted:
Each person may appear as an assignee at most once at any time. Assignees only exist in the columns in which actual work is being done (“In progress”, “Pull request”, “In testing” or similar); definitely not in “To do” or earlier.
Both proposals require discipline. It’s great, but it usually doesn’t work when people are involved. So here’s the ultimate tip:
Delete the “Assignee” field in Jira. Radical? That depends on what it is used for. If it’s just to fill the assembly line in the feature factory, then: get rid of it!
Bye. Stefan
(rme)
To home page