Kay Liewald

Heute soll es um die Werte in Scrum gehen. Ich glaube, dass gelebte
Werte in der Teamarbeit eine absolute Grundvoraussetzung für ein High
Performing Team sind.

Zum Einstieg möchte ich mit ein paar kurzen einleitenden Worten zu den
Scrum Werten beginnen. Wenn euch das neugierig macht, solltet ihr
unbedingt den kurzen Methoden-Montag Podcast dazu anhören! Mit Jan und
Florian stelle ich euch dann meine neue Idee zu den Werten in Scrum
vor...

Für mich spielen Werte in der agilen Transformation eine ganz
entscheidende Rolle. Scrum ist nicht nur ein Framework, das einen
bestimmten Workflow beschreibt, sondern besteht auch aus Prinzipien und
Werten. Ich finde, ohne die Werte fühlen sich die Events in Scrum (die
Meetings) wie eine leere Hülle an. Mein Ziel ist es, den Mensch immer in
den Mittelpunkt zu stellen. Wenn wir es schaffen, die Werte Offenheit,
Mut, Respekt, Fokus und Commitment in unseren Teams zu leben, dann
schaffen wir es auch das gesamte Team auf die agile Reise mitzunehmen.
Für mich als Scrum Master und Agile Coach ist es wichtig, dass die Teams
über die Werte diskutieren, um sie erlebbar zu machen & damit sie ihren
individuellen Zugang zu den Werten finden:

[Zur Podcast Episode mit
Kay](https://plus.rtl.de/podcast/methoden-montag-7pgphbwyfhj94/werte-einfach-besprechen-mit-kay-liewald-t6ykmvpcz2849)


Heute soll es um die Werte in Scrum gehen. Ich glaube, dass gelebte Werte in der Teamarbeit eine absolute Grundvoraussetzung für ein High Performing Team sind. Zum Einstieg möchte ich mit ein paar kurzen einleitenden Worten zu den Scrum Werten beginnen. Wenn euch das neugierig macht, solltet ihr unbedingt den kurzen Methoden-Montag Podcast dazu anhören!

Werte bei Scrum

In dem Podcast [„Code for
thought"](https://codeforthought.buzzsprout.com/) erzählen Kristine
Schima-Voigt und Kay Liewald über unsere Erfahrungen mit agilen Methoden
in der Gruppe Software- und Serviceentwicklung an der SUB Göttingen.

[Peter](https://fosstodon.org/@code4thought) von „Code for thought"
wurde auf der [„Conference for Research Software Engineering in
Germany"](https://de-rse23.sciencesconf.org/), kurz deRSE, auf uns
aufmerksam. Wir von der Gruppe Software- und Service Entwicklung
sprachen dort in Vorträgen über [agile Softwareentwicklung im
wissenschaftlichen Kontext](https://zenodo.org/record/7727988) und
[unsere Arbeitsweise in Scrum](https://zenodo.org/record/7715041). Scrum
ist eine Projektmanagementmethode, die in der Softwareindustrie sehr
weit verbreitet ist und auch in anderen Bereichen bereits Einzug hält.
Im wissenschaftlichen Kontext ist sie jedoch noch die Ausnahme. Während
der Konferenz gab es viele interessierte Nachfragen: „Wie macht ihr das,
in eurem Bereich agil zu arbeiten?"

Einer der Interessierten war Peter, der uns fragte, ob wir nicht Lust
hätten, einen Podcast mit ihm aufzunehmen. Wir haben mit Scrum gute
Erfahrungen gemacht und tauschen uns immer gerne darüber aus. Natürlich
gibt es auch kritische Stimmen zu Scrum und auch bei uns hat nicht alles
von Anfang an reibungslos funktioniert. Auch heute arbeiten wir
fortlaufend daran, unsere Arbeitsweise zu verbessern und den Prozess
ständig anzupassen. Das ist immer ein wichtiger Teil des agilen
Arbeitens. Uns hat Scrum in vielen Bereichen sehr geholfen, sowohl was
die Projektergebnisse als auch die Kommunikation und die
Arbeitsatmosphäre in den Teams betrifft. Grund genug, uns mit Peter
einmal darüber zu unterhalten, um andere Teams an unseren Erfahrungen
teilhaben zu lassen.

Falls euch das neugierig macht, [hört doch einfach mal
rein](https://codeforthought.buzzsprout.com/1326658/12932362) ...

Die angesprochenen „Eieruhren" sehen übrigens so aus:

![Eieruhr](/assets/images/podcast/timebox.webp)

<figure>

<figcaption>Agil in der Wissenschaft</figcaption>
</figure>


In dem Podcast „Code for thought“ erzählen Kristine Schima-Voigt und Kay Liewald über unsere Erfahrungen mit agilen Methoden in der Gruppe Software- und Serviceentwicklung an der SUB Göttingen. Peter von „Code for thought“ wurde auf der „Conference for Research Software Engineering in Germany“, kurz deRSE, auf uns aufmerksam.

Podcast „Code for thought"

Ingo Pfennigstorf

I just stumbled over a nice
[post](https://blog.codecentric.de/en/2018/05/agility-its-a-mindset-not-a-process/)
and became inspired writing about agility in our teams, how we got
there, how we use it and how it may fail.

The intellectual foundation for becoming agile in a software development
group, is to internalize the "[Manifesto for Agile Software
Development](https://agilemanifesto.org/) ".

## Starting the transition

We started off with a new project about 4 years ago and some people that
were keen on changing the way we worked in the past. How did we work in
the past? Well, our issues were mainly too long lasting projects, bugs
and implementations the way the customer didn't want to have them. In
many projects only one person was responsible for everything, from
talking to the customer to get the requirements, to coding everything.
That didn't work out and the need for a change emerged.

To have a scaffold for the colleagues we chose
[Scrum](https://www.scrumalliance.org/learn-about-scrum) as an agile
framework. With the introduction of Scrum we established the groundwork
for the agile way. We embraced daily stand-ups, sprint plannings,
reviews and retrospectives. Project leaders became "Product Owners", a
"Scrum Master" role was created, as well as everything that was useful
to become agile.

For sure, there were concerns having much more meetings than before, but
all these meetings are well established and part of our agile success,
and also the customers were quite happy to be involved and have results
after each iteration (sprint).

## Technical Issues

One principle of the Agile Manifesto is

> Our highest priority is to satisfy the customer through early and
> continuous delivery of valuable software.

With that in mind, we created environments to make it easy for
developers to add their code to the main code repository, that
automatically gets deployed to a development server, where all team
members and the customers may see the current state of the project at
any time. Tools such as *git*, *Vagrant*, *Jenkins* helped us initally,
but our development and production infrastructure are also victims of
the agility, so we dropped *Vagrant* in favour of *Docker*, that we use
in development and production, and replaced *Jenkins* with *Gitlab CI*.

So, for keeping this part short, each change in the source code
repository is available on a server in a few minutes. Getting everything
that was done in a sprint onto a live server is just a
`git tag`{.language-plaintext .highlighter-rouge} and
`git push --tags`{.language-plaintext .highlighter-rouge} command away.

## Human Issues

All these artifacts and technical wizardry are worthless, if the mindset
is a fixed one, as described in the article mentioned above. Solving
this may become hardest task in the agile switch. Agile Evangelists,
Coaches and Scrum Masters can help there, but it's also on the team
members to continuously learn about new things in their area, that
change is not a negative thing and failure is a great way to become
better and better in the job they do.

## Are we done yet?

Never ever! One of the key principles is to inspect and adopt the way we
work, become better and resolve the things that don't make us happy
developers.

I want to conclude with the headline of the article that inspired me for
writing this one:

**Agility: It's a mindset, not a process.**


I just stumbled over a nice post and became inspired writing about agility in our teams, how we got there, how we use it and how it may fail. The intellectual foundation for becoming agile in a software development group, is to internalize the “Manifesto for Agile Software Development “. Starting the transition   We started off with a new project about 4 years ago and some people that were keen on changing the way we worked in the past.

Messaggi di Rogue Scholar

Werte bei Scrum

Podcast „Code for thought"

Agility