Know more and connect with me on [Linkedin Profile].

Thursday, March 09, 2017

Personal Maps in a Kick of Meeting

I was in a KOM (Kick-off meeting) for a new Agile coaching project with some organization in Egypt. In my first day, first meeting, I planned a simple Agenda as following:

  • Know about the team
  • Know about the product
  • Know about the project
  • And build a list of problems and objectives for the project
So naturally, the first thing is to know about the team. I did not find anything better than exercising Jurgen Appelo Personal Maps. We were a small team and it was the first time to meet them. 

We were co-located, which gave us a better chance to make face to face conversations. I thought of using a white-board to have a big canvas for our personal maps, but the meeting room had no one. I asked one of the team members to bring a bunch of A3 printer papers and if he did not find any, to bring A3 papers. Almost no office does not have A4 printer papers, and sure he came back shortly with a bunch of papers. 

I started by describing the Personal Maps objectives and process. I worried that the team may find it a wasteful activity, but I continued per my plan.

I gave each team member one A4 blank paper and ran a timer for 3 minutes. All team members started drawing their personal maps. It was remarkable how much Mind Maps are popular and how fast they started being productive from the first minute.

After the timer expiration, everyone finished and we started to show each other our Personal Map paper. We agreed that no one will present his own map, and we will only answer questions related to it from other team members. We just shared the other's Mind-Map.

That was the first time I met with those members, and it was a very positive experience to know about each other as a human being. We found shared hobbies and shared experiences and sometimes remarkable things about individuals. The exercise succeeded not only as an introduction to each other but also as an ice breaker. Below is some of the maps done. It is not very fancy, but the discussions about them were.

Lessons Learned:
  • I plan next time to increase the time to 5 minutes, to have more time for bigger maps.
  • I will bring A3 papers to enable and encourage team members to write more details.
  • Let someone present others mind-maps fully and sure he will enable others to ask questions.
  • At the start, I will explain the importance of font clarity to make it easy for others to read it.
Here are some other mind-maps.

Tuesday, January 31, 2017

Organizing Application Classes into Packages

In Java language, we have encapsulation at many levels. First, is the class, as it may has private data
members and methods. It has the benefits of hiding complexity and provides a layer of abstraction.
Second is the package. It provides access rights to sibling classes inside it. Classes defined without being public are private to the same package classes and not exposed outside the package. So, packages in Java provide a means of encapsulation and details hiding inside it. There are also other means of encapsulation in Java, but I am not concerned about them in this post.

For more details about controlling access to class members for class, package, subclass and the world, see:

After this introduction, my question is, how can we organize project classes into packages? I am describing here two ways and comparing them. I will provide example product that is related to finance. I will assume both ways are using the same famous separation of concerns such as having separate layers for entities, data access repositories, business logic and web layer.

1) Organize Packages based on Layer:

  •        stores all data bases entity classes.
  • contains all data access classes.
  •    contains all business classes.
  •           stores all web layers that include controllers and rest classes.

2) Organize Packages based on business domain :

  •            includes all classes from all layers that are related to user.
  •      includes all classes from all layers that are related to account.
  • contains everything related to transaction.
  •         contains everything related to charts
Each package has separate classes for each layer. As example in account package we will have:

    • AccountEntity
    • AccountRepository
    • AccountService
    • AccountRest
    • Any other classes related to Account

In approach 1:

  • All applications folder/package structure will look the same as long as they use the same described architecture. There is no identity exposed in package names. 
  • The utilization of java package encapsulation is almost eliminated or ignored.
  • This thinking may be imposed by functional devision of code that match organizing your teams to Functional Teams rather than Cross-Functional Teams. 

In approach 2:

  • We utilized the package as a component concept, that you can have private classes to the package. 
  • You will have a unique identity for each application that matches its domain.
  • Each package can be easily separated into micro-service.
  • Encourage or at least consistent with cross-functional teams organizations.

Assume you want to change the transaction date to be transaction date and time. This change will required you to change all layers to accommodate this change.

In approach one: you have to navigate to 4 different packages to change them. I found this navigation tedious and distracting.
In approach two: all your changes are contained in one package only. Other packages will not be affected at all, except in case you will change a public class-method.

This is why I prefer approach two and see it consistent with Java package concept as well as Agile cross functional teams and micros-services.