The importance of a Product Owner

Companies using regular Project Management methods and willing to start using the Scrum Framework usually take a lot of care when hiring the Scrum Master (SM). Of course they need to hire someone that has lots of experience managing teams and that "achieved to multiply" n times the velocity of his last team.

But not all of these companies understand that the key artifact of Scrum is the Product Backlog, and the responsible of this artifact is not the Scrum Master but the Product Owner (PO).

Having a good SM and a great development team with a bad PO is equivalent of having a hamster engine powered Mustang.

As explained on the book Enterprise-Scale Agile Software Development "In an organization with established agile skills and Scrum-based projects, with experienced developers and strong Scrum masters, a bad product owner can turn an effective team into a frustrated and ineffective mess."

The success of the sprint depend on several factors (good understanding of the stories and good complexity estimations among others), and most of them depends of the quality of the backlog stories, this means on the work done by the PO.

Basically, the success of a product depends on the PO. Here you can see some examples of bad PO practices in the post "How to create products that customers hate."

A good product owner should:

Understand the product

"If you can't explain it simply, you don't understand it well enough."

Albert Einstein

This seems to be a stupid and obvious suggestion, but I can assure you that all the product owners have tough times trying to write a set of stories to describe a feature of a product. And the only PO that achieve this are the ones that really, really.... really have a clear idea of the feature to be developed and the "why to be developed".

Typically, a bad story is the one that the developers do not understand or the one that can't be estimated in complexity points in a couple of minutes by the dev team.

Never underestimate the power of prioritizing

Being negligent with prioritising the stories while using scrum is like being negligent with the steering wheel while driving a car. The PO is the one that will trace the path for obtaining a product by giving priorities to the stories in the backlog. Giving life to the backlog is updating the priorities and adding or changing stories day after day. This is adapting the requirements depending on the context of the current market.One of the advantages of scrum is the flexibility of changing your mind at any time, and this is possible by mantaining your backlog alive.

Learn to write a good backlog story

You can have some good tips here

Be present as much as you can

Sometimes when the team starts to go technical, some of the product owners have the feeling that they are no longer needed. For example when starting to define the tasks of each story. Keep in mind that the team can have a doubt about the story at any moment, in general the team will go back and forth from technical to usege requirements. And it's not the same to ask directly the PO during the meeting when the ideas are fresh, than seeing him later to solve doubts. Not having a strong presence of the PO can harm the team's velocity.

If you are interested on becoming an excelent PO, I suggest you the book  Agile Product Management with Scrum

How to solve the org.hibernate.LazyInitializationException

If you are building real world Spring-MVC /Hibernate applications you will probably have the honor to meet the org.hibernate.LazyInitializationException. I'm assuming that in the DAO's implementation you are using the HibernateTemplate and not the entityManager (and of course a sessionFactory instead of a entityManagerFactory).

The error you might have looks like this:

GRAVE: Servlet.service() for servlet [testDispatcher] in context with path [/secondtest] threw exception [Request processing failed; nested exception is org.hibernate.LazyInitializationException: failed to lazily initialize a collection of role: com.test.anotated.ArtData.colors, no session or session was closed] with root cause
org.hibernate.LazyInitializationException: failed to lazily initialize a collection of role: com.test.anotated.ArtData.colors, no session or session was closed
 at org.hibernate.collection.AbstractPersistentCollection.throwLazyInitializationException(AbstractPersistentCollection.java:383)
 at org.hibernate.collection.AbstractPersistentCollection.throwLazyInitializationExceptionIfNotConnected(AbstractPersistentCollection.java:375)
 at org.hibernate.collection.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:368)
 at org.hibernate.collection.AbstractPersistentCollection.read(AbstractPersistentCollection.java:111)
 at org.hibernate.collection.PersistentBag.iterator(PersistentBag.java:272)
 at com.test.controller.GetArtController.helloWorld(GetArtController.java:38)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

I have found a good explanation of the why on a webpage: 

"This error means that you’re trying to access a lazily-loaded property or collection, but the hibernate session is closed or not available . Lazy loading in Hibernate means that the object will not be populated (via a database query) until the property/collection is accessed in code. Hibernate accomplishes this by creating a dynamic proxy object that will hit the database only when you first use the object. In order for this to work, your object must be attached to an open Hibernate session throughout it’s lifecycle."

That is pretty nice! :)

The solution I've found in many web pages and forums is to force Hibernate  to perform an Eager fetching by using  fetch = FetchType.EAGER on the collection of the entity class. Once again, if you are building real world applications this kind of quickfix will not work.

For example, if your entity has one collection of objects (let's say a List<MyObject>), and each one of this objects has more than one collection of objects (let's say 2 or 3  List<String>); writing  fetch = FetchType.EAGER next to each collection  will probably  carry you to have the  javax.persistence.PersistenceException: org.hibernate.HibernateException: cannot simultaneously fetch multiple bags.  Now,  instead of  trying to fix our brand new bug, lets try to fix our configuration to avoid having the first LazyInitializationException in a clean way.

How to avoid the LazyInitializationException:

All you need is to mantain the session of your sessionFactory open while the processing the request. This is possible by adding an OpenSessionInViewFilter filter in your web.xml that will bind the session to the thread of the entire processing of the request.

Here is an example of an web.xml file, we are defining the filter on lines 17-20 and doing the mapping it to all the URLs of the application on lines 22-25.

<web-app id="WebApp_ID" version="2.4"
 xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee 
 http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">

 <display-name>Spring Web MVC Application</display-name>
 
<!-- Listener to create the Spring Container shared by all Servlets and Filters -->
    <context-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>classpath*:META-INF/spring/spring-master.xml</param-value>
    </context-param>

    <listener>
        <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
    </listener> 
  <filter>
        <filter-name>OpenSessionInViewFilter</filter-name>
        <filter-class>org.springframework.orm.hibernate3.support.OpenSessionInViewFilter</filter-class>
    </filter>

    <filter-mapping>
        <filter-name>OpenSessionInViewFilter</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>
 
 <servlet>
  <servlet-name>testDispatcher</servlet-name>
  <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
  <init-param>
            <param-name>contextConfigLocation</param-name>
            <param-value>/WEB-INF/mvc-dispatcher-servlet.xml</param-value>
        </init-param>
  <load-on-startup>1</load-on-startup>
 </servlet>

 <servlet-mapping>
  <servlet-name>testDispatcher</servlet-name>
  <url-pattern>*.htm</url-pattern>
 </servlet-mapping>

</web-app>

By doing this, the filter will mantain the session opened (during the request handling) and allow the Lazy fetching.

Try this sample project:

I did this little sample spring-mvc / hibernate project (using eclipse)  if you want to see the complete configuration and test its execution.

You can download the project and all needed jars (14.3 M)
hibernate-sample.zip

or just the project with an empty \war\WEB-INF\lib directory (23 K)
hibernate-sample2.zip

To run this example you must have already a database installed and tomcat configured:

1. Unzip the file with the project
2. Import it to eclipse
3. Edit the src/META-INF/spring/spring-datasource.xml to match your database (I have used Postgresql in this example)
4. Run it whith Run on Server (if the option Run on Server don't appear read the next steps)
5. enjoy :)

If Run on server option don't appear

1. Rightclic on the project
2. Choose properties
3. Choose Project Facets
   
4. Select "Dynamic Web Module" and Java and then clic on "Further Configuration" available.
   
5. Set the "Content directory" as war and don't check the generate.xml option
6. click OK
7. Done!

Now if the project is running you can go to the URL http://localhost:8080/hibernate-sample/ and see this.