InfoQ: Conversation Patterns for Software Professionals. Part 1

InfoQ Team picked my article Conversation Patterns for Software Professionals to publication. Enjoy the piece! Next episode is coming soon.

Agile 2014 Feedback

I've received feedback from Agile 2014 attendees. The feedback questions are based on a 5 rating scale, with 5 being the highest score. We have:

• Session Meets Expectations: 4.00
• Recommend To Colleague: 4.00
• Presentation Skills: 3.83
• Command Of Topic: 4.17
• Description Matches Content: 4.00
• Overall Rating: 4.00

and comments as well:

• Michael's approach falls directly between the geeky, form-based, completely objective approach and the soft-skills, humanist method - something that software people should be able to grasp very quickly. Great job!
• Michael was nervous but brave presenting in a language different than his primary language. I want to assure him that he did very well and hope he will present enough to be able to relax. Many Americans know only English. The fact that many of the presenter know multiple languages already gives them an advantage.

For me it's great because had high hopes for my talk. One what I want more are attendees - this time were 24-25 people.

Listen to Your Product

This year at Agile 2014 I met Raje Kailasam who talked about very interesting approach which is Product Humanization (PH). As Raje claims, she's still searching for a good name. She also consider Product Persona as a name. As you'll see later on, Product Experience (PX) seems to be good name as well.

In short, PH/X is an idea to stand in your product's shoes and feel what it feels. Sounds awkward, huh? Let's take a deeper insight.

If I asked you about next features or a next sprint scope, you would start thinking about answers but in the same time this process would be biased by doubts related to: budget, velocity, technical dept or whatever. That is because your logical thinking tries to find 'the best' answer according to you current situation.

But when you identify yourself with your product, you may employ whole your body to this process and express what the product feels (if it could) and what it think as well.

Take a look on free-style examples we recorded at the conference.





During this short session we also draft two techniques employing Raje's approach.

Product Interview

Purpose of this technique is to grab some deeper knowledge about current state of a product. One of the Scrum Team members plays the product role, rest of the Team interview him or her.

We found the critical part is questions you ask the product. These seem to work well:

• What do you as an entity want to be?
• What do you want to do?
• Where do you want to go?
• How do you want to be served?
• Why do you want to exist?
• What do you want to see?
• With whom do you want to belong?
• Who are your friends?
• How do you feel now?
• How do you feel about your future/past?
• How do you feel about your body? Tell me more about it?
• Which of the part of your body you are aware the most now?
• What do you feel about your relationships? Which are difficult? Which are not?
• What is important to you?
• What do you want to say? To whom?

Use collected answers to improve Product Goal, Releases, Epics, Product Canvas or to identify places to introduce improvements to increase business value.

Product Advocate

It is about employing an advocate of the product during Scrum planning meeting.

The Advocate tells the Team and PO how s/he feels about new stories, sprint goal and scope. Use the answers to improve Sprint Goal, User Stories, scenarios.

These is early draft of Product Humanisation. Watch Raje's activity to stay up to date.

Agile2014, Orlando Premiere

This is a presentation I am going to show at Agile2014 in Orlando next Thursday. So, I publish it just for you :) Any feedback is welcomed.

If you going to join my talk, please watch these comedy sketch first.

A Word on Business-IT Collaboration

However there is bunch of strict means related to business-IT collaboration, the effectiveness of collaboration is often understood as a very subjective sensation.

When business and IT play together there are well defined process and rules, but these are second-order things. What people value the most is mutual involvement in a collective goal.

In these situations I've noticed that:

• collaboration rules are given explicite in a visible way
• there are also explicit rules in case of emergency
• the rules are for better collaboration not for accounting sb. for tasks
• when one doesn't follow the rules this means the rules don't fit to the worklflow and must be changed
• rules come from workplace and people who do work not from management
• rules are changing because reality is changing and that is OK
• the rules above are written in hearts not always on the paper

It's All About the Culture

I was attended in really interestnig conference Agilia Budapest by Aguarra company.

The greatest thing was that almost all speakers brought some new ideas and some new approaches in the subject.

So one of the speakers was Andrei Boghiu Product Manager at Prezi, so you probably know who they are. Adrei talked about the product development process in Prezi, from a feature idea to a deployment. He talked about their: continuous learning, constant feedback from the market, lack of documentation in favour of prototypes, collaboration between people, flat organisational structure and so forth.

I listened to him and in that moment I realized Wait a minute, I've heard something similar! Same story I've heard from Spotify guys and the guys from the ThoughtWorks and Touk and SoftwareMill and from couple other companies.

But you know, every time I hear those speakers, I also see people who try to repeat the success story in their own companies and they fail. What is wrong with that?

My observation is that bright companies talk only about the solution they use. However that solutions are well known it's a hard work to implement them with positive results.

Think about it, even if a company use prototypes and screens instead of stories and scenarios, how they convince people to do that? How they engage the people in taking the responsibility instead of waiting for the orders from top management? Finally, how they created the environment where all that well known stuff perfectly works in?

I asked Andrei about it. I think he was little bit surprised by this question ;) and he mentioned couple interesting things such: they engage people to make failures and learning, people (I mean engineers) directly influence the business activities. These are parts of their organisational culture. Yep, it's all about the culture. The culture is the factor which turn all mentioned solutions from an idea into the everyday habits.

Adrei et al. take their organisation cultures for granted, they find difficult to explain what it exactly is. They are simply affected by the culture of their organisations and work in that way.

This is the question I wonder the most: How the specific culture was created in the organisation? What were the steps they used? I have no any doubts that was made on purpose even if the creators were never named what they actually did.

This question requires some deeper researches and interviews.

The 7 Duties of Great Software Professionals. Really?

There are two reasons I am not a fan of this talk. First, once you saw Anthony Robbins' motivational speech you don't want to see anybody else. He is simply the best!

The second reason is that in this speech the author offers some challenges to developers, he suggest that setting and achieving professional goals is the way a developer should follow to become great.

Well, goals are very popular and well known self-motivation tools, but they sucks. Why?

Setting the Goals

Being driven by goals is endless race from one goal to the next one, and then when your first excitement is behind you, you may wonder: What was actually for?

As Paweł explains (in Polish) achieveing a goal is a desire of more dopamine in our brain. Every time you achieve a goal, you get a reward a in form of dopamine self-injection.

Unfortunately training yourself in achieving goals causes you get more dopamine b-e-f-o-r-e achieving and after that you get just only teeny-tiny injection. You feel not so good as you expected, so you want more dopamine. What you do then? Set next goal.

Desire of goals means constant staring at the difference between your current state (before ticking a goal off) and future state (after getting it done). This difference is Dis-Satisfaction.

However the delta form the structure above is called a resource needed to get the goal done, in fact this is the difference between two emotional states, two dopamine levels. This difference is felt as some discomfort.

The race form a goal to another one is driven by Dis-Satisfaction and the only way to avoid this feeling is more and more dopamine, more and more achieving.

Mindfulness

So let stop for a moment and try to see things as they are...
Mindfulness is a concept moment-by-moment awarness when you try to liberate yourself form the desire of achieving.

Following the mindfulness way you accept reality as it is and observe your relation to this reality. Obviously as human beings we need goals and we need achieve things. Starting it with awareness you achieve goals if needed, but you do it being awaken from the dopamine dream.

Hmmm...it was a little bit off-topic, but who cares...;)

DDD from a Non-Java/C# Developer Perspective

During 4Developers I met some friends who are PHP and Perl developers. They were very interested in what kind of value Domain Driven Design may bring to them.

They found the topic very confusing because in their opinion speakers were strongly focused on Java and Object-Oriented programming. Those developers made connection between DDD and OO-programing especially in Java and C#. I think it's kind of misunderstanding.

Let's see some examples of what domain expert could say (credits to Sławek):

Domain expert says:

When a piece of art is viewed as a thumbnail by a customer, one is able to show interests in this piece of by adding it to the LightBox.

The system should generate the offer from the reservation.

An offer contains just only available products with current prices.

A customer is not obliged to accept the offer. One is able to accept or reject it as well.

and so forth...

So we have some domain scenarios in a very unstructured form as were expressed by the expert.

To build the right software we model a domain base on expert knowledge and domain scenarios.

And here I wanna to put strict distinction: the goal is to model the domain but using building blocks given by DDD community is just a way to achieve this goal in the Object-Oriented world.

In my opinion pure DDD modeling should be based on Domain-Specific Languages when we have language to directly express what the expert says and how the domain works. This programing style is even easier to apply with some script and loosely typed languages.

So, if you are non Java/C#/OO professional, please be sure you may get benefits with using DDD. You don't need building blocks in the form they are currently presented, because they are implementation of DDD in Object-Oriented context. The core is to model the domain and maintain pure isolated model in a form suitable to the technology you use.

The Paraphrase Pattern

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

---

During a conversation with a stakeholder one gives you heap of chunks related to the issue. First you are unaware of language a stakeholder use, terms and their meanings and rules playing behind these elements of Ubiquitous Language. You will discover all this stuff during conversation asking right questions.

Read more about Paraphrase Pattern on http://conversation-patterns.com

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!

We Need You to Draw Seven Red Lines (...) Can You Do That?

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

---

Never, ever answer this kind of question! But let's start from the top.

I think that every single software professional has seen this movie.



Beauty of this show is the Authors extremely clearly grab the structure of the communication gap between business and technical folks. Probably you have also experienced conversation similar to the one above.

But there was the critical moment which determined the conversation flow went toward the absurd. This is the moment I'm writing about:

Look at the Expert eyes. When the question was asked, he stoped breathing for while and he slightly moved eyes up. What did that mean? Well, this is not Math, but I recognized that he fired up BusinesRuleValidator and he started thinking about a solution.

His intention was obviously positive - he tried to answer the question. There are couple things need to be emphasised in this case to help the Expert to handle the situation.

They didn't want seven lines to be drawn

Really, they didn't want those lines at all. The wanted to achieve some benefits (but not this general blah blah from the beginning :) ) and they want their problems to be solved. The lines were just only their idea to meet these needs.

So it would be more comfortable for the Expert to discover these needs first instead of explaining them what is possible or what is not. The Upward Generalisation Pattern was designed for that purpose.

Keep technicals for your teammates

Don't explain geometry rules to people who are unable to distinguish colours and perpendicularity :) When you are attendee of that meeting, collect as much information as you're able to. Answer some questions (basically using metaphors or analogies), but for God's sake don't dive deep into technical details.

They're not partners to this kind of conversation. They are excellent source of needs and business cases, but keep technical details for your teammates.

They reframed contexts to push the Expert into commitment

Task is clear! How do you know before you try? Now you've confused everyone! What exactly stop us? Just ignore it! Seven red lines it's not twenty! You don't see overall picture! It's not a difficult task! Suggest a solution! Any fool can criticize!

Statement's above are so-called reframings. In general reframing is a technique to stretch your perspective by swapping context behind your point of view. The operation challenges your beliefs related to the situation and gives you a deeper insight into the one.

But you may also backstab with a reframing. In the sketch business people use the statements above (which may be true in some contexts) to gain their persuasion power and push the Expert into commitment. Of course the statements are not valid in the context of the conversation, but this was concealed.

Don't ask this kind of questions

Always commit yourself by three phases: Listen-Analyse-Commit. That's ok to refuse the commitment question till you analyse the situation.

It's not a big deal to commit oneself to do something. The challenge is to bring the thing done. My practice is: commit myself on the next meeting :)

You are definitely the Expert, you should know better

So, if you say you need more details - you definitely need it!
If you say you need an specific example or use case - you definitely need it!
If you say you are unable to answer now - you're definitely right!

You are part of the meeting not because of nodding but because of your expertise. You are trustworthy because you are able to say both: 'Yes' or 'No' if needed.

Conversation Patterns: Navigating Through Cynefin's Quadrants

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

---

After Cynefin workshops with Dave Snowden I have some ideas how this model might help to work with stakeholders during a conversation on business domain, requirements or something else. BTW: Mariusz's article is a great introduction to the Cynefin framework.

Recognising the Cynefin's quadrant

As Scrum is a method to move work from Complex to Complicated quadrant, Conversation Patterns move conversation flow to Complicated or Simple quadrants.

Let's take a look on Cynefin's quadrants from conversation point of view.

Simple/Ordered quadrant

Order doesn't exit in the nature. This is the law and Dave Sowden words:). You are in the Simple quadrant of a conversation when you talk about facts. Howover the 'fact' word is very tricky. We often think we talk about facts, but in fact we talk about opinions, points of view and narratives.

Techniques to move conversation flow to the Simple quadrant.

Specification By Example

because an example is a single source of truth

Downward Specification Pattern

discovers specific criteria behind a stakeholder need walking down the conversation structure

Paraphrase Pattern

verify your understanding of what was said

Term Structure

strictly defines given term in the given context

Complicated quadrant

This is a place where we need to analyse the input to decide what to do next. Most well-arranged conversations happen inside this quadrant. Typically when all Complicated things are addressed we move the conversation flow to the Simple quadrant.

Techniques to use here:

User Story Mapping

gives a big picture for the product, epics, stories and its details

Conversation Structure

is an mental view of conversation steps, which helps to navigate through a conversation flow, staying focused on the subject and objectives

Downward Specification Pattern

discovers specific criteria behind a stakeholder need walking down the conversation structure

Complex quadrant

You are here where you don't know what to do. Tips given by Snowden here are:

• don't predict the future, make decisions in the present
• do some (not to much) experiments which are: coherent, save-to-fail, finely grained
• include 'naive' approaches
• include few high risk/high return options

When a conversation is stacked here, we need to discover what to follow next to reach Complicated or Simple quadrants. So these are techniques useful here:

Need Structure

defines well known but fuzzy term 'stakeholder need'

Upward Generalization Pattern

looks for the unmet needs behind the one's expectations

Transform Benefit into Problem Pattern, Transform Problem into Benefit Pattern

these explore a stakeholder needs in many directions

Questions for Setting Priorities

this is sequence of techniques to filter out less important requirements or wants

Business Value Games

look for values for a market

All reframing techniques

try to change of your perspective to see differently or to see more

Chaotic and Disorder quadrants

You lands here where something happens what make the conversation unpredictable. These might be: strong negative emotions, talking about not important things, arguments.

Being here you better suspend your conversation goals and focus on moving the conversation out of this quadrant.

Techniques working here are:

Giving an empathy to a introlocutor

these are a bunch of techniques and mindset which assume that being in contact is the most basic need for a human being

Positive Intention Pattern

this is soft reframing technique which gives a suggestion that an intention behind strange behaviour was positive

All pattern interrupt or state change techniques

set of interventions to rapid change a negative emotional state; these are widely used by coaches, trainers or therapists

Oblique games

(do you know better name for this?:)) this kind of games where participants are involved in a game (a context is important but not so much) but the narration (so called 'structure') leads participat toward wanted results e.g. conflict resolution; and example of that games is Multitasking Game by Henrik Kniberg

Agile2014, Orlando

This is a latest news: my submission Conversation Patterns for Software Professionals was accepted on Agile 2014 Conference.

Reviewers who have been helping me to improve the submission commented: 'this the heart of Agile'.

So, if you plan to participate the Conference, join my presentation. I will really need your support.

Requirements Engineering, Poland 2014

On tuesday 18/03/2014 I will give a presentation during the Requirements Engineering Conference, Warsaw/Poland. It will be Conversation Patterns for Software Professionals.

I have also prepared three-hours-long workshop: Working with Stakeholders' Needs. We will focus on how to use Conversation Patterns to define user stories driven by needs.

Don't miss the 4Dvelopers' Soft Skills & Business Relations track

This year I am responsible for the Soft Skills & Business Relations during 4Developers Conference. This is very important to me, because this track also reflects my personal journey through the soft skills way.

I invited some friends which supported me, so this track is also my tribute to them. I do recommend you to join the track and to listen carefully their stories.

This is my short introduction.

I met Hubert in 2004. We worked in the same company. He was my first trainer and coach, and made me aware what soft skills might mean to a software developer. His speech: Practical Psychology for a Software Developer will be kick-off for the track.

Marek Rudziński specialises in supporting of sales departments. I met his and his wife Iza in 2008 when I joined to their three years long training program for a trainer-wanna-be.

I work with Kamil in BNS IT company. He is great coach. He have done lots of work with technical leaders. His speech Magic power of coaching will give you a good insight what coaching is.

Currently I am involved in Non-Violent Communication training program guided by Zofia and his husband Kersten. NVC is nowadays a hot topic in agile world. Zofia's speech Kontakt i zaufanie w relacjach między klientem a programistą will indroduce you in the NVC world.

Presentation Layer Under Control

Hower there is bunch of patterns addressing presentation layer issues, implementing clean presentation layer in Java desktop application is tricky task. Main problem for me is a lot of mess inside. I'd like to present my approach to take control of presentation layer, which is combination of existing ideas such: Supervising Controller, Passive View, Presentation Model, Publish-Subscribe, Observer.

This will be an approach, not a pattern. The reason is a pattern is something widely used and this will be just set of tips. So you won't be able to apply it by just repetition some steps, but by interpretation the approach in the current context and SOLID analysis. But if you are not familiar with patterns listed above and presentation layer issues of desktop application, try Mediator pattern or SmartUI approach first. You will have some mess in the code but still under control.

So, if you want to take a look on risky implementation of a presentation layer, check out this example. As far I remember some folks call this SmartUI anti-pattern.

Well, the UI is really smart in the example. It contains child UI components, implements listeners and does both UI and business processing. This GUI is simple but continuing this approach leads to code which is hard to understand, hard to test, hard to develop.

The idea

Let's list challenges for the desktop applications with visual presentation layer:

• communication between controls
• managing application state - there are three types of it: screen state, session state and record state
• type conversion between view and rest of the application
• handling user events
• keeping GUI responsive - typically with threads
• testability - Humble Dialog aka MVP is a solution

Take look on the figure.

In the typical application all controls are grouped by their business purpose and UX rules. Let's treat the controls arrangement as being not so important for the application architect. What is important that we have many groups of controls, each group has its business purpose and groups need to communicate with others. Let's call these groups components.

However components might be visually arranged in a hierarchy (depends on UX designer), from the source code side they are totally equivalent. Component to communicate with other component use an event bus. When an event comes to a component it updates its state (what mostly means a user view is changed) according to the subscribed event.

Using event bus gives all benefits of the Publish-Subscribe pattern. You may use topics or even two or more event buses for really complex GUIs.

This was an idea. Now let's take a look how a component is designed inside.

Structure of a component

Five parts works together as a component.

part	responsibility	out of responsibility
Form	* is coupled with a particular GUI technology * builds itself * has private helper methods to working with embedded controls * calculates a control arrangement	* business processing * calling calling services * validation event publishing
FormEventHandler	* implements all technology-specific event listeners * might be decomposed into specialized handlers e.g. DragAndDropHandler	* subscribing events other than technology-specific * business processing * calling calling services * validation * event publishing
View	* exposes methods for getting and Form state (see Nice Move with ValueSetter) * typically is implemented by Form classes	* event publishing * event subscribing
ViewObserver	* notifies that something happened on a Form * typically is implemented by the Presenter class	* event subscribing
Presenter	* calls business services * publishes events addressed other components * subscribes on events from other components	* business processing (except of very rarely cases)

So how you see, a component talks to other components via event bus, but asynchronous communication inside the component is implemented via Observer Patterns. There is nothing wrong with using event bus inside the component also. But in my opinion the solution with event bus outside- and Observer inside- is more clear and easier to test.

and how it works?

Here you have a diagram how a user request is processed by a component.

and also how components talk to others:

ViewModel - what is for?

The problem is how to deal with screen state (keeping Form as stupid as possible), especially when you work with the remote backend and you need to synchronize the client with the server.

Possible solution to this is introducing a session state which is in-memory copy of screen state. Presentation Model pattern do that. The pattern represent the state and behavior of the presentation independently of the GUI controls used in the user interface. It is possible to find Presentation Model structure in this approach. These are: View interface and Presenter.viewModel property.

However implementing Presentation Model is not the goal, I have borrowed viewModel part from the pattern. Why?

In regular MVP pattern View exposes methods to set and get state of Form controls. It's something like that:

public class DetailsPresenter implements DetailsViewObserver {

  private DetailsView view;

  public void handleRequest() {
    String name = view.getName();
    String name = view.getTitle();
    Date dayOfBirth = toDate( view.getDayOfBirth());

    //call services

    view.setTitle( newTitle );
    
    //...
  }
}

This approach causes lots of set/get methods in the View interface. Because the fact that some controls states are needed to business processing the Presenter handler methods are full set/get/add invocations.

An alternative to this is full-featured Data Binding. When something changes on the screen it is automatically reflected to the viewModel and vice versa. Really magic Data Binding means lots of listeners, controllers and events going there and back again.

So, what instead? Map? Well, map might be a bag for everything, but idea is good. I use the apache-commons DynaBean as viewModel implementation. ViewObserver exposes the method to notify about changes of screen state.

public class DetailsPresenter implements DetailsViewObserver {

  private DynaBean viewModel;
 
  private DetailsView view;
 
  public void buildViewModel() {
    viewModel = new LazyDynaBean();
    viewModel.set("name", "Jack");
    viewModel.set("title", "Dr.");
    viewModel.set( "dayOfBirth", new Date());
  }

  public void handleRequest() {
    String name = viewModel.get("name");
    String name = viewModel.get("title);
    Date dayOfBirth = viewModel.get("dayOfBirth");

    //call services

    view.updateControl( "title", viewModel.get( newTitle) );
    //or updateAllControls()
  }

  @Override
  public void propertyChanged(String property, Object value) {
    viewModel.set(property, value);
  }
}

public class DetailsFormListener implements DocumentListener {
  
  private DetailsViewObserver viewObserver;

  public void changedUpdate(DocumentEvent e) {
    viewObserver.propertyChanged("title", e.getDocument().getText());
  }

  //...
}

Implementation details

You may fetch examples from my Github profile.

pl.bnsit.architecture package

This is basic template of the approach.

pl.bnsit.flights package

This is an example with coule windows, validation and so on. But I followed the typical llayered architecture.

pl.bnsit.onepieceflow package

There I went a step ahead. I tried to write simple Kanban board. But I started thinking iin a component-like way. I asked myself What are independent components on this GUI? and answered: a card, lane containing set of cards and board containing set of lanes. Then I realized that the independency might be considered through all application layers, not only inside the presentation layer.

Continuing this way of thinking we come the architecture with small, well-defined components anchored in the business domain, which are working together to do a business task.

Type conversion

Notice that some type conversion must be done between viewModel and Form. I did this with TypeConverter interface:

public interface TypeConverter {
  String toString( Object anObject );
  Object fromString( String str);
  Class type();
}

Conversion is done when the control state is updated:

public class AddingCustomerForm extends JFrame implements AddingCustomerView {
 
  private Map converters;

  public void updateComponent(String id, Object value) {
    Object convertedValue = convert(value);
    JComponent component = components.get(id);
    ValueSetter.get(component.getClass()).set(component, converterValue);
  
  }

  private Object convert(Object value) {
    Object converterValue = value;
    
    if( converters.containsKey(value.getClass()) ) {
      TypeConverter converter = converters.get(value.getClass());          
      converterValue = converter.toString(value);
    }

    return converterValue;
  }

and back, when Listener notifies via ViewObserver that control state was changed.

Agilia 2014, Budapest

I received great news. They accepted my proposal I had submitted to Agilia 2014, Budapest. I am going to talk about Conversation Patterns for Software Professionals.

We have created lots of tools which are intended to structure fuzzy or unclear business needs. We have created use cases, user stories, acceptance test and so forth.

Although the tools above were designed to improve collaboration with customers, we use them to hide ourselves from business people. Instead of talking to an individual, we tend to complete the forms.

The issue motivated me to start working on Conversation Patterns for Software Professionals, which are techniques for having better conversations with stakeholders and drilling their real needs. The Patterns makes soft skills more technical guy-friendly and easier to apply.

I do believe that quality of answers you get attests to quality of questions you have asked. So, which of the following questions will give the most valuable informations?

• Do you want to add new items to the backlog?
• What of new items you want to add to the backlog?
• What of new features you're going to use next week?

Not sure? Join this presentation and verify questions you use to ask.

This will be my first conference outside of the Poland as a speaker, so wish me luck!:)

Agile Organisational Culture

One of the most painful lacks of applying Agile is, in my opinion, the situation when we incorporated an agile structure but organisational or working culture remains pre-agile.

Organisational culture includes the: human behaviours, skills, beliefs, organisational values, mission and visions, language expressions, symbols, norms what is allowed or what is not inside the organisation. So all these things putting together make a mental shift toward being agile.

Applying Scrum or any framework in most cases gives a structure only. I mean: PO, SM, Team, Backlog, charts, meetings, workflow and so forth. But it's not enough to Scrum brings benefit to your organisation.

Even if DevTeams and business teams commit they know they are a-g-i-l-e now, they will fail because of misunderstandings what agile organisational culture components (listed above) mean to them.

As far we give the agile structure to people, we also need to align every part of organisation with ubiquitous agile culture.

Nice Move With ValueSetter

I've been working on software architecture refactoring for last couple weeks. During a workshop one of architects showed me an interesting approach.

We were applying MVP-like style and then faced with the question: How a Presenter should tell a View to change its state?

Brute force approach looks like following:

public class Presenter {

 private View view;

 public void doSomething() {

//Here, services are processing something really important

 view.setTitle( "Updated" );
 view.setName( "New name" );
 }
}

public class Form extends JFrame implements View {

 private JTextfield nameTf;

 @Override
 public void setTitle( String title ) {
  setTitle( title );
 }

 @Override
 public void setName( String name ) {
  nameTf.setText( name );
 }
}

Well, this is actually ok, but the more components you have on the form, more verbose View interface becomes.

The move I am talking above is encapsulating a setter into separate object. Look here:

public abstract class ValueSetter {

private static Map<Class<?>, ValueSetter> SETTERS;
 
 static {
  SETTERS = new HashMap<Class<?>, ValueSetter>();
  SETTERS.put(JTextField.class, new JTextFieldSetter());
 }
 
 public static ValueSetter get( Class<?> type ) {
  if( SETTERS.containsKey(type) ) {
   return SETTERS.get(type);
  }
  
  throw new IllegalArgumentException( "Missing ValueSetter for " + type );
 }
 
 public abstract void set( Object target, Object value );

 private static class JTextFieldSetter extends ValueSetter {

  @Override
  public void set(Object target, Object value) {
   ((JTextField)target).setText( (String) value );
  }
 }

 private static class JFrameSetter extends ValueSetter {

  @Override
  public void set(Object target, Object value) {
   ((JFrame)target).setTitle( (String) value );
  }
 }
}

Now it is possible to write more elegant code:

public class Form extends JForm implements View {

 private Map<String, JComponent> components;

 @Override
 public void updateComponent(String id, Object value) {
  JComponent component = components.get(id);
  ValueSetter.get(component.getClass()).set(component, value);  
 }
}

So thanks Marcin for this nice tip and fresh idea for me ;)

Extremely Pragmatic Software Architecture

Since the Measuring Software Architecture I have beeing digging through two systems written in not so mainstream technologies and some crazy idea occurred to me.

Do you know what is the biggest problem for a developer when one starts to develop a system? Lots of Mess (upper case on purpose). All that hundreds of hundreds interfaces with one, two or three methods. All that Abstract*, *Impl, Generic*, *Helper, *Support classes, which implement all mentioned interfaces make a developer really confused.

Are the patterns or DDD or something else the remedy for that? I am not sure.

First. You may think that applying quasi-remedies above reduces cost of introducing a newbie to the project. I disagree. A developer learns the technical meaning of the source code very quickly. Really big cost is acquiring in business domain.

However domain-agnostic developer writes poor code, but perfectly understanding how the domain works is not critical for one to understand what is technically going on in the code.

To be honest, I have met few software professionals who perfectly understand how the domain worked. Most of us knows just only enough (or little bit less) to make the feature working (at the moment).

Second. You may think that applying quasi-remedies increases code-readability what improves communication, what improves quality, what improves velocity, what improves business value. Well, this is true, but..

I observed when a project breaks all code-readability techniques and crazy naming conventions and macro-design techniques are used CONSEQUENTLY by a team, then some phenomenon happens. People align their perception to consequently used (even crazy) conventions and techniques. And then they are becoming productive developers. It takes time, but this is the fact.

So, my idea is the crucial thing for working effectively with software architecture is...keeping order inside the project, packages, folders, classes, methods and so forth. Order means: not so much code in one place, not so much dependencies between items and avoid cyclic dependencies if possible.

Do you know what I mean? No methodologies, no *Driven* approaches, no patterns maybe, just ordinary old-fashioned order.

When you focus yourself on listed approaches first, you may forget what they were invented for. Being focused on keeping order doesn't make you most modern developer, but you will know what will be going on in the project, what to do and how to keep the code simple and clear at the moment. And I think this knowledge is enough. At the moment, of course.

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