It's Not Pround To Be Geek

Although 'Geek' defines some identity for a developer, being geek doesn't sound proundly for me. One having accepted this identity delimits oneself at the same time.

When you think you are Geek also create responsibility related to being Geek. Then it is easy to say: I am Geek, expecting an excellent requirements to start working or I don't wanna talk to stakeholders, this analyst's job, I am Geek or something else.

I've seen many IT-related conferences speeches. My observation is lots of speakers builds their authority around of being Geek. They leverage IT-business cooperation problems, present business-IT relationships with distorting mirror and think it's funny. Well, that is funny for geeks, but not for agilist.

Differentiating from 'Others' is a very powerful strategy for a speaker or for an individual in general. This strategy underlines what a group of individuals have in common and how they differ from 'Others' (read: business), helps to feel more self-confident. But this strategy doesn't help to be more open to a relationship with 'Others'.

So don't be Geek, but Agilist :)

Conversation Patterns: There is kind of chemistry between us

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

---

Trying to apply techniques collected by Conversation Patterns, you may be wondering is this enough to have an effective conversation. Well, this is definitely enough to clearly define stakeholders needs and to specify their expectations in a required form.

Conversation Patterns are mechanics-part of a conversation and there is very strong assumption behind them, which must be satisfied to make the techniques work. It is assumed there is kind of chemistry between you and a person you conversate with.

I cannot define what the chemistry-part is, but sure you know what I mean. You are willing to talk to the person or you aren't. That's all. So, without any kind of chemistry you won't be able to discover any needs or to gather any requirement. That is because the use scope for Conversation Patterns is a stakeholder will to cooperate with you.

I haven't mixed that two: mechanics- and chemistry-parts on purpose. I think it might make the model over-engineered and unclear. I've been testing many approaches for last five years. Some of them were strongly persuading and some where old-fashioned communication techniques. Personally I've chosen Non-Violent Communication (NVC in short) for the chemistry-part.

NVC is philosophy actually and bunch of techniques developed by Marshall Rosenberg Ph.D. NVC addresses the chemistry-part by giving an empathy to a person. It is also about discovering needs, but Marshall Rosenberg discovered we all have same needs for love, safety, community and so forth. Unfortunately these needs are hidden behind feelings, so they must be recognized first.

To distinguish NVC needs and need model I've developed, I call them human needs. They are actually shared by all human beings.

It worth to mention that NVC is not techniques for giving human-detached empathy. During a training you learn to distinguish: an environment, feelings, human needs and strategies for fulfilling these needs.

This is kind of mental shift. It makes you more aware of that chemistry-part. You start carefully using a language, not for judgements but for expressing yourself. Finally, you are able to see through all tensions and misunderstandings which may happen, and behold stakeholders asking for your help.

Local Adaptive Step

Every team wants to do good job, but almost always they face with some adversities. These may be: unclear requirements, delays, communication issues and so forth.

Let's say a team wants no extra features during an iteration. This is quite logical expectations, but... things are more complicated. Extra tasks comes from PO, PO is pressed by CTO, CTO is pressed by CEO and CEO is extremely pressed by impatient client.

So, applying the system thinking to this picture it turns out that cause of problems defined by a team might lay in The System organization, not always in the team itself. That's useful point of view and it helps to find a solution in many situations.

However it works, a team or a team leader might not have the authority to reorganize The System. Even if one were a client is mostly beyond of one's influence. So, from one side a team is sure the problems are: clients or salesmen or management:). It wants all of them to change and to follow strictly the Scrum, Kanban, RUP or whatever guideline. Sometimes it's possible, but those are rare cases. Frustration grows up. What to do then?

Maybe start thinking locally, here and now

Let's forget about formal methodologies for a while and think about a team as an agent in the context of some organization.

Now we may observe a team is responsive to surrounding forces.

Instead of implement a methodology causing lots of organizational change (and also mess), let's do a local adaptive step toward the state of balance.

A local adaptive step is actually searching for a balance between all forces surrounding a team. Do whatever needed. You need for Use Cases - do Use Cases, need for formal docs - write a formal docs, don't need for iterations - don't do it at all!. So, a team is not expected to be agile, but it's expected to be balanced.

There are some of my insights on constraints a team have to be assured to do a local adaptive steps.

• a team is fully responsible for expected results of its work
• a team is free to make all decisions needed to achieve results
• a team is free to reorganise its structure and process of work