On the Daily Scrum

Introduction
In a team environment, collaboration is essential for achieving the goals within a time-boxed iteration. Within the Scrum process, it is a subject to the Daily Scrum implementation to establish collaboration context within the team, and expose the benefits of the collaboration, so an appropriate implementation is necessary. Additionally, enforcing collaboration in Scrum is essential  in the absence of a command-and-control manager to enforce it, to justify the absence of the manager.
This blog post introduces a new tool named collaboration board and a proposed Daily Scrum implementation with corresponding question to fill the collaboration board.
The Daily Scrum
One of the few building blocks of  the Scrum framework is the Daily Scrum a.k.a. Stand-up, at which each team member answers the three questions:

• What have I done since yesterday?
• What am I planning to do today?
• Any impediments?

The participants need to understand what could the answers of these questions change. Who should use the answers, and what for? This explanation can be essential for establishing an attitude towards the process, and on the long term even influence the performance and work satisfaction of the participants.

The command-and-control project management style
Scrum is a set of simple rules of a framework that is an alternative to command-and-control management style. It is important to understand, that  the role of the command-and-control manager is to be compensated by an empowered team. In order to justify the team empowerment and the absence of the command-and-control manager, the team members has to make some effort. That is it: with the Scrum framework, if the team members are informative, cooperative, disciplined and contribute, the team as an entity does not need a command-and-control manager. The Daily Scrum  is supposed to target the informative and cooperative part on a daily basis, to serve as an information exchange activity and provide context for collaboration.
It is important to understand the Daily Scrum as an activity used to provide  information exchange and context for collaboration. However, at least in the company I work for, people tend to consider the daily Scrum as a scene, on which the participants report to a product owner.
What is the problem with reporting?
Let's see what follows if we take part in the Daily Standup with that reporting attitude (to report e.g. to the product owner). If the daily Stand-up is understood as reporting, people tend to put themselves in a defensive position, because to report is associated with being subordinate and managed. To inform does not necessarily impose a mood of being subordinate and managed. As result, with that feeling it is difficult to enjoy and maybe impossible to benefit from the Scrum process as well as contribute to improvements.
What needs to be done here is to use a different understanding of inform, to absorb that defensive facet that comes by the reporting association. In this sense, it would be appropriate to put the focus on the patterns used to implement the task, and on the benefits of collaboration within the team, that contributed for the task achievement. The benefits can be for example, concept validation / feedback, experience sharing, cut-down development time or leveraging creativity.

Proposed Daily Scrum Implementation
 So what do we do to assert that this attitude be changed in order to:

• expose the benefits of the team collaboration and have the participants develop positive attitude with the time towards the process (perhaps increase satisfaction);
• justify the absence of command-and-control manager for the information exchange and collaboration responsibilities;
  
• implementation the Daily Scrum in a way that does not suppress people;

Here is my proposal to address the bullet points above in the Daily Scrum.

"What have I done since yesterday?"
Time-boxed within 2 minutes. Take some time to prepare yourself, otherwise you will not fit into the 2 minutes.

• Give a short answer of the question in 2-3 short sentences using the header descriptions of the issues only.
• With whom did you collaborate? If someone gave you ideas and help, give this person a +1 on the collaboration board. Use at least the following dimensions for the reasons you gave a +1: ideas, workforce, feedback (add new or remove if appropriate). Here are some example outcomes from collaboration: results from code review, a success story, a big improvement, new pattern, the simplest solution etc. 
• Was it something big that you would like to share? Invite the team to a session where you have enough time to say what you want.
• Set a person to give you feedback from what you did, if you worked on the task/tasks alone.

"What am I planning to do today?"

Time-boxed within 1 minute. Say briefly what you will do, using the header descriptions of the issues.

• How do you estimate the task in terms of complexity?
• After the stand-up discuss the approach and/or outline the solution with a domain expert, if there is any. Find yourself a collaboration partner within the team.

"Any impediments?"

Extract the information that concerns the team. Prepare to be short and clear. Explain the details to your ScrumMaster in a 1:1. 

HL7 2.x DSL with auto-completion

Introduction 

Have you ever worked with a HL7 2.x [1]? Have you ever tried to extract information from a HL7 2.x message or even validate such a message against an IHE [2] profile with the HAPI library [3]? The purpose of the blog post is to announce that there is a Groovy [4] domain specific language (DSL) [5] that helps you work simpler with HL7 2.x messages. Most important, a Groovy DSL with auto-completion. To understand everything in this blog post, you need some basic knowledge about HL7 2.x and the HAPI library.

Why bother to create a HL7 2.x DSL with auto-completion?

HL7 is basically defined by a proprietary schema. The HAPI project has a legal permission to use this schema. What HAPI does is to generate Java classes, based on an abstract model for every version of HL7 2.x.
The need to extend HAPI has motivated the creation of such Groovy DSL, and why Groovy? Because in Groovy it is easy to create DSLs. However, there is something that has been somehow underestimated when it comes to DSLs - the IDE support. The IDE should be able help with both usage and verification of such DSL, and take away that burden from developers. Unfortunately not all IDEs support descriptors for Groovy, that are powerful enough to model such HL7 2.x DSL extensions. The good news: thanks to the Groovy Eclipse plugin version 2.5+ [6], the Eclipse IDE has this power [7].

How to get the HL7 2.x DSL?

The proposed HL7 2.x DSL is part of the Open eHealth IPF project [9]. If you use Maven 2, add the the HL7 DSL dependency in your pom.xml. Replace ${ipf-version} with 2.3-m2 or higher.

    org.openehealth.ipf.modules
    modules-hl7dsl
    ${ipf-version}

You will find the dependency in the Open eHealth Maven repository [8].
Next you have to add the dependencies with the generated HAPI structures you need. For example, if you work only with structures version 2.6, leave only the hapi-structures-v26 dependency.

    ca.uhn.hapi
    hapi-structures-v25
    1.0.1



    ca.uhn.hapi
    hapi-structures-v251
    1.0.1



    ca.uhn.hapi
    hapi-structures-v26
    1.0.1

What are the benefits of the HL7 2.x DSL? 

Before I show how to use the DSL,  I would like to list briefly its benefits:

•  Groups and Segments can be accessed by name like an object property. This brings readability and HL7-like syntax. For example message.MSH will access the MSH segment in a message. 
• Fields are accessed like an array field; components in a composite field are accessed like a multi-dimension array. For example: message.MSH[9][1] will return the message type
• The internal structure changes between HL7 versions. In higher versions, primitive fields are sometimes replaced with composite fields, having the so far used primitive as first component. Using the DSL you can access the fileds by name. If the field or group is non-repeatable, the first element is returned. For example, message.PATIENT_RESULT(0).PATIENT will equal message.PATIENT_RESULT.PATIENT
• Support for isEmpty() method for all adapted HAPI elements (ca.uhn.hl7v2.model.Segment, ca.uhn.hl7v2.model.Group and all kind of ca.uhn.hl7v2.model.Type, inclusive ca.uhn.hl7v2.model.Composite types).
• Support for getPath() method; Here is a quick example. For a ORU_R01 message:  msg.PATIENT_RESULT(1).PATIENT.PID.path will return "PATIENT_RESULT(1).PATIENT.PID" (1 means the second repetition of PATIENT_RESULT, works only with the access by name)
• Adding repettions, for example new MessageAdapter(new ORU_R01()).PATIENT_RESULT(0) will add a PATIENT_RESULT group to the empty message.
• Manipulating segments and fields, for example msg1.EVN.from(msg2.EVN) copies the EVN segment from msg2 to msg1

How does the auto-completion work?

Well, first you have to type in a Eclipse Groovy editor. The Groovy Eclipse plug-in's type-inferencing engine, with the help of a DSLD descriptor provided by the DSL library, does most of it. The DSLD descriptor publishes callbacks that are invoked when the Groovy abstract syntax tree is being modified. However, the implementation needs a hint - your adapter declaration must be parametrized with generics. That's it, the rest is done by the DSLD descriptor of the DSL library and the plug-in's inferencing engine. Imagine that you adapt a version 2.4 ORU_R01 message. Your adapter definition should be parametrized with generics like this:

import static org.openehealth.ipf.modules.hl7dsl.MessageAdapters.load
import org.openehealth.ipf.modules.hl7dsl.MessageAdapter
import ca.uhn.hl7v2.model.v24.message.ORU_R01
...

    MessageAdapter <ORU_R01> msg = load('msg-oru-r01.hl7');
...

Notice the generic argument ORU_R01. If you do not use the generic arg, you will not profit from the auto-completion.

Examples

Let's say you have declared the msg2 object as in the previous section:
MessageAdapter <ORU_R01> msg2 = load('msg-oru-r01.hl7'); When you hit ctrl + space after msg2. you will get the suggestions. The following two screen-shots show the access by name in action.

Auto-completion after access by name of the second repetition of PATIENT_RESULT group

DSL Documenation. Notice the currentType (SegmentAdapter in bold)

You also have suggestions for the adapter HAPI objects. It is valid to call the regular HAPI methods on those objects. You can use the suggested methods, however in this case the getPath() method will return an empty String object. As said before getPath() currently works only with access by name.

Notice the HAPI documentation on the left. Notice the getAt(Integer) method  - provided by the DSL as well.

What is currently not working?

• If you use the DSL for getAt(Integer)(a.k.a. the [] syntax) on a SegmentAdapter you get the wrong proposals for SegmentAdapter after the getAt(Integer). So do not use the auto-completion after the [] DSL. The returned type is TypeAdapter in this case. Example: if you hit ctrl + space after msg.MSH[1]. you will get the proposals for the SegmentAdapter. This will be fixed in the next versions of the Groovy Eclipse Plugin - there is already a task for it.
• Sometimes the auto-completion does not return the SegmentAdapter type. It returns Object instead. I hope that this will be fixed soon.

Conclusion
The Open eHealth IPF project has a HL7 2.x DSL module. The module comes with a DSLD descriptor that provides type inference information in Eclipse. The DSL in a combination with the auto-completion helps to navigate and access the HL7 elements easily. Many thanks to the Open eHealth IPF project team and the people who developed the Groovy Eclipse plugin.

References
[1] HL7 http://en.wikipedia.org/wiki/Health_Level_7
[2] IHE http://www.ihe.net/
[3] HAPI library http://hl7api.sourceforge.net/
[4] Groovy programming language http://groovy.codehaus.org/
[5] Domain Specific Language (DSL) http://www.martinfowler.com/bliki/DomainSpecificLanguage.html
[6] Groovy Eclipse plugin http://groovy.codehaus.org/Eclipse+Plugin
[7] Better DSL support in Groovy-Eclipse http://blog.springsource.com/2011/05/08/better-dsl-support-in-groovy-eclipse/
[8] Open eHealth Maven repository http://repo.openehealth.org/maven2/releases/
[9] Open eHealth IPF project Wiki http://repo.openehealth.org/confluence/display/ipf2/IPF+reference+-+multi

Is it possible to extend the Java DSL of Apache Camel in Java?

Introduction 

This post contains my experiments to extend the Apache Camel Java DSL, also referred to as route builder fluent API. I'll try to clarify what I mean by extend with an example. With Camel (version 2.6) you are able to create a route like this:

...
from("direct:start").to("direct:end")
...

By extend the fluent API, I mean being able to add a new elements  to the existing set of API elements, e.g. beep(). Some route that uses those new route elements might look like this:

...
from("direct:start").beep().to("direct:end")
...

In the route above, the beep()element is not part of the Camel DSL. To stay focused, I will neither discuss the extensions with Groovy, Scala or other JVM languages other than Java, nor the motivation for having DLS extensions in Java. 

Extend the DSL, but how?

My experiment was driven by the idea to extend the DSL using an N-tuple of custom (MyRouteBuilder,  MyRouteDefinition,  My1stProcessorDefinition,  ... , MyNthProcessorDefinition), that are subclases of RouteBuilder, RouteDefintiion and ProcessorDefinition. 
To use the extended DSL I would subclass MyRouteBuilder and write the route just as I would write it when I subclass Camel's RouteBuilder. As you would expect MyRouteBuilder creates MyRouteDefinition, that will create My1stProcessorDefinition ... MyNthProcessorDefinition where applicable.
In this definition the beep() extension suggested above would be part of the second element of the tuple, which is MyRouteDefinition. Once again, back to the N-tuple definition; it is neither scientific nor official definition. I introduce it solely, because I believe it clearly explains what I mean. I hope it is correct, please comment if you think I am wrong.

What is the problem?
I will try to explain what is currently problematic with the extensions. Here is how a route with a beep() extension might look like, using the proposed extension technique. First I define the MyRouteBuilder:

public abstract class MyRouteBuilder extends RouteBuilder {
  public MyRouteBuilder() {
    setRouteCollection(new MyRoutesCollection());
  }
  private class MyRoutesCollection extends RoutesDefinition {
    public MyRouteDefinition from (String uri){
      // Without the MyRouteDefinition return type
      // beep will not be recognized
      return (MyRouteDefinition)super.from(uri);
    }
    //Needed by the overriden from method 
    protected MyRouteDefinition createRoute() {
      MyRouteDefinition result = new MyRouteDefinition();
      ...
    }
  }
}

Next I can define MyRouteDefinition that adds the beep() method:

import org.apache.camel.RouteDefinition;
public class MyRouteDefinition extends RouteDefinition {
   /**
    * My extension method
    */
    public MyRouteDefinition beep(){
        //beep implementation here
        ...
        return this;
    }
}

Now the use of the beep() extension in the route:

public class MyRouteBuilderTest extends MyRouteBuilder{
  @Override
  public void configure() throws Exception {
      // This compiles and runs
      from("direct:start")
       .beep().to("mock:end");
       
      from("direct:start")
       .filter(header("soundAllowed").isEqualTo("true"))
       // This does not compile
       .beep().to("mock:end");
  }
} 

The first problem is the type cast in the from(String uri) method in MyRouteBuilder. It might seem negligible at first, but I have actually overriden only one of the DSL methods in RouteBuilder. Overiding all methods would lead to duplication and inconsistency on new Camel releases.

The second more obvious problem, is that MyRouteBuilderTest does not compile. It does not compile, because the filter(...) element returns FilterDefinition, and FilterDefinition does not have any information about the existence of the beep() extension, since it is not a subclass of MyRouteDefinition.

import org.apache.camel.RouteDefinition;
public class FilterDefinition extends ExpressionNode {
   /**
    * My extension method
    */
    public MyRouteDefinition beep(){
        //beep implementation here
        ...
        return this;
    }
}

This means, that I can use my new DSL extensions only direct after from().

Conclusion

The proposed extension mechanism strategy is not applicable in Java, because the new DSL elements are "lost" when standard Camel DSL elements, like filter(...) are used.  The latter limitation is a source of confusion that might put the acceptance of such a DSL extension approach in question. I am convinced that with some changes in camel-core, extensions of this nature are possible in Java.