Der weltweit tätige Agile Coach Ben Linders hat ein Self Assessment Kartenset als Unterstützung für Retrospektiven entwickelt. Ich habe die deutsche Übersetzung erstellt, inklusive der DevOps Erweiterung, so dass wir über einige Aussagen der Karten ein interessantes Gespräch (in Englisch) führen konnten.
In this podcast, Dierk Söllner interviews Ben Linders, an expert in Agile and DevOps practices, living in the Netherlands. They delve into the nuances of DevOps, its broad collaborative approach within organizations, and the intersection with Agile methodologies. Ben introduces his Agile Self-Assessment Game, a tool designed to foster team improvement and discussion. He shares insights into cultural differences in Agile implementation, the importance of commitment and psychological safety within teams, and the effectiveness of various Agile practices across different organizational contexts. The episode is a rich exploration of Agile and DevOps concepts, emphasizing practical tools and strategies for enhancing team performance and collaboration.
Inhalt
- Introduction of guest Ben Linders
- Definition and discussion on DevOps
- The Agile Self-Assessment Game by Ben Linders
- Role of gamification in business and team improvement
- Importance of collaboration and communication in organizations
- Agile methodology, including practices like Scrum and Kanban
- Culturally diverse implementation of Agile practices
- Team dynamics, commitment, and psychological safety
- Practical Agile tools and techniques for teams
- Celebrating successes and creating a safe team environment
Transkript (automatisiert, daher keine Gewähr 🙂 )
devops auf die ohren und ins hirn ein podcast rund um devops von Dirk Sölln
hallo und herzlich willkommen zum devops podcast auf die ohren und ins hirn wir haben zum zweiten
mal jetzt einen englischsprachigen gast so dass ich jetzt auch auf das englische wechseln werde
also für die deutschsprachigen zuhörer hello and welcome to the devops podcast auf die ohren und
ins hirn which means devops right to your ears and into your brain this is the second podcast
for the german series with an english speaking guest the first one was rob england and now
welcome ben linders he will introduce himself so i will pass it over ben could you please
introduce yourself
to the listeners yes thank you derek i’m ben linders living in the netherlands i’m a trainer
coach advisor author and speaker so most of time now i’m working together with organizations and
teams to train them into increasing their agility helping them to find ways to improve their way
of working it’s a mixture of training and coaching i’m also advising organizations
on how they are doing software development finding new ways to to do that finding ways
to improve their performance and i’m also author of a couple of books and a speaker
at conferences i also do a lot of workshops and mini workshops at conferences so most
of the talk is focused on topics like deploying software development management practices
continuous improvement collaboration communication and professional development and the main focus
is there to help individuals using software development design modeling also my main
focus is in performance agreement and internship with digital technologistsWhat Heavyこう
help people to improve their value within the organization and to improve the value that
the organization is delivering as a whole to their customers and stakeholders
all right that sounds good and i think i will place your your website link to the show notes
so every kind everyone can can read and look for your um for your products and for your services
after having heard this podcast so we came together because i found a gamification part
on your website we will talk about this one about the agile and assessment cards but
first of all all of my guests i asked them to define or describe devops
it’s a devops podcast so how would you define devops well i think defining
i would like to do it in a way that is actually not limiting because that is actually one of the
strengths of devops that it’s about connecting people so there’s two things which stand out on me
first of all devops meaning collaboration broad collaboration within the organization
and it initially started as having people from development from operations working together
but i i would to see it as as a general theme of
finding ways to increase the collaboration within your organization not not just limited to people
from developers or operations but for anybody involved in the development chain of products
to improve their collaboration improve their communication the reason being that i think
that key aspects for organizations to to improve their results are mostly focused around this
collaboration and communication parts and this is where devops provides the culture provides the
boundaries to help the neural network we lead the mental promoting the split yourself to
transform ourselves the ways we just came up with devops means and also provides the techniques
to to do this in the organization right that’s it sounds good we came together because you developed
the gamification to help customers to help companies to improve their work
maybe you should describe
what you
auf meinem Website, welches sich als DHL-Self-Assessment-Game nennt.
Ich habe den Namen Game in einem Titel benutzt, aber wie bereits erwähnt, ist es vielmehr
Gamification, das bedeutet, dass es die Anwendung von Mindset-Techniken aus der
Gaming-Welt in die Business-Welt bringt, um Organisationen zu helfen, um Teams sich zu verbessern.
Die Self-Assessment-Parte dieses Games betrifft das Bilden und Verständnis, wie man
sich in der Organisation befindet.
Selbst-Assessment betrifft den Fokus auf die Leute, die ihr eigenes Assessment machen, anstatt
ein externes Assessment zu haben oder einen Auditor in die Organisation oder zu ihrem Team zu kommen
und darauf zu achten, wie sie es machen.
Also ist es tatsächlich die Bildung von Fähigkeiten für Teams, um, wenn man den DHL-Term benutzt,
darauf zu achten, wie sie es machen, aber in einer Art und Weise, dass sie wissen können,
was ihre echte Leistung ist und in einer Art und Weise, dass sie wissen würden, was sie da verbessern.
Die andere Sache ist, dass es sich darum handelt, wie man sich als Team verbessern kann.
Ich bin mehr in Agile verwendet als ein Mindset und ein Konzept, nicht so viel wie ein bestimmtes
Prozess oder eine Art und Weise, wie es funktioniert.
Manche Leute denken vielleicht an Scrum, wenn sie Agile sind.
Das ist sicher nicht der Fall und tatsächlich gibt es viele Ausstellungen, die verschiedene
Methoden für diese Karten bieten.
Ich denke eher an Agile als eine Art, die für mich eigentlich Grundsatz ist, Software
zu entwickeln, das zusammenarbeiten ist, es in einem kurzen Zeitraum macht.
Das heißt, es geht darum, die Art und Weise zu verbessern, wie du dein Software-Development
kontinuierlich machst und darauf konzentriert bist, die Leistung deiner Kunden zu erzeugen.
Okay, richtig.
Also, du hast ein Kartenset entwickelt, bis zu 52 Karten für die Agile-Parte und es gibt
einen DevOps-Extensionen-Pack mit 26 Karten.
Also, wenn du es für DevOps-Karten nutzt, haben wir 76 Karten, nur um selbst zu prüfen,
richtig?
Ja, das ist richtig.
Es gibt tatsächlich auch ein DevOps-Extensionen-Pack für Scrum, welches, wenn ich mich nicht
verletze, 39 Karten hat und es gibt auch ein DevOps-Extensionen-Pack für Kanban, welches
tatsächlich 52 Karten hat.
Der Grund dafür ist, dass es so viele gute Praktiken in Kanban gibt, die sich darauf
konzentrieren, wie du dein Werk machst und wie du es verbessern kannst, dass es mir die
Möglichkeit gab, viel mehr Karten für Kanban zu machen.
Also, wenn du das totale Set von Karten nimmst, dann hättest du ungefähr 200 Karten für
Kanban.
Was, übrigens, viel zu viel ist, um ein Spiel mit ihnen zu spielen.
Richtig.
Du kannst Wege für das oder das spielen.
Genau.
Also, was ich immer sage, wenn Leute mit diesem Spiel spielen wollen, ist, dass das erste
Ding ist, darauf zu konzentrieren, worauf du dich gerade konzentrieren willst und dann
ein Subset der Karten zu machen, die du in dieser bestimmten Situation nutzen willst.
Also, präsentiere deine Karten vorher, bevor du ein solches Spiel mit ihnen spielst.
Ja.
Also.
Und für die Agile-Parte und den DevOps-Extensionen-Pack?
Ja.
Für die Agile-Parte und den DevOps-Extensionen-Pack.
Ja, also für die Agile-Parte und den DevOps-Extensionen-Pack.
Da sind mehrere Sprachen verfügbar und die deutsche Extension, die deutsche Translation
dafür wurde von mir erledigt, also danke dir für die Chance, dein Werk zu übersetzen
und es für Deutschland verfügbar zu machen.
Also, danke dir für das Übersetzen der Karten.
Richtig.
Also, ich denke, es war sehr, es ist sehr beeindruckend, glaube ich, weil es einige
grundsätzliche Fragen gab, die nicht diskutiert werden sollten.
But there are some questions and some points on your cards.
I think we can talk about it.
And because talk about your experience, maybe all over the Europe part or all over your customers.
So I want to open up the mind and the experience from Germany to all the other countries you are supporting.
So we may start with Agile Card 3.
And that’s the statement or the question.
The team is committed and takes responsibility for delivery.
Okay, right.
So that’s just the appointment.
But what if not?
What if there’s no commitment?
What if the team does not take commitment and does not take the responsibility?
Well, actually, if the team is not taking this commitment, then there’s some gray area in commitment.
We can go into that a little bit later.
But the team.
It’s not saying, okay, we want to do the best we can to deliver value to our customers.
And we’re focused on delivering that stuff.
I think it’s one of the basic principles of Agile.
And actually, it’s the basic principles of doing work that is valuable for somebody.
You want people to really be involved in the work and to really know why they are doing it and to understand their customers
and deliver something that will be valued to their customers.
And this is the kind of commitment that you’re looking at.
So it’s not a part commitment like Okay, we’re going to put in 40 hours a week, and we’re going to be working hard, but it’s a commitment,
which is looking on the actual impact that the team tries to make with the product of the service that they are delivering.
And that’s also why you say, okay, not just through the work, but it also means putting it into the hands of your customers, which is a delivery part in there.
It’s not just about how they deliver.
All right.
Good.
Not just making a product, but just making it available.
Right, so what do you think, if the team does not take responsibility for delivery,
what is the main cause for that?
Is it just the management behind the team or is it the team itself who does not take responsibility?
Well, actually you’re diving into the way that you actually can use these cars
and that you actually use the game with the team.
Because if I use these cars with the team assessment,
this is the kind of discussion that I would like to trigger.
Be it in a team, when the team is playing with the cars,
or being when people from the organization and teams are working together on this.
Because if you see that there are different views like,
okay, I’m not sure if we really are committed to deliver value to the customers
or we see some barriers in there,
that’s where you want to dive deeper into these kind of discussions.
There can be various reasons in there.
There can be reasons that teams are scared to actually give any commitment in the organization
because commitments are treated in such a way that if the team doesn’t live up to that commitment,
they’re somehow going to be punished.
They’re somehow going to get into a lot of trouble.
And if this is the culture in the organization,
then there’s a big chance that teams don’t want to take that commitment
because they will be afraid that they cannot live up to it.
Actually, it is.
It is.
This is a discussion that we saw in a similar way in the Scrum Guide,
which initially used the word commitment also as a kind of sprint commitment on theme
and then later moved out this commitment word from this sprint part
because they found out that it would actually backfire on the way the team were working with Scrum.
Instead of being committed, they were actually sacrificing quality
to just deliver the full functionality and to deliver on time,
which was not how it was ever intended in there.
So, the committed part dives into do you have the right atmosphere in the organization
where teams dare to take commitment for the things they do,
dare to take commitment for delivering,
knowing that they will do the best they can in there.
It usually goes back again to the collaboration between the teams
and the management in there.
If you want to have a real good environment where teams can be committed.
Right.
So, there are both sides of…
They don’t let me take responsibility
or I want to take responsibility and I fight for it.
I work on that and to get this responsibility and to deliver to the customer.
That’s okay.
I think it’s quite good to have this deep dive following up this question.
It’s these kind of discussions that actually help.
It’s these kind of discussions that help organizations to find out where the real problem is in there.
And I actually had situations where managers truly wanted to give freedom to teams
and wanted them to take responsibility.
But given to how the culture has been previously,
a lot of teams are still scared to take this responsibility.
And this is actually where I tell teams like,
okay, just try out, take this responsibility,
dare to do whatever you can and see what happens in there.
Yes, right.
I heard from a German HR coach or from a responsible HR coach for, I think, 50 scrum masters.
He said, okay, a good scrum master, a good coach is someone who breaks a rule every day.
One rule every day just to have a look.
Where are the rules?
Where are the borders who can go over?
I think that makes sense.
And actually, I would question whether…
Are really rules or not rules?
They might be perceived as rules by the team.
Yes.
Okay, are we allowed to do this or not?
I worked with a project manager one time who had a simple statement like,
if there’s no rule anywhere which tells us that we’re not allowed to do this,
then let’s just do it and see how it works out.
Yes, right.
That’s it.
Okay, so I would like to switch over to Agile Card 8.
There’s the question.
Test cases are written up front.
It’s based on requirements and user stories.
And the first part of my question is,
do you see any difference between the countries where you are working?
So are there regional differences between the part of this question?
Yeah, I think it’s regional and often even more cultural differences
between the way that organizations are working.
Also the way that organizations are applying Agile.
For instance, when I was in Australia working with teams over there,
I noticed that it’s very common to have business analysts within your team
as people who have a deeper knowledge on the requirements area
and who are part of a team at one hand,
but they’re working very intensively together with product managers
or product owners to clarify what the product actually needs to do.
So this really domain knowledge of the business is a key aspect.
And the business analyst role, which was there already before
that those organizations started to incorporate Agile,
a lot of those organizations managed to keep this business analyst role,
but they actually moved it into the team.
And I think by making those business analysts part of the team and team members
and improving the collaboration between the business analysts, developers and testers,
I think that’s giving a lot of improvement.
I see also cultures where there’s still a big difference
between product owners and the teams
when it comes to defining the requirements
and discussing the requirements and clarifying them
up to the level that it might even harm working in an Agile way.
One organization I worked with started to implement Agile
in the different teams in there.
And after a couple of months, I noticed big differences between the projects
where the product owners and the teams were working together.
And I think that’s a big difference between the projects where the product owners and the teams were working together.
And I think that’s a big difference between the projects where the project owners and the teams were working together.
And I think that’s a big difference between the projects where the project owners and the teams were working together.
really was available to the teams and really worked together with the team very intensively
to clarify what their customers needed
and really was using also things like the product review
to see what the team had delivered and giving feedback on that
versus product managers who actually stated their role and said,
okay, I just gave you a specification
and I’m going to be back in five or six months from now
when the project is finished to see what you have delivered.
I didn’t even want to attend the product reviews.
And those teams who managed to get their product owners on board,
they got much bigger benefits.
And it was actually a win-win.
It was a win-win for the teams and it was a win-win for the product owners.
So it was actually a culture clash within the organization.
And actually, the funny thing was that after a couple of months,
discussions were ongoing between the different product managers in the organization
where they said like, okay, but I’m working in a different way with the teams right now.
And yeah, initially it took me more time.
But right now, take a look at my agenda.
I actually got much more freedom to do stuff.
I got time to dive into topics that I couldn’t dive in previously
because right now the teams can do much more themselves.
So they actually managed to free up their agenda by working in an agile way
and getting better results from teams.
That’s right.
I think it’s, to my point of view,
user stories are just an invitation to discuss something,
not to describe everything,
switching from business cases or other traditional things
to a modern way of describing requirements.
No, it’s just an invitation.
And to start a discussion, and discussion means investing time,
and you will be paid off after that, just as you mentioned.
Yeah, I agree.
You’re looking for the most rich communication techniques that you can use.
Face-to-face contact, face-to-face communication,
even if it’s remotely via video connection,
it’s much better than trying to use documentation.
So that was the second example for having your cards using
for just to start discussion and self-assessment.
Moving on to Agile Card 11, which states,
the team knows how much they can deliver.
It’s a short sentence, but very expressive and with much meaning in it.
And what?
What does that mean in practice, to your point of view?
What you’re actually aiming at with this card is that teams know their capability
and you want the teams to work in a sustainable space.
So when teams know how much they can do and they know their capability,
they also know what they are capable of, what they are not capable of.
They’re in a much better position to make realistic discussions
with the product owners, with their customers,
and to start a conversation.
And to say what they can deliver and what they cannot deliver.
What you want to prevent is putting pressure on teams.
What you want to prevent is overloading them.
And the more teams are capable of knowing what they can do and what they cannot do,
it empowers them in these kinds of discussions when they are put under pressure.
Because then they can say, well, this is how much that we can do.
And what we can actually discuss about is what we will be doing.
But putting more pressure on us won’t give you a better result.
It will actually give you worse results.
So it’s about empowering the team, basically.
Regarding my teams, I have one team in mind,
which overloaded itself for weeks, for several sprints.
They were taking cards and were taking stories for their sprints.
And I think for six, seven or eight sprints, they did not deliver what they committed.
And I got the feeling that they don’t have the point on that.
They are not feeling committed.
Just putting the same pressure.
But if they did not reach their goal, and as I mentioned, six or seven sprints in the past,
they did not reach their goal.
But it doesn’t matter.
It’s okay.
So just take another chance and fail again.
What was a hard work to tell them.
What does it mean?
You know what?
You know what you can deliver, how much you can deliver, and commit yourself to that.
Exactly.
And if you know how much you can do, I’ve seen teams actually where I had to make them
think differently about things like project deadlines.
When they started on the project, when they planned their first sprint, they got worried
like, okay, if we keep on working like this, if this is the amount of stuff that we’ll
be doing every sprint, then we won’t have everything ready at the end of the project.
And then they also started taking on more work and weren’t able to finish it.
So after a couple of sprints, I actually got them together and I told them, like, you should
stop worrying about your project deadlines, about the delivery of your project.
The only thing you should focus upon right now is on the sprints that you are doing.
Trying to do your sprint the best you can.
Learn from what happened in the sprint, use your retrospective to see where you can improve
there.
And if you see where you did well work, what are your strengths that you can use to even
further improve in there.
And if you work in that way, you’re going to be doing the maximum you can.
And if that means that you still can’t make the deadline on the project, well, you’re
not going to make it if you put on more work.
Right.
That’s actually going to backfire.
So that’s not going to be the solution.
So stop worrying about the project scope, stop worrying about the project deadline.
This is something that the project manager and the product officer should do.
And if they know what your capacity is, then they can take the proper decision on prioritizing
what needs to be done.
I think there’s another point to start discussion about different roles and different responsibilities
for that.
It’s quite good.
Exactly.
Exactly.
And this is also where the cars will show whether a certain statement that is made on
the car.
It’s not really a question, it’s more like a statement.
If you have a team.
If you also have teams involved with your product owners and project managers, then
you can actually discuss like, okay, who’s taking responsibility for this?
This is something that we should be doing as a team or multiple teams.
It is something where we expect the product owner to be in the lead.
This is something where we expect the project management to be in the lead.
And the cars will help them to discuss this and to see if this is properly covered or
not.
Right.
And so you can use your cards to rerun the case.
Right.
So you can play the game after three months or six months and have a look if anything
changed.
Exactly.
Exactly.
Actually, I’ve seen teams who use these cards at the start up as a team to discuss, okay,
what’s the main stuff that we should be focusing on right now?
And who’s going to be doing this?
So they use it as a kind of kickoff for their teams right now.
And then after three months, two or three months, again, they take a subset of the cards, do
a kind of self assessment and see how they are doing at that point in time and see what
other things they can do.
And that’s what we’re going to take along right now.
So I would like to move on to the Agile Card 16.
And this means the team tracks progress daily, for example, with burn down charts.
How does a chart help to your point of view?
The main reason of using a chart, which can be a burn up or burn down or any other mechanism,
is visualization.
What you want to do is to make sure that you have the right visualization.
Right.
So what you want to do is to put it in a chart, make it visible for everybody involved
in there.
My experience is that when you start making stuff visible, when you start drawing it
out, whether that’s a whiteboard or whether that’s on a tool or whatever, it becomes a
lot easier for people to discuss it, to see how they are doing.
So visualization is a key technique in there to show how the team is doing.
Yes, I think that’s right.
And regarding my team.
What I had in mind for the Agile Card 11, I asked them to use the burn down charts for
each sprint.
And we got a clear image of what they did not deliver.
So the burn down chart does not burn down.
It doesn’t go to the zero line.
So they saw for five sprints, oh, we did not deliver.
What?
We committed, right?
It’s visualization.
Exactly.
Exactly.
And once it becomes visible, then people can see, okay, is this, is this really a problem
or not?
And how should we act on it?
It prevents a lot of discussion, much more power that you can do with a picture than
you can do with words.
That’s right.
So, um, that’s the Agile Card 18 and I think, uh, it’s, I think would be one of my favorite
cards.
Uh, the trainings I give for, um, scrum and for DevOps.
The Agile Card 18 means, uh, or states face to face conversation is preferred for conveying
information, conveying information.
And I think today it’s often, uh, a challenge.
You have, uh, teams sitting all around the, the world, uh, or, uh, different buildings.
So they’re not in, uh, not sitting together for that.
That’s what, what, what I see it.
Um.
So, um, so I think, uh, the Agile Card 18 is a, is a, is a great platform for, uh, for
most of my clients, for most of my customers.
What’s your, uh, impression for that.
I, I think basically this is becoming the norm.
I think we should start with the assumption that getting all the people at one place,
getting them into one room to do everything that needs to be done end to end is simply
not possible in, I think, nine out of 10 situations, but probably in 99 out of 100 situations.
There’s different reasons for this.
One reason being, that, uh, I think it’s a very good tool.
Das heißt, wenn man die Systeme erledigen möchte, die gerade entwickelt werden müssen,
sind diese Systeme so komplex, dass sie viele Leute betreffen,
und es ist einfach nicht möglich, all diese Leute in einen Raum zu bringen.
Es würde nicht funktionieren, weil es zu viele Leute gäbe.
Das andere ist, dass wir auch nicht denken sollten,
dass wir einfach alle auf die gleiche Stelle kommen und dort sind
und acht Stunden dort arbeiten und zusammenarbeiten.
Menschen können von überall arbeiten,
sei es in ihrer Heimat, sei es in der anderen Teil der Welt.
Und ich denke, remote arbeiten ist der Standard jetzt.
Ich habe meine eigene Situation angeschaut.
Die meiste meiner Arbeit ist gerade remote.
Und ich kann viele Dinge remote machen,
sei es Menschen zu coachen,
zusammen mit Teams zu arbeiten,
meine Trainings- oder Präsentationen zu entwickeln.
Es gibt also viele Dinge, die ich remote machen kann.
Wenn man sich die Kommunikation anschaut,
die eine Sache, die ich versuche,
mit den Teams anzuzeigen, ist,
dass die wichtigste Sache in der Kommunikation Distanz ist.
Und Distanz ist nicht nur physische Distanz,
Distanz ist auch emotional Distanz.
Einer meiner Seitenarbeiten, die ich mache,
ist das Schreiben für InfoQ.
Redakteure für InfoQ sind überall auf der Welt.
Wir sehen uns meistens ein oder zwei Mal im Jahr,
manchmal sogar weniger.
Aber wir haben eine so starke Verbindung mit einander.
Wir kennen die Dinge, die wir am meisten wertschätzen.
Wir kennen die Dinge, die unsere Benutzer,
die Redakteure für InfoQ,
suchen.
Und wir sind so stark verbunden,
dass nicht in dem gleichen Ort zu sein,
eigentlich kein Problem ist.
Denn unsere emotionale Distanz ist sehr klein.
Also kann ich einfach viel machen,
mit E-Mail, mit Slack,
manchmal mit Skype-Anrufen.
Und wir können tolle Sachen machen,
während wir überall auf der Welt distribuiert werden.
Wir müssen nicht in dem gleichen Raum sein,
weil unsere emotionale Distanz sehr klein ist.
Und das zahlt für die physische Distanz.
Und wenn ich physische Distanz meine,
meine Vorrednerin lebt in Neuseeland.
Also das ist ungefähr so weit,
wie wir von dort aus gehen können.
Und wir können zusammen sehr gut zusammenarbeiten.
Okay, also es gibt einen besonderen Sinn
hinter dieser Satz,
hinter dieser Frage.
Okay, also emotional Distanz.
Ich denke, das ist ein guter Punkt,
um darauf zu arbeiten
und darauf zu schauen.
Und das ist aufgrund der Kultur
und der Art und Weise,
wie du und dein Leiter
und wie dein Team
die Arbeit machen
und wie sie zusammenarbeiten.
Richtig.
Ja, ich denke, es ist die Kultur,
die Glauben,
das gemeinsame Mindset,
das Wissen, was wichtig ist,
das Fokus.
Das ist die Art von Sachen,
die deine emotionalen Distanz bestätigen.
Je kleiner diese Distanz ist,
desto mehr bist du auf das,
was wichtig ist,
desto bessere Resultate
bekommst du als Team.
Ja, richtig.
Also gehen wir weiter
zu Agile Card 21,
die sagt,
das Team ist in der Lage,
unabhängig eine konstante Zeit zu halten.
Und wir haben darüber gesprochen,
weil du nicht sicher warst,
ob meine deutsche Übersetzung
den richtigen Sinn hat
oder die richtige Ausführung.
Und wir haben darüber diskutiert.
Was ist deine Idee,
wenn es um die Geschäftspressur geht?
Siehst du,
dass die Geschäftspressur da ist?
Ja, leider sehe ich
noch viel von der Geschäftspressur.
Das ist tatsächlich einer der Aspekte,
die ich in meinem zweiten Buch
über die Qualität der Arbeit
diskutiert habe.
Denn diese Art von Geschäftspressur
und auch die Druck auf den Projektleiter
oder die Druck, die die Projektleiter
auf Teams legen,
tun viel Schaden,
wenn es um die Qualität der Produkte und Service geht.
Also ist diese Art von Druck
immer noch da.
Und für mich ist es
eine Art von Überraschung,
denn wenn du in diesem Bereich sehr tief reingehst,
ist es selten,
dass ich irgendwelche Situationen sehe,
in denen das wirklich funktioniert.
Manchmal, wenn du ein Team kennst,
das genug fähig ist,
technische Dämpfe zu nehmen
und etwas auf kurze Anmerkung zu erlernen
und dann die Zeit zu nehmen,
sich davon zu erlernen
und die Probleme zu lösen, dann kann es funktionieren.
Okay, richtig.
Was ich sehe, ist,
dass es
nicht so viel Druck gibt.
Vielleicht sehe ich es nicht
und es ist da,
aber ich kann es erkennen.
Aber ich denke,
wie du es erwähnt hast,
wenn es nicht so viel Druck gibt,
wenn das Unternehmen weiß,
dass es keine bessere Qualität
oder Software bekommt
in weniger Zeit,
dann ist es okay,
wenn sie darüber sprechen,
wie viel Druck es von der Firma gibt.
Ich denke, es ist okay,
wenn sie darüber sprechen,
wie viel Druck es von der Firma gibt.
Und Druck wird nicht helfen,
um bessere Software zu bekommen
oder um die Software früher zu bekommen.
Das ist eine Diskussion,
die ich gerne sehen möchte
zwischen den Leuten
in der Managementrolle,
den Leuten in den Geschäftsrollen
und den Leuten, die in den Teams arbeiten.
Und ich habe beide Situationen gesehen,
in denen Teams sich beeinflusst haben,
aber ich habe auch Situationen gesehen,
in denen Teams sich mehr oder weniger
beeinflusst haben
und in denen die Leute
von der Produktseite gesagt haben,
es gibt genug Zeit,
nicht zu viel Arbeit zu machen.
Wie wir vorhin diskutiert haben,
Teams beeinflusst sich selbst.
Also gehen wir weiter
zu Asia Card 26.
Wenn jemand sagt,
dass er sich auf ein Produkt
beinhalten möchte,
dann muss er sich selbst
auf ein Produkt beinhalten.
Und er muss sich selbst
auf ein Produkt beinhalten.
Wir haben vorhin gesagt,
dass Teams sich beeinflusst haben,
wenn sie sich auf ein Produkt
beinhalten.
Wenn man sich auf ein Produkt
beinhalten lässt,
dann ist das auch so.
Man muss sich selbst auf ein Produkt
beinhalten.
Du musst sich selbst auf ein Produkt beinhalten,
dich selbst.
Wenn du ohne Software
ausımaßlich
Produkt und Service
haben willst und
nicht deinen Kunden
geven willst,
dann unknown
Und das ist das, was diese Karte versucht zu stressen.
Und tatsächlich, die Art und Weise, wie ich diese Karte gestattet habe,
ist, um Menschen in Diskussionen zu bringen,
wie, okay, aber was ist gemacht?
Was ist wirklich gemacht?
Wann sind wir wirklich gemacht?
Und um Diskussionen zu verhindern,
wie, okay, wir haben gemacht, und wir haben gemacht,
und wir haben gemacht, gemacht, gemacht.
Und dann, gemacht, gemacht, gemacht,
ist, wenn es in den Händen der Benutzer ist.
Nein, du willst nur einen gemacht haben.
Das ist eine End-to-End-Verantwortung.
Und es ist nur gemacht, wenn es tatsächlich da ist,
auf der Kostümseite.
Und jeder Schritt dazwischen,
du kreierst einen Art von Hand-over,
der nur Sachen verlängert,
und der, wiederum,
die Verantwortung und die Verantwortung des Teams abnimmt.
Also, du willst die Schritte so gut wie möglich auswählen.
Ja, das ist richtig.
Aber ich möchte noch etwas beiseite bringen.
Meiner Meinung nach,
wollen die Scrum-Guides,
die Team zu verbessern.
Und eine Art oder eine Teil der Verbesserung
ist,
zu sagen,
wir müssen auf die Definition von DONE arbeiten,
um diese Definition von DONE deutlicher zu bekommen,
um mehr Punkte darauf zu haben.
Also, was die DevOps-Punkte oder die DevOps-Parte betrifft,
denke ich, ist es das Hauptwerk für den Scrum-Master,
zum Beispiel,
um dem Team zu helfen,
auf die Definition von DONE zu arbeiten
und um eine mehr detaillierte Arbeit zu bekommen,
äh, nicht Arbeit,
eine mehr detaillierte Sicht auf ihre,
auf ihre Sicht,
äh, was, was sie sehen,
was DONE bedeutet.
Ich, ich denke, das ist wahr,
aber tatsächlich ist es der Art und Weise,
die du durchgehst.
Zuerst, wenn du mit deiner ersten Definition von DONE beginnst,
ich stimme zu, es wird unkompliziert sein,
du wirst Dinge verpasst,
und wenn du deine Retrospective machst,
wenn du auf das passiert ist,
wirst du herausfinden,
okay, das ist auch etwas, was wir tun müssen,
das ist auch etwas, was wichtig ist,
also, lass uns das zu unserer Definition von DONE hinweisen.
Und ich, im Grunde, denke ich, dass das eigentlich ein gutes Verhalten ist.
Sobald deine Teams mehr wachsam werden,
verändert es sich tatsächlich von einem Art und Weise,
von einer Art und Weise, wie, okay, wir müssen alle Regeln folgen,
und dann wissen wir, dass etwas gemacht wird,
zu einem Art und Weise,
okay, wir wissen, wann ein Produkt gemacht wird,
wenn wir es sehen.
Und es ist auch ein Team, das sich wachsamer wird,
weiß, wie flexibel sie sind,
in der Art und Weise, in der sie ihren Prozess benutzen,
sie wissen, ob sie einen Art und Weise der Software entwickeln müssen,
abhängig davon, was diese Art und Weise betrifft,
abhängig davon, was die potenziellen Risiken darin sind,
abhängig davon, wer darin involviert ist.
Ein wachsames Team weiß, wie man ihren Prozess wachsamen kann,
um das richtige Ergebnis daraus zu bekommen.
Und das bedeutet auch, dass sie mehr oder weniger
die Definition von DONE wachsamen,
abhängig von der Situation, in der sie sind.
Was ich versuche zu sagen,
je wachsamer dein Team wird,
desto kleiner wird deine Definition von DONE.
Initial wird es wachsamen,
aber je wachsamer es wird, desto kleiner wird es.
Denn es wird die Werte verändern,
um eine viel mehr
Mindset- und Goals-orientierte Beschreibung
der Tatsache zu haben,
anstatt den ganzen Prozess zu beschreiben.
Richtig, das stimme ich zu.
Das ist der Art und Weise, den du möchtest.
Du hast weniger Dokumentation.
Das stimme ich zu.
Das stimmt, es wird kleiner für das.
Also wachsame Teams,
das stimme ich zu Agile Card 31.
Das bedeutet, der tägliche Stand-up fokussiert sich
auf das abhängige Arbeit, das vorhanden sein muss
und die Bedingungen und dauert nicht mehr als 15 Minuten.
Was ist deine Erfahrung mit all den Teams,
die du weltweit unterstützt hast?
Gibt es regional oder kulturelle Unterschiede?
Bleiben sie in ihrem Zeitraum?
Mhm.
Ich habe gesehen, dass das eine Herausforderung für viele Teams ist.
Und tatsächlich haben einige Teams sehr gute Habits, das zu tun.
Ich hatte ein Team, mit dem ich an einem Punkt im Zeitraum gearbeitet habe,
das die Worte Point mit einem spezifischen Sinn benutzt hat.
Also wenn jemand in einem Stand-up-Meeting spricht
und die Worte Point benutzt hat, um zu sagen,
okay, ich bin bereit,
es ist Zeit für die nächste Person,
die jetzt zu sprechen ist,
um zu erzählen, wie sie sich dort machen.
Und tatsächlich, wenn jemand auf dem Ziel bleibt,
dann könnte jemand auch schauen,
und ich würde sagen,
Point?
Kann man da aufhören?
Also haben sie einen Art von Habit geschaffen,
um mehr zu den Punkt zu sein,
indem sie das Wort Point mit einem spezifischen Sinn benutzt haben.
Ich habe Teams gesehen, die ihren Stand-up in einer anderen Art und Weise machen.
Oder eigentlich sind die Scrum-Lehrer
viel mehr die Diskussion ermöglichen,
indem sie durch das Board gehen.
Sie geben einfach Zeit zum Reden
für alle Teamleute dort.
Sie machen immer noch sicher,
dass all das, was sich umsetzen muss,
synchronisiert werden muss.
Und dass die Leute versuchen,
Hilfe zu bekommen,
dass sie die Möglichkeit haben,
sich sicher genug zu machen.
Also entwickeln verschiedene Teams
verschiedene Habits darin.
Das ist wiederum, wo ich denke,
die Retrospective ist ein sehr starkes Tool.
Deine ersten Stand-ups werden fehlen.
Es ist ein neuer Weg,
und du musst herausfinden, wie du das tust.
Und deine Retrospective kann dir helfen,
zu sehen, wie die Dinge da sind,
und dann, um bessere Wege zu finden,
mit den Experimenten, mit den Stand-up-Meetings zu machen.
Gibt es irgendwelche kulturellen Unterschiede
oder Unterschiede zwischen den verschiedenen Ländern?
Nun, ich sage oft, dass es kulturelle Unterschiede gibt,
aber ich sehe auch das Gegenteil.
Ich habe mit Teams in Indien gearbeitet,
die ihre Stand-up-Meetings machen.
Und da habe ich zu Beginn Geschichten gehört wie,
okay, ich bin mir nicht sicher,
ob sie wirklich so fokussiert sind.
Und ihre Diskussionen könnten länger sein,
und sie könnten nicht sprechen.
Und ich habe tatsächlich Diskussionen gesehen,
die sehr wichtig waren.
Sie hatten Teams mit acht oder neun Mitgliedern.
Ich habe wirklich alle Arbeit synchronisiert.
Und alle haben gesprochen.
Und sie haben in fünf oder zehn Minuten
mit der Stand-up-Meeting beendet.
Und ich war wirklich beeindruckt,
wie sie es da gemacht haben.
Also, ja, es werden kulturelle Unterschiede geben,
aber oft ist es vielmehr die organisatorische Kultur
als die regionalen Kulturen.
Wenn die organisatorische Kultur
Menschen ermöglicht, sich sicher zu fühlen
und mit Dingen zu experimentieren,
dann können Teams in diesem Bereich Wunder machen.
Und dann ist es egal, ob diese Firma in Indien ist
oder in Deutschland oder in den Niederlanden oder in den USA.
Es geht vielmehr um die lokale Kulturen der Firma.
Okay, richtig, das ist interessant.
Okay, also, ich denke, wir haben ein oder zwei mehr Karten.
Also, bevor wir zum Schluss kommen,
würde ich gerne einige Beispiele von Ihrem Arbeit nehmen.
Agile-Karte 34.
Da ist die Frage.
Die Produkt-Demonstration oder Sprint-Review
wird von vielen Stakeholdern,
Geschäftsführern, Geschäftsführern und anderen Teams besucht.
Was ist Ihre Meinung?
Können Sie uns einige Beispiele von Ihrem Arbeit geben?
Vielleicht von überall auf der Welt?
Ja, ich habe hier eine große Unterschiede gesehen.
Ich habe viele Produkt-Review-Meetings gesehen,
die immer noch eine Art von Beratungs-Meetings sind.
Also, es ist tatsächlich das Team, das Beratungen macht,
und es ist das Team, das den Produkt-Mitglied anbietet.
Und oft ist der Produkt-Mitglied eigentlich der einzige Geschäftsführer in der Raum.
Und ich denke, diese Beratungen sind grundsätzlich nicht wirklich effektiv.
Die Idee der Produkt-Review ist, dass es eine Beratungs-Meetung ist,
in der man Feedback bekommen möchte.
Es ist also keine Beratungs-Meetung.
Man will Feedback auf das Produkt bekommen,
weil man diese Feedback nutzen möchte.
Man will diese Informationen nutzen, um zu entscheiden, worauf man weiter arbeiten möchte.
Und man will überprüfen, ob man das richtige Produkt in der Raum hat,
anstatt darauf zu beraten.
Ich habe Beratungs-Meetings gesehen, die wirklich offen waren.
Ich habe bei einer kleinen Start-up-Firma gearbeitet.
Und im Grunde genommen würde jeder in der Firma in der Raum sein,
wenn sie im Büro waren.
Jeder, also etwa 25 oder 30 Leute,
insbesondere der CEO.
Und tatsächlich habe ich Situationen gesehen,
in denen der CEO zu dem System, das demonstriert wurde, überwacht,
und dann angefangen hat, einige Sachen auszuprobieren und in Sachen zu typen,
und mit der Maus zu arbeiten, um zu sehen, wie das funktioniert.
Okay, wie fühlt sich dieses Produkt an?
Ist das das, was unsere Kunden möchten?
Also hatten sie wirklich alle in der Raum
und es war wirklich möglich, solche Diskussionen in der Raum zu machen.
Ich habe Produkt-Reviews gesehen,
wo ein Team und ein Produktführer zusammenarbeiten.
Und je nachdem, wer im Publikum ist,
es kann sein, dass der Produktführer die Szene setzt
und die Leute in der Raum sicher fühlen,
um in der Raum Feedback zu geben.
Und dann die Leute aus dem Team,
die das Produkt tatsächlich demonstrieren
und zeigen, was sie gerade machen.
Aber sie nehmen auch einen Art von Wunsch für das Arbeit,
das sie in der Raum machen.
Also da ist eine sehr große Unterschiede.
Ich habe Organisationen gesehen, die experimentieren
mit zwei verschiedenen Arten von Produkt-Reviews.
Es war eine Organisation, die nicht zu groß war, aber es war eine Organisation, die nicht zu groß war,
aber es war eine Organisation, die nicht zu groß war,
und es gab zwei verschiedene Orte.
Das Team der Entwicklung war in einem Ort,
die Produktführer waren in einem anderen Ort.
Und sie alternierten ihre Produkt-Reviews,
sie hatten einen Produkt-Review am Entwicklungs-Schein,
wo es nur ein paar Produktführer gab,
die viel mehr auf das technische Teil des Produkts konzentriert waren,
wo das andere Produkt-Reviews
mit einfachen Mehrheitenukeben låst.
Und die anderen Woche waren bei Produktführern.
Und dann waren ein paar Entwickler dort,
die eine strategischere Perspektive mit den beiden Ortebarkeiten
ergeben konnten.
Und indem sie字ieren,
auch in Nina hat sie verschiedene Vorsbuilten,
die sie Grove Bhushabды gelementieren.
Und diese kh hazards!
Das mainly Das eigentlich noch eine rein
Das eigentlich noch eine rein
Äußerliche als setzt es hier auf.
Man hat das Gefühl,
wenn man vitamin-纥 eins passe,
dann hat man einevingtiative Eschshi
Wenn man aufouleist ich habe jetzt im ungefähr der gtver-
persönlich verunssympfung Gefühlt 타
Also sie haben keine saber aus Свφ haben zu tun.
Agile Card 52, the last one for this podcast and the last one from your card set, which means team members enjoy the work that they do, have fun and celebrate successes.
What do you experience? What’s your experience about that?
Well, this actually has some cultural aspect in there. I think what I’ve seen with teams in the Netherlands and also with some of the teams in Germany and there, like celebrating your successes, it’s still some kind of cultural thing like, okay, celebration is something that you don’t do in the office.
If you want to celebrate and you will go out to a bar or you’re going to have a party, but celebrating in the office, like this is work. This is serious stuff, right?
And do you have fun at work?
It’s the same. If you want to have fun, you go out to bars and do it in your private time.
Well, you can still have fun as a team. And I think it’s actually important to have fun. The thing behind having fun is that it also creates a safe culture.
So if it’s safe enough to have fun, if it’s safe enough to have a laugh, if it’s safe enough to sometimes tease somebody a little bit on some stuff, it’s also safe enough to speak up if something is really bothering.
And again, this psychological safety is a key aspect for teams, for people to work together in teams.
So if you want to create this psychological safe environment, making sure that people can also have fun, can have a laugh, is very important because it helps to create this environment, which is so essential for people to work together.
That’s right. Safe safety, yes.
Okay, Ben.
Having a look at the time box, we are just over the 45 minutes, which was our time box, but I think it was a great part.
And I’ve learned very much from your worldwide experience about that.
Is there anything you want to add?
Did I miss some really great card or some really great point?
Well, I think not really a card.
We only went through the HR card.
As you mentioned, there’s a DevOps card.
There’s a set for software.
There’s also a set for business agility, so we take on different aspects of collaboration there.
I think the key thing for this agile self-assessment game is not that much a card, but it’s the playing formats.
And what I actually have seen is that I’ve described, I think it’s something like 10 different playing formats as a guideline with the cards to give people some ideas on how to play with them.
And what I found out is that people actually took this kind of inspiration.
And they developed their own games and developed their own playing situations to use the cards in a way that made sense to them.
And that actually makes me feel very happy.
So that’s again, the difference between game and gamification.
It’s not about the cards.
It’s not about the rules.
It’s about giving people a tool, an agile coaching tool that they can use in the way that works best for them.
And I actually encourage this by saying, okay, if you are a player and you know, if you have a good technique, then you can do it.
Then you can use it.
Okay, wenn du das Produkt kaufst, wenn du die Karten auf meinem Website downloadst, bekommst du freie Lebenszeit-Support.
Also, wenn du diese Karten in deiner Organisation benutzen willst und du eine Frage hast, wie man das macht,
oder du willst nur ein paar deiner Ideen checken, wie man mit ihnen spielen kann,
dann ruf mich an und ich helfe dir mit dem. Ich werde dir einige Ideen geben, wie man das macht.
Oder du kannst deine Ideen mit mir verabschieden, weil ich finde es wichtig, dass die Leute die Dinge in deinem Umfeld benutzen.
Und das ist, warum ich diese zusätzlichen Schritte für die Leute verabschiede, um es ihnen sicher zu machen, Dinge zu probieren.
Okay, danke.
Also, ich werde einen Link zu deinem Website geben, wo jeder die englische oder die deutsche Version kaufen kann,
um dieses große Selbstassessmentspiel zu bieten und agile Arbeit zu bieten.
Also, danke.
Danke dir, dass du ein Gast in meinem Podcast warst und ich hoffe, dass wir uns bald wiedersehen.
Danke, dass du mich besucht hast.