Direkt zum Hauptbereich

Posts

Agile product teams

In this article, I’d like to share my condensed view on agile product development teams. It might help you to find your personal role in such a team or even setup a team based on my blueprint, as a team architect. Let me know, if you need any additional input. I’m happy to learn, help and speak about this topic. In the last years, I gained experience in different projects from delivering individual software with a single small team to developing large IT platforms with multiple agile teams (and non agile management) involved. In parallel, I deduced the principles from frameworks, i.e. Scrum, Kanban, Scrumban, LeSS and SAFe , and adapted them to our specific problems in the project. In the following sections, I will cover the process, the roles and responsibilities inside the team and how to combine them as well as supportive methods and tools to develop products. The following drawing provides an overview of these aspects, which I will describe in greater detail below. Agile
Letzte Posts

Leading the agile way

What about leadership in the agile world? Do we still need leaders if we run agile? Due to my experience in agile teams my answer is: "Yes, we need leadership but less managers! " The tasks itself are straight forward. But leading agilely means solving them different, new, agile. That means,no power to micro-managers by transparency. Instead, accomplishment and affiliation driven smart enabler and servant leaders without ego. But this is easier said than done. Lots of stuff is written about working agile. Frameworks, such as Scrum , define the basic team structure, processes and tools about organizing small teams of about 7 people. Other methods, such as SAFe , sketch how to interact between teams and scale agile to enterprise level. And lot’s of best practices (e.g. Spotify engineering culture ) describe how to run agile companies by example. However, I'd like to share my thought on the topic "agile leadership"  I gained from agile projects and teams in the

Umgang mit Stress im Job - für Leader und Gestresste

Die Welt wird immer schneller - durch Digitalisierung. Alles ist vernetzt, immer online immer abrufbar. Und das führt bei uns Menschen zu Stress: Der Chef ist unfähig, der Kollege ist doof, das Teammitglied ist faul. Jedoch machen wir uns den Stress an sich selbst - in unserem Kopf mit unseren Gedanken. Doch auch unsere Umgebung beeinfluss uns. Wie also umgehen mit Stress? Entziehen können wir uns der Welt leider nicht. Wir sind ein Teil davon. Und auch wenn wir über die fortschreitende Digitalisierung schimpfen, wir nutzen sie doch. Also, wie gehen wir um mit dem Stress unserer Welt? Falsche Zusammenarbeit stresst.   In den meisten Fällen erleben wir Stress in unserer Arbeitswelt. Wesentliche Quellen für Stress sind nicht in unserem Arbeitsergebnissen sondern im Zusammenleben zu finden: Leiden unter Streitsucht unserer Kollegen Ausbleiben individueller Anerkennung und Fehlender Teamgeist Es liegt also an unserer Zusammenarbeit und an Kommunikation zwischen uns und uns

Building great APIs - the art of developer experience

Developing successful business by adapting your products to the diverse global market, relies on quick and sustainable technical integration. Hence, designing a great interface (API) is the key for product success today. Classical IT architects, however, don't really care for design, but developer experience people do. I show 5 techniques to design great APIs based on the experience in my last project. Let me start with a story about the importance of integrated systems for customer experience. I'm humanistic nerd and triathlete. So, I enjoy to track and analyze my sport performance. I train with a Polar M400 watch and use training plans from the corresponding cloud service Polar Flow . Now, I missed an additional navigation system to not ride the same track all the time and I'd liked to track cadence, which is, unfortunately, not possible with the Polar M400. However, I neither liked the bicycle computer Polar M460 , since it's just the features of watch in a b

How the new approaches “Agile methods”, “Microservice Architecture” and “Minimum Viable Products” (MVPs) perfectly fit together.

Although the new approaches originate from different disciplines, they share the same two old and well known concepts: Divide & conquer and Inspect & adapt . Why these approaches? – Because we naturally fail. Today’s digital globalization requires highly integrated IT systems with rich functionality. In order to develop and operate such large and complex IT, we cannot simply scale the projects. Instead, we come up with new approaches such as MVPs in product management, Microservices in IT architecture and agile methods in project management. Why these aspects? – Because they are crucial for successful IT products. Product management focusses on the outcome - the IT product – from an external perspective. Whereas IT architecture defines the internal structure of the IT product. And project management considers the people and processes in order to manage limited time, resources and features respectively quality, since products are usually developed as project. Agile

Transformation into micro services still depends on the users needs

Today, we have a lot of monolithic system running. The future system landscape, however, will be micro services – a flexible and scalable architecture. Why we move towards micro services is clear: First, because micro services are more flexible and scalable than old approaches such as monoliths. Second, due to the diversification on operational level, we get a robust system as a bunch of resilient services. The overall system does not stop, if only one services stops working, and it might heal itself. And last but not least, because we can! Can we? How do we actually transform a monolith towards a micro service architecture? Since monolithic are usually build out of modules, my answer is: We transform a monolithic into a micro service architecture based on its modules, which support the users business cases. Background In general, IT facilitates the principle of divide and conquer in order to handle complexity. A large problem is cut into smaller, manageable pieces. Monolit

Emulate wheel with single-button apple mouse

Recently, I reactivated my good old apple mouse. I really love its timeless design and the simplicity of the single button. Yes, there is no second button for right clicks. But no, I’m no brainless apple fanatic. Instead of the buttons there is this brilliant design of utilizing keyboard modifiers, such as control , command or option , in order to extend the functionality of a single key. We are used to this feature for a long time, using command + s to save data or command +q to quit an application. So why not using it for mouse buttons? To me it is consistent to use the same idea for additional mouse buttons. And this is what makes good design, at least to me. But what about the mouse wheel? My good old mouse does not have a wheel. :-/ Well, what about changing the key map such that the movement of the mouse is mapped to the wheel function if I additionally press left command . Fortunately, karabiner allows to change the key map of Os X. So I added the follow