Fail Fast

One time, I was asked to work in a project in an mixed role as Scrum master and requirements engineer. Many people will snub their noses at such an arrangement, and often with good reason. Mixed roles are not well received in the agile world, but for me this is right up my alley. I have a very broad set of interests and skills, and I like situations enabling me to bring as much of that skill set into play as possible.

But when I started to work at the place, I soon hit a major road block. Agility, as I understand it, wasn’t required or indeed welcome there at all.

How did I know? Well, they told me, and they didn’t beat around the bush either. “Agile is chaos,” one project manager let me know, “we don’t want that here.”

“We’ve hat bad experiences with agile work. That one team we tried it with just went about their own ways, and the end result wasn’t what we expected,” said another.

So you failed once. Not a big deal, considering that according to some sources 70% of classically managed software projects fail. Try again, fail again. Fail faster. (BTW, did you notice how this business often feels like phrasemongering? That’s because you need to repeat a few central ideas over and over, until the concept sticks in the brains of your teams. If you are starting agile work and do nothing else, choose a few crucial phrases well, try to understand the concepts behind them and stick with it.)

Of course, it wasn’t over with those blanket statements. In the course of the work, we stumbled every time the team was supposed to make a decision for itself, even small ones, like deciding on the time of day they want to have their daily. It was to be at 9 AM, come hell or high water, no input from the team required.

Why is that important? The framers of the agile manifesto had a crucial insight: People want to be helpful. They are motivated, if they feel trust and empowerment. “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” I don’t know a more effective motivation killer than micromanagement, especially when working with highly qualified individuals.

And it doesn’t help if you put your team in a double bind. “These are the sprint goals, which I’ve presented to the team, and now get to work. No, don’t waste time discussing if these goals make sense at this point, or whether the goals are indeed reachable. We need to reach them, or the project won’t be done in time.”

If a thing cannot be done with the given resources, it cannot be done. Wishful thinking won’t help, and neither will additional pressure, at least not in the long run. What will help, is listening to your team. After all, it consists of highly qualified individuals you chose for the job because you thought they could do it. So why not listen to them? And you can only listen, if you give the team the room to talk. Demos, plannings and retros are the space for exactly that. There is always something to learn from them. The Scrum framework even gives you guidelines for how much time you should allow for these events each sprint.

Look, the thing is: You don’t have to do agile, if you don’t want to, much less Scrum, which can be a bit of a challenge for people who have no experience with the method at all. It’s not a law, and there are other frameworks available. In fact, don’t do it if you’re not fully committed to it, or you will end up with zombie scrum. You know, because a zombie somewhat looks like a human, but inside it’s all dead and it stinks.

Anyway, how do you deal with it if you find yourself in a similar situation? Here’s what I tried:

– Educate: Explain the advantages of agile work. Also, make the limits transparent. Agile is all about discipline in the right places, so that the team can have the freedom it needs where it counts. Don’t let a team wander off into the wilderness. Demand progress, and demand the progress to be shown. Sprint reviews are important, and so are retros. It may sound like a huge waste of time in the beginning, but the benefits will become evident if and when the team forms a habit of constant inspection and adaptation.

– Also important is strict time boxing. There is a reason why scrum will only allow 15 minutes for a daily. The purpose of a daily is not to report to the manager, and also not to solve problems. It is to identify the problems and assign them to people who are able to solve them. This will indeed work better if the time is limited.

The same ist true for the length of a sprint and the time any story is in the works. If you cannot get your stories finished in time, you might actually be better off using Kanban and focus on a limited number of items of which you have a very clear idea how long they can stay in the works. Put first things first, and the first thing to focus on in a team that doesn’t want to do agile is to make sure things are actually getting done.

– If all of this is not enough, try to find allies. This is actually a good idea in any case, but it get crucial if the resistance is too strong for one person. Your allies don’t have to be in upper management – in fact I’d rather they weren’t, agile is nothing you can impose top down – but if your conflict is mainly with a manager, you can work around them sometimes. If it’s just one or two team members, they can sometimes be swept off their feet and carried along by the developing dynamics.

In my case, that also didn’t work. The situation got worse week after week. I never got criticised for any mistakes I made, but for the things I did well and right. I could have given up on my role as Scrum master and just written up requirements for the rest of the duration, but that wasn’t what I was taken on for in the first place. So when, after two months, I was given a way out, I took it. After all, “fail fast” is another one of the driving principles of the agile approach.

How would you deal with such a situation? Help me learn an let me know in the comments.

Design Thinking in der Politik: Worauf müssen wir achten?

Agile Prozesse wurden in Unternehmen entworfen, und das bedeutet, dass wir sie in anderen Kontexten nicht so ohne weiteres einsetzen können. Wir müssen ein bisschen über Strukturen, Prozesse und Begrifflichkeiten nachdenken. In meiner Arbeit geht es darum, wie das funktionieren kann.

Auch so ein Pet Peeve von mir: Wer ist unsere Kundin, unser Kunde? Für wen arbeiten wir überhaupt? Ich hatte einmal einen Chef, für den hat es gereicht, wenn der Auftraggeber zufrieden war. Der hat uns schließlich gesagt, was er sich vorstellt, und von ihm haben wir auch unser Geld bekommen. Case closed. Kontakt mit den Nutzerinnen, Eingehen auf deren Bedürfnisse: Fehlanzeige, und auch gar nicht erwünscht. Die Folge war natürlich ein Produkt, das an den Bedürfnissen der Nutzer*innen vorbei ging. Wie hätte es auch anders sein können, wenn wir Continue reading “Design Thinking in der Politik: Worauf müssen wir achten?”

Design Thinking für Neueinsteiger, Teil 2: Der Lösungsraum

Im letzten Beitrag sind wir der Frage nachgegangen, wie genau wir ein Problem verstehen müssen, um es lösen zu können. Die agile Antwort darauf ist einfach: Immer genau so gut, um den nächsten Schritt gehen zu können, und morgen besser als heute.

Design Thinking treibt diesen Ansatz auf die Spitze. Der Prozess ist durch und durch explorativ, er lebt vom ständigen Dazulernen und vom laufenden Kontakt mit den Menschen, die eine Lösung am Ende benutzen sollen.

Die entscheidende Frage dabei ist die nach dem Nutzen: Was würde dir am ehesten dabei helfen, dein Problem zu lösen? Dagegen tritt alles Andere in den Hintergrund. Tätigkeiten, die niemandem helfen, versuchen wir nach Möglichkeit zu vermeiden. Continue reading “Design Thinking für Neueinsteiger, Teil 2: Der Lösungsraum”

Design Thinking für Neueinsteiger, Teil 1: Der Problemraum

Eines meiner absoluten Pet Peeves in der Projektarbeit ist „lösungsorientiertes Denken“. Leute wollen sich am liebsten gar nicht mit dem Problem aufhalten und nicht einmal überlegen, ob wir überhaupt eines haben, sondern gleich und nur an Lösungen arbeiten. Das geht oft schief.

Nein, nicht, weil ich etwa glaubte, wir sollen ewig in unseren Problemen verharren und nicht über Lösungen nachdenken. Natürlich sollen und müssen wir das. Firmen und andere Organisationen geben uns – oft nicht einmal wenig – Geld dafür, dass wir Lösungen auf den Boden bringen. Das ist das tägliche Brot im Projekt, da sind wir uns sicher einig.

Ich bin aber überzeugt, dass ich ein Problem erst lösen kann, wenn ich es grundsätzlich verstanden habe; sicher nicht in allen Details, aber die groben Umrisse müssen mir klar sein. Nichts ist sinnloser als eine Lösung ohne Problem, und von denen gibt es auf dem Markt wie Sand am Meer.

Design Thinking gibt uns einen Pfad vor, wie wir das Problem, das wir bearbeiten, immer besser verstehen und so immer besser passende Lösungen finden können. Der Doppeldiamant mit seinen divergenten und konvergenten Phasen führt uns von einem Problemraum in einen Lösungsraum. Continue reading “Design Thinking für Neueinsteiger, Teil 1: Der Problemraum”

Design Thinking als kreativer Prozess

„Design heißt zunächst einmal Gestaltung. Zumeist wird unter Design die äußere und innere Ausgestaltung unter ästhetischem Primat verstanden. Die ansprechend, formschöne Gestaltung wird ergänzt durch eine funktional, hoch qualitative, gestaltoptimierte Konstruktion. Design soll also Ästhetik und Technik optimal verbinden.“ (Bergmann & Daub, 2008, S. 58)

Design Thinking kommt aus der Produktentwicklung. Ursprünglich ging es wirklich um das Design konkreter Gegenstände, die man sehen und angreifen konnte, und das kann man an dieser Definition auch noch ablesen. Der Begriff hat sich seither aber weiterentwickelt. „Mittlerweile wissen wir jedoch, dass nicht die physische Gestalt, sondern vielmehr die intelligente, effektive Gestaltung im Hintergrund für den Erfolg der Produkte verantwortlich ist.“ (Gerstbach, 2018, S. 43) Heute geht es um alle Arten von Lösungen, und nicht nur um ihre optischen oder haptischen Eigenschaften, sondern um alle möglichen „Anteile der konzeptionellen und technischen Gestaltung von Objekten und Systemen.“(Uebernickel et al., 2015, 16) Continue reading “Design Thinking als kreativer Prozess”