An agile approach to defining your product vision!

‘What is your team working on?’

Of course, you’ve heard this question many times before and probably your answer will slightly differ from your teammates’. But, with the help of two agile team-building activities, you can eliminate such a difference and reach an alignment with your teammates on a description for your team and product. Those activities are ‘Collaborative Product Vision‘ and ‘Defining the Team Vision Statement.’

In this post, I will only be covering the product vision activity.

How to run the activity?

Here is the template of the product vision:

FOR (1. target customer)
WHO (2. statement of the need or opportunity)
THE (3. product name) IS A (4. product category)
THAT (5. key benefit, compelling reason to buy)
UNLIKE (6. primary competitive alternative)
OUR PRODUCT (7. statement of primary differentiation)

Here are the steps to simulate the activity:

  1. Write the statement on a board for all to see.
  2. Split your team into groups of two or three
  3. Give the groups 5-10 minutes to fill in the seven blanks
  4. Ask each group to present and explain (if needed) the vision they came up with
  5. For each blank, ask the team members to individually vote for their favorite replacement
  6. Replace each blank with the phrase of highest votes
  7. Read the new statement out loud
  8. With the team apply some changes if needed

The Benefits

I am writing this blog because I think this is a nice activity for any team! So far, I have played it with three different teams, existing and newly established ones.

Here are some benefits of playing this activity:

  1. Good activity for team bonding especially new ones
  2. Aligns all team members on one vision of the product they are building
  3. Aligns all team members on what is considered as in and out of scope of the product
  4. Helps teams in identifying their main competitors
  5. Highlights the major difference between the product and its competitors
  6. A short but meaningful description of the product for upper management, visitors, and newcomers

Example

FOR Outlook Users 
WHO want to keep track of time spent in meetings
THE MeetingReporter IS An outlook-addin
THAT generates time reports from the calendar 
UNLIKE existing tools where you have to manually insert time spent
OUR PRODUCT will parse the calendar and automatically generate different reports based on meeting category

Above is an example!

It is the vision of the tool I am writing on my free time! From this short statement and without any further explanation, anyone should understand purpose and major feature of this tool!

Finally

Some people consider such activities as a waste of time. Obviously, I disagree! This is an occasional activity that takes between 15 to 20 minutes depending on the team’s size. Thus, it is an excellent candidate for the first activity of the team’s retrospective!

I encourage teams to try it. For those who do, I am pretty sure you will be posting the outcome on your team’s home page, just as we did!

Resources:
  1. Fun Retrospectives
  2. Collaborative Product Vision
  3. Defining the Team Vision Statement

How to handle Java exceptions in clean code? – Part 2

In my previous post, I explained the different types of exceptions in Java and left two questions for this post!

Which exception to use?

Java documentation and Uncle Bob’s book (Clean Code) were my references when preparing this tutorial. I noticed a slight difference between what is recommended in each!

Java Documentation

While reading the Java documentation, you sense a preference for Checked Exceptions. The documentation states that the usage of UnChecked Exceptions should be restricted to the case where crashing the system is intentional if an exception occurs. In other cases where recovery is still possible, Checked Exceptions should be used.

Robert Martin’s opinion

Uncle Bob has a different opinion!  He argues that although Checked Exceptions might have some benefits and can be useful in some special cases like writing critical libraries, they are not a necessity to have a robust software.

Breaking the ‘Open/Closed Principle‘ and ‘Encapsulation‘ are the main two reasons that make using Checked Exceptions a bad idea!

Let’s see how!

In the below example, the MainBookReader.main method is calling the method MainBookReader.readJsonObject to get the book’s description from a JSON file. And since readJsonObject throws an exception we had to add throws FileNotFoundException clause to the signature of the main method and the interface JsonLoader!

import java.io.FileNotFoundException;

public class MainBookReader {
    public static void main(String[] args) throws FileNotFoundException {
        BookJsonLoader jsonLoader = new BookJsonLoader();
        Book bookFromJson = jsonLoader.readJsonObject("books.json");
        System.out.println(bookFromJson.name());
    }
}
import com.google.gson.Gson;
import java.io.FileNotFoundException;
import java.io.FileReader;

public class BookJsonLoader implements JsonLoader {
    public Book readJsonObject(String fileName) throws FileNotFoundException {
        FileReader jsonFile = new FileReader(fileName);
        Gson gson = new Gson();
        return transformToBook(gson.fromJson(jsonFile, JsonBook.class));
    }

    private Book transformToBook(JsonBook jsonBook) {
        return new Book(jsonBook.getName());
    }
}
import java.io.FileNotFoundException;

public interface JsonLoader {
    Book readJsonObject(String fileName) throws FileNotFoundException;
}

Adding the throws clause to most of our methods means two things!

  1. Our top methods & classes had to know a lot about the lower methods & classes!
  2. If any change is to be applied to the lower methods, this change has to be replicated to all above methods!

This is a violation of the ‘Open/Closed Principle‘ and ‘Encapsulation‘!

Is there a better way?

No matter how careful we are, things can still go wrong. Thus we still need to deal the exceptions when they occur! The alternative to the code above is writing clean code!

In this section, I will refactor the above code to make the code look better, although it might involve more code!

Wrap the Exception

The first step is to wrap the exception in one place! In our case, we can replace the throws clause with a try-catch!

In the catch clause, I’m throwing a JsonFileNotFoundException (UncheckedException) that I have created based on the needs of this system (i.e. providing an informative message to the user).

public class BookJsonLoader implements JsonLoader {
    public Book readJsonObject(String fileName){
        try {
            FileReader jsonFile = new FileReader(fileName);
            Gson gson = new Gson();
            return transformToBook(gson.fromJson(jsonFile, JsonBook.class));
        } catch (FileNotFoundException e) {
            throw new JsonFileNotFoundException("Can't find the file " + fileName + ". Please make sure it exists!", e);
        }
    }

    private Book transformToBook(JsonBook jsonBook) {
        return new Book(jsonBook.getName());
    }
}

The benefits of this refactoring are:

  • Remove all ‘throws clauses.’
  • Hide the logic and information of our class from the outer classes
  • Send an informative message to the user in case the file was not found
  • Minimize the dependency (remove imports from other classes)

Don’t return null

In some cases, developers don’t want to throw an UnCheckedException, so they tend to return a ‘null’ instead! That is a bad practice because it will eventually result in a NullPointerException later.

So, what to do? The answer is simple, return a SPECIAL CASE!

The below class ‘MissingBook‘ is our special case!

public class MissingBook extends Book {

    private MissingBook(String name) {
        super(name);
    }

    public static MissingBook aMissingBook() {
        return new MissingBook("MISSING BOOK");
    }
}

This allows us to return an instance of the MissingBook in the catch instead of throwing an exception!

public class BookJsonLoader implements JsonLoader {
    public Book readJsonObject(String fileName){
        try {
            FileReader jsonFile = new FileReader(fileName);
            Gson gson = new Gson();
            return transformToBook(gson.fromJson(jsonFile, JsonBook.class));
        } catch (FileNotFoundException e) {
            return MissingBook.aMissingBook();
        }
    }

    private Book transformToBook(JsonBook jsonBook) {
        return new Book(jsonBook.getName());
    }
}

Don’t pass null

In your code, you shouldn’t pass null as parameters and instead use the Special Cases as before. But, it gets harder to prevent your clients from passing nulls thus you might need to assert some function parameters before proceeding with your code execution!

Finally

Doing the refactoring for the simple example above might look like over-engineering! But, it becomes beneficial when writing more complex code!

I think that the excessive usage of CheckedExceptions will pollute the code and thus should be avoided! For me, the benefits of CheckedExceptions can still be achieved through:

  1. Following the rules of Clean Code
  2. Increase test coverage of the code by following the TDD practice! With the use of TDD, all the edge cases should be covered and thus eliminating the possibility of having unexpected exceptions during execution!

To understand better the importance and how to write clean code, it is highly recommended that you read the book Clean Code by Robert Martin!

References:

  1. Clean Code: A Handbook of Agile Software Craftsmanship
  2. Unchecked Exceptions — The Controversy
  3. Java Exceptions
  4. The Clean Code Blog

How to handle Java exceptions in clean code? – Part 1

Reading the chapter ‘Error Handling‘ from the book ‘Clean Code‘ made me think whether developers follow the clean code rules when writing production code. It also appeared to me that the difference between the Java exception types might not clear be for some!

The purpose of this short tutorial is to clarify those two points. And to make it clearer, I will be dividing it into two posts. In the first one, I will explain the different types of Java exceptions. Whereas in the second one, I will show how to write clean exception code!

Java Exceptions

In Java, the class Throwable is at the top of the class hierarchy of all exceptions. The classes Error and Exception directly extend Throwable. All the subclasses of Error and Exception are grouped into two types ‘Checked Exceptions‘ and ‘UnChecked Exceptions‘as displayed in the image below.

javaexceptiondiagram

What is the difference between Checked and UnChecked Exceptions?

UnChecked Exceptions

UnChecked Exceptions extend the classes ‘Error‘ or ‘RuntimeException‘. In this case, developers don’t have to worry about catching or handling the exceptions at compile time as the compiler won’t report any error. But, as they are not caught, those exceptions may result in complete failure of the application when thrown during execution.

Below are two examples of UnChecked Exceptions!

1. Runtime Exception

The below method simply divides two numbers:

private static int divide(int numerator, int denominator) {
    return numerator / denominator;
}

The code is fine and will compile with no errors! So what is the problem?

The problem might occur at runtime if we try to call the method while passing zero as the denominator. Since this exception is not caught, our system will crash throwing the below arithmetic exception:

Exception in thread "main" java.lang.ArithmeticException: / by zero
 at MainUnCheckedException.divide(MainUnCheckedException.java:7) ...
2. Error

The below method compiles, but since I missed writing the base cases calling the method will crash the system and throw a StackOverflowError (as shown below) will throw an Error!

private static int fibonacci(int number) {
    return fibonacci(number - 1) + fibonacci(number - 2);
}
Exception in thread "main" java.lang.StackOverflowError
 at MainUnCheckedException.fibonacci(MainUnCheckedException.java:10)...

Checked Exceptions

On the other hand, all other classes extending the ‘Exception‘ class are considered to be Checked Exceptions. In this case, the code will not compile if the developer doesn’t explicitly handle the exception.

This adds a level of security to your code, as you are forced to specify how your code should behave when an exception occurs and thus decreases the chance of having an unrecoverable failure in the system.

Let’s see an example!

public class MainCheckedException {
    public static void main(String[] args) {
        FileInputStream fileInputStream = new FileInputStream("foo.txt");
    }
}

Error:(6, 43) java: unreported exception java.io.FileNotFoundException;
must be caught or declared to be thrown

In the above code, we are trying to read a file ‘foo.txt’, but our compiler complains that we need to handle the FileNotFoundException.

Solving this compilation error can be done in two ways:

  1. Try Catch: The first solution requires surrounding the code with a try-catch.
    private static void readFileTryCatch() {
        try {
            FileInputStream fooFile = new FileInputStream("foo.txt");
        } catch (FileNotFoundException e) {
            System.out.println(e.getMessage());
        }
    }

    Even if the file was not there, this code would not break thanks to the try-catch. As shown in the below code and output, the system will print out the exception and continue execution!

    public static void main(String[] args) {
        readFileTryCatch();
        System.out.println("Done");
    }
    ------------Output------------
    foo.txt (No such file or directory)
    Done
  2. Throw an exception: The other solution is adding a ‘throws FileNotFoundException‘ to the method signature.
    private static void readFileThrow() throws FileNotFoundException {
        new FileInputStream("foo.txt");
    }

    Using this solution will propagate handling the exception to the calling methods as illustrated in the two options below:
    Option 1: Adding throws to all methods signatures 

    public static void main(String[] args) throws FileNotFoundException {
        readFileThrow();
        System.out.println("Done");
    }
    ------------Output------------
    Exception in thread "main" java.io.FileNotFoundException: foo.txt (No such file or directory)
    at java.io.FileInputStream.open0(Native Method) ...

    Option 2: Catching the exception in one of the methods in the call stack

    public static void main(String[] args)  {
        try {
            readFileThrow();
        } catch (FileNotFoundException e) {
            System.out.println(e.getMessage());
        }
        System.out.println("Done");
    }
    ------------Output------------
    foo.txt (No such file or directory)
    Done

 

I hope this post gave you a better understanding of Java exceptions! In the 2nd part, I will be sharing more details on how to properly write exceptions in clean code and which of the two exception types to use!

XP Days Benelux

On the 24th and the 25th of November, I was (with ten of my colleagues) in Heeze, Kapellerput in the Netherlands attending the two days conference ‘XP Days – Benelux‘!

The sessions at the conference were categorized as “Technology and Technique,” “Customer and Planning,” “Team and Individual” and “Process and Improvement.” And some of which were game based sessions!

In this blog, I will be sharing my feedback on two games I participated in!

LeanStartup board game

Led by: Sven Dill and Frederik Vannieuwenhuyse

The purpose of this game is to introduce participants to the practices and principles of Lean-Startup by simulating a business where each group has to produce a product and sell it to customers.

board

Game Rules

In the beginning, the game seemed a bit complex or vague, but things started to get clearer after the second iteration. Here are some of the game rules:

  • Split the participants into four teams (ideally three per team)
  • Each team is a functional company responsible for building a product
  • The board represents the market, where each is a customer requesting some features
  • At each turn, the team can distribute their resources on building features, investing in their company, experimenting or selling a feature
  • Through experimenting, the team can flip a tile to learn the requirements to sell the feature.
  • At each experiment, all the participants get the chance to learn new vocabulary from the lean-startup!
  • The team who reaches the red tile (in the middle of the board) first wins the game.

LeanStartup Vocabulary

During the session, we came across many lean-startup vocabularies, but here I will only be mentioning five of them!

  1. Pivot or Preserve: Certain challenges might force entrepreneurs to make a major change in their strategy. That change is called a Pivot!
  2. Idea Theft: Finding a compromise between the fear of idea theft (someone stealing your idea) and gaining knowledge is not an easy task. But, it is more important to gain knowledge than being afraid of spreading your idea!
  3. Concierge MVP: In some cases, you might need to create a fake processing MVP. That means what is happening in the background is not what it looks!
  4. Startup Machine: Put your idea to test by going to streets and asking people what they think about the product
  5. Startup Weekend: This is an activity where people of different backgrounds (dev, marketing, designers, etc.) meet to start building the first version

Take Aways

This game can be played by startups or even teams at large enterprises! And at the end, players should have got an idea of what Lean-Startup is. And more importantly, they will learn some of the factors that can play a role in any team’s failure or success such as competition, luck, technical excellence, failing and successful experiments, etc.

Agile Self-Assesment Game

Organized byBen Linders

As the name indicates, this game helps teams to assess how agile they are.

The game can be played by either an existing or a new team. In the case of an existing team, the results can be a base for a plan to change or improve their agile process. Whereas, for a new team this activity can be considered a futurespective activity as it defines the team’s first iteration.

Instructions

The game consists of 52 cards, where each card holds a sentence on applying an agile practice. To play the game you should follow the below instructions:

  1. Place the cards on the table
  2. Each member picks a card and reads it out loud
  3. The team discusses the card then place it under one of the following categories:
    • Not or inconsistently done

    • Consistently done, but value can be increased
    • Consistently done, valuable practice for the team
  4. After all the cards are visited, pick the ones under the 1st and 2nd category
  5. Have a discussion how to improve, change or remove those practices from your process
  6. If the cards to be discussed are too many, you can use voting to pick the most important ones for the team

AgileSelfAssesment.jpg

Cards

Below are statements taken from five cards:

  1. The team is empowered to make decisions
  2. The team is self-organized and doesn’t rely on management to set and meet its goals
  3. Software is tested and working at the end of each sprint/iteration
  4. All code changes are reversible, and it is possible to make a release at any time
  5. The team has a Definition of Done which defines their way of working and is used to check if a user story is ready

To know more about this game, you can check Ben’s blog on this session!

Until next time

I recommend those games to agile teams. Personally, I will be organizing two sessions with my team soon at Murex!

Finally, thanks to the organizers for setting up such an amazing and successful conference! See you next year! Probably as a speaker 😉

Extreme Practices – Agile Tour Beirut

In my previous post, I shared with you how Philippe and I prepared for our talk “Extreme Practices.” In this post, I will be briefing the talk’s content; starting with the pitch and ending with the feedback! Philippe has already posted a blog on the talk that you can read here.

Pitching

dsc_0444-1

Each of the speakers had to brief their session in a thirty seconds pitch. This was mine:

This is unusual for me, because my co-presenter is in Paris! Philippe and I will demonstrate how we adopted the practices of Extreme Programming in our distributed team. We will also have two live demos; the first on remote pair programming and the second on remote meetings.

The talk

The audience started taking their seats; and in a couple of minutes, the room was full! We started by engaging the audience with three simple questions!

Who goes to work by car?

Who goes to work by bus?

Who goes to work on Skype?

Extreme programming

After introducing ourselves, our team and Murex, we spent the first half of the talk discussing four of the XP practices and their benefits.

  1. Ten Minutes Build
    • Helps developers stay focused on what they are doing
    • Shorten the feedback loop
    • Encourages developers to submit frequently thus resulting in easier bug analysis
  2. TDD
    • Only coding what makes tests pass decreases the possibility of generating bugs
    • In most cases, a failing unit test is enough to detect where the bug is and thus reducing the need for debugging
    • The refactoring step drives to clean code
    • Finding difficulty writing a test is an indication that refactoring is required
  3. Pair Programming
    • Benefits:
      • Newcomers tend to learn faster and submit on their first day
      • The quality of our code has increased
      • We didn’t notice any negative any impact on productivity
      • It helped us build a bonded team
    • Difficulties
      • It is very tiring for both the driver and navigator
      • It is risky because some developers prefer to work alone
  4. Retrospectives: For this part, we explained the five stages of our retrospectives
    • Check-in/energizer
    • Throwback
    • Collect insights & discuss
    • Actions
    • ROTI

Extreme programming in remote mode

Our second half of the talk was dedicated to sharing how we are applying XP in a remote mode, mainly focusing on Pair-Programing and Retrospectives. The discussion included the difficulties we faced at the beginning and how we managed to solve them. We ended the discussion on both topics by a live demo!

  1. Remote Pair Programming
    • To overcome the problem of time difference between the two cities, the pairs tend to share their calendars as well as an online document with the detailed tasks required to finish the story
    • The navigator might easily lose focus; that is why we try to submit frequently and switch control as much as possible
    • It is more tiring than local pair-programming especially if you have the headset on all day long. We agreed that anyone is free to ask for a break at any time
  2. Remote Retrospectives
    • The whiteBoards were located in Paris, and thus it was hard for us in Beirut to effectively contribute to the meetings. We managed to solve this problem by replacing our the whiteboard with an online Trello boards.
    • Initially, our meetings were held over the phone lacking any visualization of the team on the other side which caused a lot of frustration. To overcome this problem, our IT team installed Visio Conference rooms in both cities!

Here is a short video of the PairProgramming demo we did!

Main message

You don’t have to move abroad for your dream job!“.

Remote work is becoming the trend! The advancement of the collaboration tools and technologies is making it easier for companies to adopt. In the future, you will see more and more developers working from home.

That was our message to the audience!  We concluded that there are three ways to organize your team when working remotely:

  1. Split the team in two if there are enough members in each city
  2. Work in open-source mode if team members are distributed over many cities
  3. Finally, adopt our remote XP practices if it is not possible to split the team in two

Feedback

Kudo.png

In addition to the above two Kudo cards, I received several positive verbal feedback at the end of the session. All that was a sign that our talk was successful!

Slides

Finally, you can have a look on our slides here:

 

Extreme Practices – The Preparation

Extreme Practices was the name of the talk Philippe and I gave at the AgileTour in Beirut on 15th of October, which based on the feedback was a successful one! Our main focus was on the practices of extreme programming and how to adopt them in a distributed team.

As this was my first talk, I decided to write two blog posts about it. In this first blog, I will be sharing the preparation whereas in the second post (in few days) I will be talking about the talk itself.

It all started with a discussion

Earlier this year, I attended a workshop organized by Pierre Hervouet who is also the organizer of AgileTourBeirut. After the session, we had a lengthy discussion on how we are applying Extreme Programming in our distributed team. We ended that conversation by agreeing that I give a talk at the AgileTour on that subject.

The next day I discussed with Philippe the possibility of him being my co-speaker. Unfortunately, visiting Beirut during that time wasn’t possible for Philippe! But later it struck us; why not giving the presentation in a remote mode (i.e. I will be in Beirut while he is in Paris) to simulate how we work on a daily basis.

That kicked off the preparation for the talk!

The content

After a couple of brainstorming sessions, we defined our presentation’s content and agreed that having live demos of remote pair programming and remote retrospective would make the talk more valuable!

Here is the content we agreed on:

  1. Introduction of ourselves and our team
  2. A short definition of XP
  3. A detailed explanation of some XP practices (below) and how we are applying them
    1. 10 minutes build
    2. TDD (Test Driven Development)
    3. Pair Programming
    4. Retrospectives
  4. A short story on how we started the distributed team
  5. Remote pair programming
    1. Explain how we are doing it
    2. Discuss the difficulties we faced and how we managed to solve them
    3. Do a live demo and solve parts of the FizzBuzz problem
  6. Remote retrospectives
    1. A couple of stories on how we initially started doing remote meetings
    2. Again, mention all the difficulties and the respective solution
    3. Do a live demo
  7. Final message
  8. Answer questions

The next step was building up the presentation slides and preparing the demos!

Slides design

We are both software developers. Thus we have limited design skills plus we usually are busy at work and can’t spend a lot of time on the design. That is why we requested the help of our Internal Communications team in the Paris office! The team focused on enhancing the slides’ background and images, but the content was not modified. After a couple of iterations with them, we ended up with very well designed and beautiful slides!

The below images show a sample of the difference!

Presentation coach

I usually give talks, presentations and even training sessions at work, but this was my first attempt to give a talk at a conference. Yes, I was a bit worried about it! Thus, we asked for training with a professional coach from our training department in Paris.

We had two sessions with the trainer. The first one was in Paris (i.e. we were both in the same room) whereas the second one simulated the real scenario of the talk (i.e. I was in Beirut and Philippe in Paris).

The coach’s focus was on:

  1. The talk’s timing, to make sure that we don’t pass our allocated time. That led to the removal of some slides that were less relevance to the main message.
  2. The content, to make sure our message is well received by the audience. This led to the rewriting of parts of our text.
  3. Our presentation skills, which included how I stand on the stage, eye contact with the audience and Philippe’s intervention during the talk.

I have to say that this training was essential to the success of our talk! Some of the key points I learned from this training were:

  1. It is ok to forget and thus don’t hesitate to look at the notes if needed
  2. Limit the notes to headlines instead of full text
  3. Try not to look at the big screen
  4. Keep eye contact with all the audience

A big risk

Let’s admit, doing a remote presentation especially with an unstable connection as we have in Beirut is a huge risk! But we were well prepared!

Again here, I asked for help. But this time it was from the IT department at AUB (the tour’s host). They were very helpful, as they granted me a dedicated link with (relatively) high-speed Internet and performed two rehearsals to make sure everything is working as expected. (I took the below image from the last rehearsal)

To avoid any surprises during the talk, Philippe and I decided to record the two demos ahead of time and just play them if needed. Below you can check the two recorded demos.

Pair-programming recording

Retrospective recording

 

The preparation for the talk took a lot of time and was tiring, but it was worth as everything paid off at the end!

Stay tuned; next post is coming soon!