Thursday, March 27, 2014

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

Monday, March 24, 2014

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.

Saturday, March 15, 2014

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.

Thursday, March 13, 2014

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.

Wednesday, March 5, 2014

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.
partresponsibilityout 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.