Junit Tests should be used as a tool to assist in achieving low complexity. Only high code coverage never ensures a flexible maintainable code. I have explained all this in detail in “The Myths of Junit Code Coverage“. This will help you for sure.

However, Distributed Scrum definitely not as easy as plain Scrum is. It involves geographical, cultural and chronological issues. It has its own set of rules. To have a successful distributed Scrum team is not at all a piece of cake.

Things like TimeZone difference, Distributed Standups, Team configuration at different sites, Cultural Differences, Linguistic problems and many more bottlenecks continue to haunt the Distributed Scrum Teams.

Few months back, I could not find a place where specific problems regarding “Distributed Scrum” could be answered. Hence, I created a linked group “Distributed Scrum Practitioners” to discuss the problems faced in distributed scrum.

I invited few great minds of Agile to participate in the discussions. These people have been practicing Distributed Scrum for a long time. We have discussed lots of issues there. We got different viewpoint from different experts which helped us in finding problems for our Distributed Scrum Team.

Some of the Discussions were:

Is it necessary to have developers at all centers of scrum?

Things without which Distributed Scrum won’t work.

When to not have a distributed Scrum?

How to use Planning Poker cards in Distributed Scrum?

Retrospective : What went well? Do we do it the correct way?

Have you ever faced a scenario where the product owner is not the supreme authority. And you have multiple influential stakeholders…

Remote pairing success stories

The lamest possible implementation

and lot more.

If you also want to share your thoughts on Distributed Scrum, or to solve your problems in Distributed Scrum by advice from people who are really following from a long long time. Join and participate in “Distributed Scrum Practitioners“.

The artifact is uploaded at Central Maven Repository http://repo1.maven.org/maven2/com/xebia/. You can browse the artifact here.

maven-lucene-plugin creates a Lucene index from a file source. The structure of the lucene index i.e. fields, analyzers, indexLocation, fileSourceLocation, store etc can be configured in a configuration file lucene.xml.

lucene.xml contains all information regarding the lucene index and the data source (from which the index is created). The Maven Lucene Plugin looks for lucene.xml file in the project root directory (adjacent to pom.xml) and creates the lucene index from the file source mentioned in lucene.xml based on the index configuration provided.

Apache Lucene Version

The maven-lucene-plugin uses Lucene version 3.0.3. The index can be opened using Luke 1.0.1. Luke can be downloaded from here.

Configuring plugin in pom.xml

Configuring the maven-lucene-plugin in pom.xml is very simple. All information about index configuration needs to be written in lucene.xml. Index can be created by running “createIndex” goal in the plugin. It can be done by running the goal during any phase as shown in the example plugin configuration. OR it can be called by executing “createIndex” goal from command line by “mvn lucene:createIndex”.

The “createIndex” goal looks for a file “lucene.xml” in the project root directory (adjacent to pom.xml). The lucene.xml file needs to have all the information related to the configuration of index.

Example pom.xml is shown below:

<build>
 <plugins>
  <plugin>
    <groupId>com.xebia</groupId>
    <artifactId>maven-lucene-plugin</artifactId>
    <version>1.0</version>
    <executions>
     <execution>
      <phase>install</phase>
      <goals>
       <goal>createIndex</goal>
      </goals>
     </execution>
    </executions>
  </plugin>
 </plugins>
</build>

Example lucene.xml

maven-lucene-plugin looks for a file lucene.xml in the project root directory (adjacent to pom.xml). The maven-lucene-plugin will not work without lucene.xml. lucene.xml contains all the information about the lucene index.

Example lucene.xml is provided below and each tag is explained in detail after that:

<index>
  <indexLocation>C:\\index
  <sourceFileLocation>C:\\file\\data.txt
  <overWrite>true</overWrite>
  <separator>;</separator>
  <field>
    <name>names</name>
    <type>string</type>
    <analyzer>WhiteSpaceAnalyzer</analyzer>
    <store>true</store>
  </field>
  <field>
    <name>hobby</name>
    <type>string</type>
    <analyzer>SimpleAnalyzer</analyzer>
    <store>true</store>
  </field>
</index>

The parent tag is index. All other information is encapsulated inside it.

1. <indexLocation>C:\\index</indexLocation>

   indexLocation tag points to the directory on your disk where the index will be created after the goal:createIndex is executed.

2. <sourceFileLocation>C:\\file\\data.txt</sourceFileLocation>

   sourceFileLocation tag points to the file on your disk which will be indexed.

3. <overWrite>true</overWrite>

   overWrite tag specifies whether the existing index present at the indexLocation (if any) should be deleted or should be overWritten

4. <separator>;</separator>

   separator tag specifies the delimiter between the field names and the data to be indexed in it. The default separator is ; (Please refer to Sample File Source Format described in the next section for more detailed information).

5. <field>
    <name>names</name>
    <type>string</type>
    <analyzer>WhiteSpaceAnalyzer</analyzer>
    <store>true</store>
   </field>

A specifies a Lucene Field. can have one or many .

A <field> should contain the following tags :

Following analyzers are supported by maven-lucene-plugin in release 1.0. The default is the WhitespaceAnalyzer.

• “WhitespaceAnalyzer”
• “SimpleAnalyzer”
• “KeyWordAnalyzer”
• “StopAnalyzer”
• “StandardAnalyzer”

6. <store> specifies whether this field will be stored in the index or not.

Source File Format

This is an example of file source ( file containing data to be indexed). The data in the file source should be written in the format explained below.

• The top row represents the field names separated by the separator.
• The separator is the defined in lucene.xml.
• The default separator is “;”.
• The rows other than the top row contains values for the field.
• The field name should be same as that specified in the <field><name>fieldName</name></field> tag in lucene.xml.

The source file can be seen as a set of columns with the element at the top as the field name. Technically, each row other than the top row (name of fields) is considered as a lucene document.

For eg. in the example file data shown below, names and hobby are the field names.

Example File

names;hobby
albert einstein;invention and discovery
Leonardo da Vinci;Writing Painting

Maven Lucene Search

maven-lucene-search is a dependency which can be used to search lucene indexes without doing any Lucene specific coding.

It can be added by using dependency

<dependency>
 <groupId>com.xebia</groupId>
 <artifactId>maven-lucene-search</artifactId>
 <version>1.0</version>
</dependency>

It requires a lucene.xml file in src/main/resources. This lucene.xml file structure is same as described earlier for maven-lucene-plugin.

Including maven-lucene-search as a dependency provides a LuceneSearcher interface which has an implementation LuceneSearcherImpl. LuceneSearcher provides useful and simple methods to work on the Lucene Index created via the maven-lucene-plugin. It provides method to search on different fields and to delete different documents. The overhead of opening index reader and searcher and lucene specific stuff is taken care by the dependency.

The maven-lucene-search uses Lucene version 3.0.3.

Example Project

A example project which uses maven-lucene-plugin for indexing and maven-lucene-search dependency for searching can be found here.

The data.txt should have the following data:

names;hobby
albert einstein;invention and discovery
Leonardo da Vinci;Writing Painting

The project also contains a file SearchExample.java which demonstrates the use of LuceneSearcher availabe in maven-lucene-search by searching the index created by the plugin.

Development and Contribution

The Maven Lucene Plugin is created by Xebia India IT Architects Ltd. It is an open source project hosted at Sourceforge. The project url is http://sourceforge.net/projects/lucene-plugin/.

The source code of this project can be downloaded from SVN repository at SourceForge here. The SVN contains these projects

1) maven-lucene-plugin – Maven plugin to create index.
2) maven-lucene-search – Maven dependency to easily search on the index created by maven-lucene-plugin.

3) client – Example project which uses maven-lucene-plugin to create index and maven-lucene-search to search on the provided index.

New feature requests can be logged here and the bugs can be logged here. Support requests can be logged here.

If you are interested in contributing to this project, then please contact pranjan@xebia.com.

Future Releases

In future releases, following features will be included. If you want any specific feature, please log it here.

• The maven-lucene-plugin should be able to create index from different datasources ( filesource, database, web, xml ).
• Create annotations which can be used on fields of classes to index data.
• Populate db from a lucene index using indexToDataBase goal.
• Integrate luke in the maven-lucene-plugin. A maven goal will be created which opens luke initialized with the index locatioin provided in lucene.xml.
• Provide easy to use utility methods for querying and updating the lucene index through a interface in maven-lucene-search.
• Package the index as an artifact.

The plugin empowers you to use the strong capabilities of Apache Lucene with very limited or no knowledge of the technical internals of Lucene. The complete documentation about the usage of the maven lucene plugin can be found here.

The plugin is available at Central Maven Repository.

The Blog-Health-o-Meter™ reads Wow.

Crunchy numbers

The average container ship can carry about 4,500 containers. This blog was viewed about 16,000 times in 2010. If each view were a shipping container, your blog would have filled about 4 fully loaded ships.

In 2010, there were 18 new posts, growing the total archive of this blog to 20 posts. There were 7 pictures uploaded, taking up a total of 85kb.

The busiest day of the year was July 1st with 881 views. The most popular post that day was Pair Programming Issues.

Where did they come from?

The top referring sites in 2010 were dzone.com, blogsurfer.us, javablogs.com, zooie.wordpress.com, and linkedin.com.

Some visitors came searching, mostly for ternary search tree, scrum team size, random colors, jspider, and android random color.

Attractions in 2010

These are the posts and pages that got the most views in 2010.

Pair Programming Issues December 2009
4 comments

Apache Lucene – Indexing and Searching April 2010
3 comments

Architectural Terminology – An Introduction May 2010
7 comments

JBoss Drools 5 – Effective Usage May 2010
4 comments

Why Agile Does Not Work August 2010
11 comments and 1 Like on WordPress.com,

So, I thought that there must be something wrong in my interest towards meetings.

The irony was, I always attended other non project meetings with great enthusiasm and participation. So, I tried to capture the impulsive moments of boredom in meetings when I my interest drifts away from the subject.

One of the major points was beginning of discussion on topics which were not planned for the meeting. So, in this scenario, you expect one thing and the result is something else. So, if you are not prepared for what is being discussed, you will feel isolated and get into your own world.

Another meeting hunter is useless meetings. Sometimes, people meet for the sake of meeting, as a tradition. If the same job can be done via a simple email, there is no point wasting time of all the attendants. Everyone knows that this meeting is a just to follow some process, and no body will show interest in this.

If the meeting turns on into a debate, then not many will be able to sustain their interest in the meeting. Meetings should be crisp and clear. The speakers should make their points in a short and clear way. If everyone will provide every minute discussion about the point they are telling then meeting is not the place for it. The RAM that the brain has is limited. So, meeting is not the place to discuss the implementation of things to the minutest details. You need a presentation for this. Meeting is a place to take decisions on a high level. If you need to go into minute details, then the audience should be selected appropriately and they should be prepared before attending the meeting.

Other problem deals with the behavioral aspect of people. Some people are good listeners, some are so so listeners, and some are not at all a listener. Same goes for speaker, some never speak, some speak when its necessary, and some can’t stay quiet. What I have observed is that so so listeners and so so speakers are the best ones to work with. After meetings, neither your ear nor your mouth will be paining. This is where the behavioral aspect of agile fails. I will soon write in detail about the behavioral problems in Agile.

Some people have the tendency to speak in person even during the meeting, rather than addressing the whole audience. This not only makes him loose his context of meeting, but the person interrupted by him also looses the context of meeting. The meeting left is almost of no use after that. So, remember always talk to the group, not to any individual.

Finally, I have concluded, that meetings will continue to suck as its related to the behavioral aspect of people and you cannot change each and every person in world. The only meetings which I am sure will be successful, is a one with a logical moderator who commands authority and is willing to take the meeting to a conclusion rather than making it a debating amphitheatre.

However, I tried to follow his advice (guideline ), at least few times, but never found anything fruitful from it. Those days I was using Agile but not Extreme Programming. So, the tryst with TDD didn’t lasted long as I was never able to utilize it judiciously. The end result of following this practice was not coming clear to me.

Later, I changed my company. The new (present) company was a veteran in Agile and Extreme Programming methodologies/practices. So, I learned to pair program. Learned to re factor. Learned to not do the complete designing at once. Learned to do upfront designing.

Here the emphasis on junit test writing was enormous . So, I sharpened my skills on junit test writing and after a while, I was able to write junit tests pretty easily.

However, the path to excel in writing junit tests is not that easy. You need to travel a painful road of learning all the mocking frameworks and how to use it. And trust me, mocks suck. But, they can take you out of very difficult scenarios. Dependencies on databases, dependency on third party services and other stuff can be managed quiet well by mocks.

Other than mocks, you will also need to learn some workarounds for some complex scenarios which you will face while writing junit tests. I am talking about java techniques here. Like using some anonymous inner classes with behavior suiting the test. Reusing code in tests etc..

So, lets get back to my story.

Even after mastering the junit writing techniques ( which I got by pair programming with some veteran creatures ), I was not able to appreciate the idea of writing junit tests. It merely looked like a figure to satisfy the customer’s quality demands. So, basically, I was not doing TDD till now. Till now, I was doing DDT, which we named ( light humor intended ) as Development Driven Testing. This type of junit tests are written after writing the code which can be described in a plain and simple word “Useless”. This is simply of no use, don’t write it.

So, finally I was shown the magic of TDD when I paired with a pro TDD guy to develop of feature. Earlier, coding without a design in mind seemed hard to me. As I was not able to think of the minute component with getting the big picture. This was the place where I found TDD useful for the first time. The junit test acted like a client which wanted to use the method exposed. Doing development in TDD fashion, finally helped me think of components as needs of the client ( the user of the code being written , in terms of code).

What method needs to be written and what behavior it should attain were also governed by the junit tests. So, the only thing you should know before doing Test Driven Development is the business requirement. You write the requirement and then code for it.

So, these are the test cases which have some meaning attached to it. As some business value was thought of while writing them. So, if they don’t execute successfully, the code is not meeting up the requirements.

With time, I saw the comfort that TDD provides while coding. It takes out the burned of thinking about all the ifs and buts that you have about the execution of the code. As you are testing it as you write it.

The only other important thing that I would like to emphasize is the importance of pair programming in Test Driven Development. Until and unless you will pair with someone who is a master of TDD, you will not be able to appreciate its value. If you don’t have any skillful guy who can do TDD, pair with anyone and try to experiment with it, by just following the rules of TDD.

Execute it correctly and believe me, you will find a bliss named “Test Driven Development”.

I have seen agile adoption failures. And what I have learned from that experience is, that the problem was not Agile. The problem was the way, the processes through which they were adapting it.

The idea of writing this blog originated when I attended the Certified Scrum Master Training few days back. Apart from my colleagues, who are Agile specialists, and really young for this course, I didn’t find any veterans at all. Other than that, most of the people were quiet experienced PMP certified core project managers. These experienced people, who have been working in a completely different environment, following a king-slave sort of process with engineers had become too rigid with time to be mould in Agile.

This is something that I experienced in those two days. I observed that their thinking majorly revolved around these two points:

• How to utilize every second of a developer’s life.
• How to calculate performance and utilization of each individual.
• How to keep the customer happy at all costs

Even after two days of training and discussions on Agile methodologies, they kept talking about the necessity to calculate the utilization and productivity of each and every individual. It looked like, this was the only thing they cared about. I bet these people will need time (in span of years) to be Agile.

They were also too much concerned about the happiness of the client in every situation. The reality that I have experienced is, you can not keep the client happy on all fronts at the same time. You just need to tell the truth to the client. You tell them what is possible and what is not. And believe me, if you do it from the beginning, the client understands.

What was really disheartening, was that not even a single question was asked about how to create a blissful environment for the development and motivation of team. Agile, which focuses on people over processes, will get a kick in the butt by these guys. The Agile that these managers will follow, will create a situation like that of Hitler’s concentration camps in their teams.

I have seen this before. Let me tell you what will happen. These project managers will modify/customize Agile on their will and make it a tool to micro manage the team they are leading. The reformed Agile will be used as a selling technique to the customers. You might have heard of companies using their own form of Agile for development. These refined forms are customer centric and not team centric.

Few features of the refined/customized Agile could be:

• The burdown chart should always be a straight line.
• The estimates can be decreased, but don’t dare to increase them.
• The scrum meetings could be converted into a status update meeting.
• Work logs to be submitted, instead of updating scrum boards.

Now, why will this happen? Why am I so sure of all this? Am I a frustrated soul who likes to crib? Lets answer these.

Well, the basic thing is, a “team” is Agile, not an “individual”. So, to have a real Agile team, everyone in the team should be well equipped of Agile methodologies. Not only the Agile methodology, but also of how to tackle different scenarios in Agile. You simply can’t train the scrum master, send him back and ask him to train the team he will be leading in Agile. A newly trained, non experienced person in Agile will never have the capability to handle /answer all the scenarios/questions of a practical team. The team needs the same amount of Agile training from Agile veterans as the scrum master. Logically, everyone in the team should have the capability to become the scrum master.

Secondly, a newly trained person can hide the Agile techniques from the team which will cut off his powerful hands to manage them. This can specially be the case if the person has spent managing a non Agile team. These managers will never want to lose their power. This is what they eat of. They wont hit their jobs. The result will be, the suffering of the team.

Now lets look for some solutions. The simple and easy solution is, hire an Agile coach, let him train the team, the manager, the management, the product owner. Let him monitor the working of the team for few iterations. And once you feel you are doing really well, stop paying the Agile coach.

Hire self disciplined and self motivated individual. Agile does not support micro management of individuals. In fact, there are no managers at all. The Scrum Master is just a facilitator who ensures that there are no hurdles in team’s way. So, if you have got people who can utilize this independence of macro management, then just get rid of them. Not everyone can do Agile, always have self managed people in the team.

Finally, keep in mind that it’s not easy to change a person’s thinking and behavior. However, it’s not impossible. So, it will take time (might be in years) . So, be patient. The team will evolve to become Agile, and it will take time. The most important advice will be, try to be a better human being. Don’t think about promotion and money for a year. Think, care about the team. Agile cares a lot about behavior and processes. So, if you are a good human being, this only will create an awesome and blissful environment for your project’s execution.