Entscheidungen treffen (lassen)

Human-centered Design – also Menschen in den Mittelpunkt zu stellen – bedeutet nicht, dass Menschen/Nutzer/Kunden alles selbst entscheiden dürfen oder sollen.

Wertvolle Erlebnisse entstehen dann, wenn wir die Bedürfnisse der Menschen verstehen und als Experten in unserem Bereich mit diesem Bewusstsein die richtigen Entscheidungen treffen.

Eisbrecher für Workshops: 1, 2, 3 – Klatsch, Hüpf, Stampf

Ziel: Körperliche Aktivität, Kreislauf anregen, Distanz zwischen den Teilnehmern abbauen

Immer zwei Personen stellen sich gegenüber. Die erste Person sagt „1“, die zweite „2“ und die Erste „3“. Danach wird die Reihenfolge getauscht. Nachdem die Teilnehmer etwas geübt haben, wird nun jede „1“ durch ein Klatschen ersetzt. Auch hier den Wechsel zwischen den Personen beachten. Sobald es flüssig läuft, wird jede „2“ durch ein Hüpfen ausgetauscht. Also: Klatsch, Hüpf, „3“. Auch hier die Runde für 30 bis 60 Sekunden laufen lassen.

Zum Abschluss kommt die größte Herausforderung. Jede „3“ wird durch ein Stampfen abgelöst. Die Teilnehmer wechseln sich also mit Klatschen, Hüpfen und Stampfen ab. Meist endet die Runde mit lautem Gelächter…

Wichtig für den Moderator: entweder selbst mitmachen oder am Anfang jeder Runde ein Beispiel machen. So wird die Einstiegshürde geringer und die Angst genommen, dass die Teilnehmer „sich zum Affen machen“.

Qualität, die begeistert

Wann hast du dir zuletzt neue Stühle gekauft?
Wie lange hast du schon das gleiche Handy?
Wie lange nutzt du das selbe E-Mail-Programm?

Neue Features und Gimmicks machen Spaß – und wie lange? Langfristige Begeisterung kommt nur bei Marken und Produkten auf, die Jahre später noch nützlicher sind, als die Käuferin erwartet hat.

Symptoms of high-performing teams

Thread by Susanne

I’ve worked with lots of agile teams, and some of the symptoms of a well functioning high-perfoming teams that I see are:

They start their daily standups on time.

They tend to laugh a lot and have fun.

Everybody in the team gets to express themselves.

They correct and edit each other when they go off track.

They try out new things with appetite. But they are quite willing to admit those things didn’t succeed.

They often don’t care very much if it looks like they’re working hard.

They encourage each other to leave on time.

They talk about how “we built” or “we failed”, rather than “I built“ or “I failed”.

They have lunch together, or some other time within work hours where they talk about other things than work.

They welcome more junior members of the team, and enjoy mentoring them.

They have inside jokes.

They share responsibility for communicating with outside stakeholders.

They don’t agree on everything.

They debate between short term benefits and long term strategy. They reach compromises.

They question each other on topics like accessibility and inclusivity in design and development.

When they finish a task, they check if they can help someone else finish theirs.

There’s room in good teams for extroverts and introverts. And those in between.

Team members are aware of their needs and communicate those to others.
I’ve seen some great teams have some seriously stubborn people in them. They can be great when the team needs reminding of why they came up with a certain rule: specifically so the team wouldn’t compromise when they were in a hurry.

Good teams often fight for independence to make their own decisions.

They ask “why” a lot.

They discuss the users of their products every day, and the user experience is viewed as everyone’s responsibility.

If they are remote, they try new ways to make everyone equal, even if it means compromising the experience of those people that are in a shared space.

They are not dogmatic.

Testers and designers are included in discussions of estimations and backlog refining.

They respect agreed decision making structures, but argue their points.

The people are not too similar to one another. They think about problems from different angles.

If someone on the team is ill, the others figure out how to get by without that person.

They have quiet time. In whatever amount is valuable to them.

They don’t interrupt each other. They take equal turns in speaking.

They get each other tea/coffee/water.

They have one-to-one chats with each other to discuss points of agreement or disagreement.

They know each other’s personal and professional goals and aspirations, and try to support them where possible.

They are not all equally skilled at everything. But they try to work on things where they can learn.

When people pair on a task, the less experienced person is usually the “driver”.
Senior team members ask for advice and feedback from more junior team members.

They don’t have to give positive feedback every time they give negative feedback.

They thank each other for favours, for tea, for good ideas, for bad ideas, for observations…

They use the products they’re building.

When someone has an idea, other team members build on it and add to it.

They accept that people have “off” days.

They are generally resilient when it comes to change – including change of direction, goals and vision.

They can work quickly, but it’s not always crunch time. There is a sustainable cadence to work.

They regularly talk about how they work together, and try to improve that.

Team members generally know what every other team member is working on, and what kind of issues they’re having.

They encourage each other to share work early, rather than wait for it to be “perfect”.

They have some shared values or principles that guide their interactions.

They try new tools and methods quite easily.

They might defend each other to people outside the team.

Before they ask for feedback or reviews from other team members, they read through their own code/work.

They have time to / they prioritise automating tasks that are not valuable.

They talk about technical debt, and teach stakeholders about it.

The work they do feels important.

They argue.

They talk about how well they’re doing compared to expectations. If the estimates turn out to be off, that’s not a disaster.

They take turns dealing with boring or time consuming tasks.

They are interested in each other personally.

They talk about problems without talking about people’s characters, rather they focus on the work.

In meetings, they put their phones down or close their laptop lids when they’re listening.

They have a say in who joins the team.

They have shortcuts for common communication (like signals for when the conversation is derailing, or when they’re losing focus).

They don’t mistake fun for a lack of discipline.

They consider different communication styles. Meetings are not just held so the loudest speakers are heard the most.

They care that other team members and stakeholders understand the work they’re doing.

Documentation is updated whenever errors are spotted, by the person who spots the error.

Team members feel a shared sense of pride and ownership of their work.

It’s not ok to notice a problem, and not do something about it, even if it’s not in an individual’s immediate area of responsibility.

Developers participate in sketching sessions, designers understand how git works.
Team members reach out to their personal networks to ask for help for other team members.

Everybody tests.

Team members let each other try things out even if they think it will fail (sometimes, if constructive).

They notice when other team members seem worried or down. They ask about it.

They don’t grow too quickly.