Tag Archives: process

New Leaf at Jaspersoft

This week is my one year anniversary at Jaspersoft as User Experience Architect.

Appropriately, but coincidentally, this week we are beginning a new approach to integrating UX into the development process.

The New Leaf

This change in methodology is our response to a failed project: a visual redesign of Jasperserver, our flagship product. In this case ‘failure’ was a schedule issue: late in the cycle we realized that we would not meet our release target unless we pulled the redesign from the plan, and reverted it out of trunk.

There are probably 5 or 6 particular reasons why this project failed.  I think it would be useful to take these point by point in some future post. Today, however, I am more interested in how our experience is part of a more general issue: how do organizations combine user-centered design with the agile development methodology?

Faced with our recent failure in solving this integration we are making two fundamental changes:

  1. We are recognizing that not all projects are created equal. Many can be done in parallel but some must be sequenced before other development.
  2. Previously we managed all projects as in terms of requirements, design and production.  Going forward we are recognizing that we need to manage certain projects (see point 1) in terms requirements, design, user experience architecture, software architecture and production.

Recognizing the Special Projects

With respect to the first point, my initial guess as to what defines a project that must be done sequentially is one that creates a change in the object model of any software layer. A sexier and more compact formulation would be to say that architecture projects must be sequenced.

You might recognize such a project because it involves changing or upgrading a named framework.  Switching from a homemade set of Javascript utilities to jQuery is a good example. Upgrading to a newer version of Spring would be another.

Our ‘Visual Redesign’ project is another good example. At one level the architecture that was changing was purely visual: the visual logic of the pages, the color palette, the typography and the massing and organization of the white space. However, the true focus of the project was to change the markup structure in order to enable the new, beautiful and flexible visual design. This is the crucial point.  Once we agreed to change the markup, we were agreeing to change the DOM structure, and this meant invalidating many of the assumptions upon which the event handling scripting was based. This in turn made it impossible to move forward with almost any other work.

It’s the interface, stupid

The simple reason parallel development was blocked was that converting over to the new framework broke the UI.  We learned very quickly that a broken UI made it challenging to progress even on initiatives that were classified as infrastructure projects. The reason, obvious in retrospect, is that in the execution of essentially all projects the graphical user interface is the primary tool developers use to evaluate whether their changes are successfully meeting requirements. In addition, without a functioning UI, all QA testing, both manual and automated, ground to a halt.

As an initial mitigation we tried to maintain both the old and new UI environments simultaneously. Within two weeks of embarking on this program we realized that rather than reduce risk, the parallel approach dramatically increased it by literally doubling our development effort. Given that the business could not double our available schedule, maintaining two environments meant guaranteeing we would miss our target release date.

This all came to a head after a week in which the entire team worked long hours and yet we saw almost no meaningful progress on new features and zero reduction in our bug count.  At this point, even I, the primary cheerleader for the project, had to admit it was time to back out.

Three Heads Are More Rational Than Two

Following this painful but entirely rational decision (OK, maybe there was a little bit of yelling) we’ve begun looking at how we are going to get the Visual Redesign into our next release. As mentioned above, in addition to realizing a visual redesign is a special kind of project we have increased the body count at the planning table.  Whereas in round one we staffed the planning phase with just myself, the UX architect, and  a software architect, this time around we are including a third player: the technical manager.

Our thought is that this addition will produce two distinct benefits.  First, it means the cycles the software architect has available for this project will be devoted to the production of his most valuable contribution: a rock-solid interactive architecture.  This time he will not have to split his effort and allegiance between producing the best architecture and planning the steps involved in implementing it within the allotted schedule.

Second, including the technical manager from the beginning means that as soon as the frameworks begin to form, be they conceptual models or interactive frameworks, they will be critiqued by a third party who has no personal investment in the vision they represent, but is simply concerned with their tactical production implications. Our hope is that this practical critique will help trim the fat from the architectural visions without producing the compromise in ideals that occurs when talented individuals spar endlessly over the myriad important, but ultimately arbitrary, decisions that comprise a holistic and internally consistent vision.

That’s the theory, anyway.