von Diana Kruse

Wir Quality Specialists schauen nicht nur über den teameigenen Tellerrand, indem wir uns in bereichsweiten Formaten wie QS-OpenSpace, QS-Conventions und Fokusgruppen rund um das Thema Qualität austauschen. Wir strecken unsere Fühler auch konzernweit und über den Konzern hinaus aus.

In diesem Beitrag möchte ich kurz über die QConf sprechen, der jährlichen konzernweiten Konferenz für alle Software-Qualitäts-Interessierten der otto group.

Seit dem letzten Jahr haben sich die einzelnen IT-Bereiche stark weiterentwickelt. Konzernweit spiegelt sich in etwa das wider, was ich auch am Markt verfolge: Es gibt Bereiche, die noch am Anfang stehen, was agile Software(Qualitäts)Prozesse angeht. Andere, wie wir bei otto.de, leben und verändern diese schon seit einigen Jahren.

Die QConf in Zahlen

750
Feedbackzettel
70
aktive Teilnehmer
17
Stunden Softwarequalität
16
Speaker / Workshopleader
4
Sponsoren
4
Orgas
1
riesiger Raum
Jeder Bereich steht somit vor anderen Herausforderungen und doch macht uns ein Gedanke alle gleich:

„Wie können wir unterstützen, dass qualitativ hochwertige Software an unsere Kunde geliefert wird?“

Von Natalie Volk, Finn Lorbeer, Diana Kruse, und Torsten Mangner

Bei otto.de gibt es in jedem Cross-Functional-Team mindestens eine Testerin / Testmanagerin / QA / QSlerin… wie auch immer man die Rolle der Person bezeichnet, die Bewusstsein für Qualität schaffen soll.

Bisher dominierte die Bezeichung „Testmanagerin“ – ein sehr hölzerner, bürokratisch klingender Titel. Dieser sollte deutlich machen, dass die Rolle mehr tut, als nur Tests durchzuführen: Sie managed Tests! Mittlerweile ist auch das managen von Tests nur noch ein kleiner Teil des Mehrwerts, den wir im Team erbringen.

Having successfully reimplemented our e-commerce website www.otto.de in a highly decentralised, agile project approach, we currently face the challenge of establishing an agile mindset outside the cosy cheese dome of a well-protected and well-specified project. During this project we felt like living on a separate planet. Business and technology work entwined, scope was managed by ourselves, we had the liberty to change and adapt our processes and methodologies, introduced an agile management framework, implemented Scrum, built autonomous and cross-functional product development teams and closed feed-back loops with continuous integration and delivery. Or putting it a different way: we learned how to change into a learning matrix organisation. This process was thrilling, demanding to all of us and we are proud of having mastered this challenge. After leaving our project “Lhotse” behind and literally lifting our project cheese dome, we are now facing an urge to change management culture and improve our capability in inter-organisational collaboration.  

In this blog you will find a lot of information on how we implement code for our shop in the best way. But in some cases we also buy commercial standard software, for instance for components which give us a faster time to market or which cannot be implemented by us in a better or more cost effective way.

Another reason to buy software is data exchange with external systems using standard interfaces when there are products on the market which have already implemented those interfaces.

Additionally, we want to improve experience in using software as a service (SAAS).

In the past months some of my team members and me had several workshops with different vendors to find commercial software components for some parts of our ecommerce platform. Independently from concrete products and vendors, we made some good and some not so good experiences in presentations held by vendors to help us find what we need. And that is what we want to share in this article.

So, read this carefully if you are a software vendor 😉

The term Commitment was removed from The Scrum Guide (pdf) and replaced by the term Forecast back in 2011. Here is my rant against the concept of commitment as it is still used by many otherwise agile teams. If you don’t do scrum, but any other development method that ties a fixed set of development tasks to an iteration, then this article is also for you. You must not mistake ceremonial commitment with the commitment of individuals and teams to deliver excellent work. We all agree the latter is a great and desirable thing. In this article I am only talking about the former.

Sprint commitment means, that a team of software developers have to commit to finishing a fixed number of stories in the next iteration. I guess the hope often is, that due to the pressure created by such a commitment more stories are developed per time unit. I also heard the reasoning commitment would improve planability of a development project or that it increases the motivation of developers. I think that is all wrong.