Mein Team führt schon seit geraumer Zeit eine Diskussion darüber, wie man den Prozess verbessern kann. Und das ist auch gut, denn ständige Verbesserung ist ein zentraler Bestandteil jeden agilen Handelns.
Allerdings liegt die Antwort auf die Frage nie in Werkzeugen und deren Möglichkeiten. Um das Problem zu lösen muss dessen Ursache verstanden werden. Jira bietet sicher viele Möglichkeiten, noch ein Feld einzuführen. Wenn die Diskussion sich darum dreht, welches Feld am besten ergänzt wird und wie ein Zustandsübergang abzubilden ist, ist das agile vollkommen aus den Augen verloren.
Eine unmittelbare Konsequenz von Werkzeugen ist, dass sie es Teammitgliedern erlaubt, Verantwortung abzugeben. Der Zustand wird möglicherweise richtig abgebildet, das Feld richtig gefüllt. Nun ist es an jemand anderem das technische Problem zu identifizieren, die Person weiss möglicherweise nicht einmal über den Zustand Bescheid.
Agil soll heissen, das Vertrauen aller Mitglieder im Team soweit herzustellen, dass notwendige Arbeit in Standup Meetings oder spätestens im Review transparent gemacht wird. Dabei kann kein Tool helfen.
Yesterday, a software engineer, also new to the organization, roughly told me the following. The way the organisation plans projects is so different to what he is used to as a software engineer. Planning projects with a horizon of 12 or even 24 months is something he says he just cannot wrap his head around.
While this is very common and necessary in the hardware industry, it is indeed something terribly alienating software people. Software is typically treated as a living product, that takes tiny changes at a time, it is more governed towards a direction to take than having the one exact goal it has to hit by a specific date.
These very fundamental goals both mindsets follow make it difficult for change to happen. While the software engineer above obviously has a point to make, he cannot reach the people he needs to reach, because both sides are just too far apart.
At the same time, I don’t yet have an answer to the problem, but the problem itself became so obvious when this colleague told me he just doesn’t know what to say. The digital world does not yet have a common language, not to mention a common way to think about approaching problems, and unless this hurdle is taken, change will only happen slowly.
The past weekend I traveled internationally to work with colleagues on another continent. I’m a lucky volunteering member of IEEE, and so I reached out to the community before I jumped on my flight.
Turns out I have friends in this city, and so I spent a whole afternoon learning about the city and the eventualities it brings along.
Both my old friend and me agreed throughout our conversation that networking is an important activity, and having built an extensive network is an enormous asset.
While IEEE is only one opportunity to meet people, it is a solid recommendation for engineers to actually pick up this activity in first place, even though it may not seem obvious at the beginning of the individual career. Working with and knowing many people is all too often underestimated and need strong soft skills. But even those can be trained, just like engineering can be tought.
A few weeks into the new role, I’m busy with all the new and exciting responsibilities. Being in charge for a product is fantastic, all along with the rising technology in the Internet of Things makes it a really unique experience. Also the approach to the market broadens my horizon and there are so many things I should be writing about, but cannot find the time. Also, a new article for the TEMS Leader is in the making, which keeps me off nomorecubes.
The project is not abondoned yet, though, just like it had ups and downs over the years.
Everybody hates management-speak and corporate jargon, but here are some terms that people used to think of as horrible jargon that we all got used to. Maybe one day we’ll all be leveraging deliverables without a secon