PolyConf, Poznan Oct. 30-31

Yesterday I received a message from JUG mailing list that PolyConf Conference was announced.

As I mention in A Thought on Design Patterns I found a polyglotism as a reasonable way the modern software professional should follow and am glad to hear there is a conference supporting this. I am excited to see what they will present.

Diagnosing organisational problems with I-Messages

This article is part of my work on Conversation Patterns for Software Professionals

---

Typically conflict between people or teams is a symptom that indicates there something's up. The tool I use for that situation is based conversation patterns. With this tool you will be able to come to a bigger picture on what is really going between people.

There is very strong assumption behind this tool need to be accepted first: people are not problems on their own. A behaviour may be a problem, environment, lack of skills or even belief may be problems, but not a human being.

You-Message

In case of issues causing a conflict and lots of negative emotions people tend to express their statements in a specific way - they talk about others. Take a look on some real-life examples

• PM: Developers are always delayed
• DEV: PO must know what he really wants
• PM: The problem is team's velocity
• DEV: Requirements are not specific enough
• PO: Developers spends time on useless refactoring or something
• DEV: Business people are always changing their minds
• PM: They didn't tested all features

I have interviewed lots of people and mostly I hear same messages: He is..., They should be..., She don't... and so forth.

But what invariably surprise me most is that all of them seem to be true. Really! Spending whole day interviewing developers I came to conclusion - Damn, what the crap they deal with?. Same talking with business people I often think God, what a hopeless situation!. Every story I have heard make sense in its context.

I imagine this kind of communication something like that

The more individuals I talk to, the more chaos appears in my mind. It is really hard to understand what is going on basing on those stories.

Aha moment

Then I finally understood - all those people talked about themselves. They expressed their needs and expectations, but they do it in very indirect way. Talking with the You-Message makes other people the source of our problems and there are only two solutions in that situation: fight them or leave them.

I-Message

I followed this idea and I started using the Need Structure and Upward Generalization Pattern to lead my interlocutors to express their needs in the form of I-Message.

What are the I-Messages? These are statements where one expresses oneself, eg. I want..., I don't..., I like to..., I am lack of..., I need....

Be careful, statement I want you to stop is You-Message like not the I-one like. With I-Message you express just only yourself and nothing more, this is critical.

So, this kind of communication I imagine something like that

And some examples of transforming You- into I-.

You-Message	might mean / I-Message
Developers are always delayed	I need to close projects on time I don't want to work under time pressure I am accounted for time and budget I want to be kept informed of any problems which may cause delay as soon as possible
PO must know what he really wants	I don't fully understand what to do I need acceptance criteria for every user story I start to develop I want to be kept informed about new ideas as soon as possible I want to have an impact on the sales strategy

Notice that I-Messages express needs very clearly and it may turn out that all individuals want same thing eg. to be kept informed.

Putting people stories in the form of I-Message introduces lots of order to the communicational chaos. It's easier to see what is going on and what is needed.

Next I use Conversation Structure and Downward Specification Pattern to clarify acceptance cirteria of met needs and for negotiating the solution.

InfoQ: *-Driven* do not change anything

InfoQ Team has published my aricle *-Driven* do not change anything.

I gave a speech on these theses during the 33rd Degree Conference 2013 and I was told I didn't know Domain Driven Desing at all. Well, I have my private opinion about this. But I am sure I know how the cognitive biases work and all that *Driven* madness is one of them.

This article is not intended to criticize anybody or anything. It is about priorities and searching for a balance. Being focused on our basic skills first, helps to use a *-Driven* approach properly especially in an unknown context. I do really appreciate all those mental frameworks because they do great job. But I think if software development is driven by something, these are stakeholder needs and our common sense. Being driven by anything else might be harmful simplification.

Enjoy the article!