Let me introduce you to some nice German words such as “Gerüchteküche” (= kitchen of rumours) and “Flurfunk” (= corridor radio) which could be translated to “office grapevine” or “rumour mill”. Over the years I’ve noticed that a rumour is nearly always much worse than the real issue that seeded it. Still, people tend to worry A LOT.
I don’t really get the worrying, because 99% of the time it doesn’t propel people to take action. Not even asking someone in the know if there’s anything to the rumour at all.
So, the worrying is wasted energy on 2 accounts: 1) It won’t turn out that bad anyway and 2) it doesn’t make anyone take action.
I can recall exactly one occasion where reality turned out to be just as bad or worse than the rumours. Did I go “Damn, I wish I would have worried more instead of frolicking about”? No, because in this particular case I couldn’t have done anything to prevent the outcome anyway.
Matt Schlicht puts it like this in How to Become Stress Free in 2 Steps:
Do not stress over things you can not change. Do you think sitting there and stressing out as hard as possible will solve the problem? No, of course not. Solving problems solves problems. It’s easy to get emotional and focused on something stressful, but in the end stress is pointless if you are not putting it to use.
If you run into something stressful immediately skip past that feeling of stress to figuring out if there is a solution. No solution? Move on. Solution? Do it.
How do you deal with rumours?
Most of the agile transitions I’ve had insight into were mandated by management. They were motivated by an ever-growing pile of requests that exceeds the developers’ capacity several times over. The tales of “hyper-productive teams” lead them to think Scrum and fast dev teams will solve all their problems. Clear problem (requests exceed capacity) -> obvious solution (make the team faster), right? Continue reading
Two months ago I started a new job. I left nice old colleagues and got nice new colleagues. The companies are the same size. No big diff there. But there is a very visible difference in the respective offices:
- Old workplace: 200 square metres of whiteboard surface + glass walls – all of them covered with drawings, notes and print-outs
- New workplace: 4 square metres of hardly used whiteboard surface and empty walls
The impact on communication is tremendous. Meetings in which we talk about systems I’m not yet familiar with and no one draws a picture… I’ve always thought I’m the visual learning type. Now I’m sure of it, because without a sketch I can only follow half of what is being said. I find myself unable to picture it in my head.
Unfortunately I can’t remember what it was like before my last job…
- Was I once better at picturing stuff in my head, then lost the ability, because visualization made it unnecessary? Like an untrained muscle?
- Or was I never able to do it? (But since I hadn’t known that 98% understanding are possible, I didn’t realize I was missing out.)
It makes me sad when a PO presents a new story and the first thing out of a developer’s mouth is “It can’t be done!”*. A story is meant to be the basis of a discussion – “It can’t be done!” is harmful to this discussion.
As long as there is no timeframe attached to the story, “It can’t be done!” is rarely true.
Just like “I don’t have time for that!” is code for “It’s not a priority”, “It can’t be done!” is usually code for something along the lines of:
- We’d have to do a major rewrite. It would take months!
- That code is chaos. No one knows how it works. I don’t want to touch it. I’m afraid to break something.
- I can’t think of a way to achieve it. (In this very moment.)
- I don’t want to do it.
- I think that feature’s stupid but you won’t listen to me, so it’s easier if I declare it impossible.
- I could do it, but you’ll just change your mind in a week’s time and I’ll have to throw that code away.
- We can’t afford the expensive thingamabob, we’d need to achieve that.
You know that saying “Don’t judge a book by its cover”? Well, I usually do jugde a book by its cover and I’d never have bought “Systemisches KONSENSIEREN” (“Systemic CONSENSUS”)! When a colleague dropped it on desk, I made fun of it – its whole appearance is “touchy-feely” in a bad way and, come on, CAPS? Really?
Fortunately, I picked the book up on a whim and its main (and only) idea immediately took the top position on my list of “things to try out”: When voting, don’t have the usual majority vote that generates winners and losers. Turn traditional voting upside down and determine least resistance!
Let me illustrate how that works with the first example in the book: Continue reading
Apparently I’m stuck on the topic of decisions, but whereas the last post was about manifesting decisions, this one is about avoiding them. Well, at least a certain kind of decisions: The kind where teams need to do something regularly, but it doesn’t matter which team member does it, as long as it’s done. Let me give you some examples:
- Who takes care of ad-hoc support requests in a team of admins doing kanban
- Which scrum master writes the weekly “What are the scrum masters doing, anyway”-mail
- Which team member attends the SoS. (In my workplace the SoS is a stand up of team members, not the scrum masters.)
Because each of these decisions is tiny and not very significant on its own, people are sometimes reluctant to agree on a long-term arrangement that eliminates the string of tiny decisions. They figure, they’ll just take them each time they present themselves, because, hey, tiny, right? What ill could possibly happen?
Turns out, a variety of ills: Continue reading
That awkward moment, when you ask “Shall we try that?” and the most response you get is mumbling… You’re not quite sure what to make of it. It usually means that nobody is opposed to the idea, but does anyone want it? So you end up hanging in the air with a non-decision and just continue with other stuff. Sounds familiar?
Well, you can kiss that good bye. A colleague of mine introduced an extremely simple, yet effective, technique in our company: In such situations everyone is encouraged to loudly ask “Was that a decision?” That one question gets enough silent or mumbling people to voice a “yes” (albeit not resounding) to make it clear to everyone, that a decision has indeed been taken. I see a definite improvement although only about 5 out of 35 people picked up the habit of asking that question.
PS: If you’re not interested in just a “yes”, but degrees of support, try Fist-of-Five (in German).