Project: Paazl, offers choice in shipment

JTeam is proud to announce the release of Paazl, one of the projects that we have been working on recently.

Paazl offers a solution to the growing demand for choice when it comes to shipping. The platform JTeam developed allows Paazl customers (mostly webshop owners) to offer a range of options in shipment to their customers in a very easy way. Basically distributors offer a number of shipping options, like the time of day to deliver and whether to deliver to the door or to a service center where you then can collect your shipment. Of course all of these options come at a price. But right now, almost no webshop offers the full flexibility in shipping that they could offer to their customer. This is where Paazl comes in…

Paazl allows webshop owners to easily offer the full service offering of one or more distributor to their customers. This is achieved by offering the Paazl platform as a service and providing a module for easy integration into any webshop. This allows customers of the webshop to choose the shipping option that best fits their needs.The integration into the checkout process is seamless and is very similar to integration of a payment module.

For more information about Paazl, visit their website.

From a JTeam perspective, Paazl was a very interesting project because this was our first in-house project for a customer where we applied full scale Scrum. This was different from previous Scrum projects, where we participated on-site in the customer’s development team. In those project, empowerment was a major part of our engagement, next to technical consultancy and participation in development. We introduced the teams to the best practices of XP at the technical, and Scrum at the organizational level. Scrum was an easy fit for these projects, since all stakeholders were close to the team (at most one door away) and highly motivated to improve their processes. With Paazl, the situation was different. Basically entrepreneurs on a fixed budget who wanted us to build a web application, based on a set of detailed wire frames they provided.

I sometimes get this question: why apply Scrum if the customer already knows precisely what he wants? In response I raise these three concerns:

1 – How can we be sure this is really the case, and what if it isn’t?
2 – How can we be sure we really understand what the customer wants?
3 – How can we provide the customer with the most value for his investment?

Previous projects have demonstrated that our Scrum approach really delivers on its promise to create high-quality software in small increments, so we decided to apply it to this project as well. But how do we get the customer to get involved with the team in the role of Product Owner? What’s the use of sitting with the team twice bi-weekly in planning and review meetings when all requirements have already been meticulously specified? From experience we know what they still have to find out: those initial requirements are merely a starting point. When faced with the application under construction, as it gains features, iteration after iteration, they will want to deviate from those original specs. Our process provides the flexibility to accommodate these deviations, but why should this be appealing to customers who think they know exactly what they want upfront?

So here’s what we did. We created a full product backlog based on the requirements, estimated all items in story points and based our offer on that. In response, they cut back on features in order to get the biggest bang for the buck and meet their budget. The resulting backlog defined the initial scope for our project. We now had a fixed scope and a fixed budget in terms of story points. We invited the customer to our bi-weekly sprint planning meetings, where they would sit with the team and go through the backlog for the upcoming sprint in detail. In the course of several sprints these meetings also helped for the team to get a deeper understanding of the customer’s business needs. And we had review meetings at the close of each sprint, where the team would show them the latest result, to be deployed on a preview environment where they could subsequently play around with it to their hearts content.

Sure enough, after one, two, three sprints they started to realize they were actually in the driver’s seat where they could steer development in new directions. As they came up with new features they wanted, we had to look around together for other features to simplify or drop altogether. The scope could be changed as long as the total number of story points remained the same. By sprint four their business model had changed slightly, priorities were adjusted accordingly, and development had no problems to keep up with the changes. After six two-week sprints the application was feature complete, production-ready, and remarkably different from those original requirements.

What went well? Next to creating high-quality software, our Scrum process also delivered on the promise of providing maximum business value for the customer’s investment. What can be improved? Next time we’ll give the customer a more thorough introduction to our Scrum process right at the outset of the project, so they’ll be able to take advantage of it from the start. What still puzzles us? How to sell an agile contract that is not fixed scope or fixed budget – see Alef’s posts on this blog, tagged as “agile”.

Finally, what technologies did we use? Spring – with annotations – for the application infrastructure. Hibernate JPA for persistence. JExcelApi to import orders and addresses from Excel sheets. Apache Commons-Net for sending preregistration records to distributors over FTP. iText to create the address labels with bar codes that go with the shipments. Spring WS to talk to various web services provided by the distributors. We designed a REST-like API for the webshops to communicate with Paazl, exchanging XML messages using HTTP POST and GET, and used Apache HTTP Client to implement a reference webshop implementation. Our web frontends are based on Spring@MVC, see Tom’s blog post about that, with JQuery for the scripting. And we use the Google Maps API to display the location of distributor service points.

Last but not least, we wrote a lot of testing code. For our unit tests we ditched EasyMock in favour of Mockito, which made the testcode simpler and easier to understand. We used MockFTPServer for integration tests of our FTP client code and Subethamail Wiser for integration testing of sending email. And we pioneered the use of factories for creating full-fledged domain objects for use in unittests. More on this in subsequent blog posts.