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.

Before we move on, let’s get the terminology right. Erik van Oosten rightfully commented we might have to start using the terms fixed-feature and fixed-term on top of fixed-price. To take it to a bit more general level, in a project there are three basic variables: a collection of features (or scope), the deadline (or schedule) and the budget (or resources). I’m specifically naming them scope, schedule and resources as these are the exact same terms Scott Ambler came up with in his article titled The Broken Iron Triangle Software Development Anti-Pattern. In his paper, Scott argues that ‘refusing the recognize the implications of the iron triangle’ is ‘one of management’s more popular approaches to hamstringing an IT project’. He goes on to say ‘we really need to question the ethics of “fixed-price” IT projects‘, which confirms what we’ve already settled upon.

The next thing he says (and this is completely obvious, if you’ve ever encountered an agile project done right) is you should be prepared to vary one (or even two) of the factors involved. Vary the scope, schedule or the resources that is, based on what you encounter during a project.

That’s nicely said and all, especially if you’ve won the client’s trust already, but what are you going to tell a customer that has a budget of say €100k for which you’ll quite likely implement something nice that suits his needs. The client puts out an RFP and invites three suppliers to answer to the RFP. You now it’s best for the client to end up in a situation where in cooperation with the client you can vary either scope, schedule or resources, but you have to win the client’s trust first.

I think the answer lies in the response to the RFP plus a certain amount of risk you’re willing to take as supplier to win this deal and this is where the list of contracts comes in that I got from Martijn Dashorst of Wicket fame. The list, by Alistair Cockburn provides various options for drafting a cooperation between the client and the supplier, varying from fixed-everything to fixed-nothing.

I’ll be digging through this list in the coming weeks to see if there’s anything usable. In the meantime, one thought I had was to be upfront with a potential client and offer him the various options for drafting an agreement (or at least, the ones we feel comfortable with). I’m not sure this will work in all scenarios. There are plenty of RFPs for example that require you to come with a response without being able to discuss possible directions with a client (how weird that may sound).

This is why I’ve been reading up on what others have to say about this subject. What I found was pretty interesting and I’d like to share my findings with you and also reflect a bit on these findings.

Are fixed-price contracts evil?

Generally speaking deals where for a fixed amount of money a project will be executed result in the client having no or little incentive to accept the project as being done or complete. After all, broadening or changing the scope of the project can be done at no cost, since the price has been fixed at the start of the project. The risk is entirely at the supplier side.

Naturally the supplier wants to minimize this risk, so usually demands or forces the customer to be very precise about the scope before the start of the project. In addition he asks for changes to be done using change requests, which subsequently are charged at a certain rate.

In his turn, the customer then puts as many feature in scope as possible, thinking that if he does so, the chances will increase that the features he really needs are among those in scope, hence not needing any change requests.

The end result:

• Way too many features initially in scope, many of which will be left unused in the end product
• Too much time and money spent on these features
• A situation where the customer is encouraged not change his mind too much
• A situation where the supplier is not encourage to think along with the client during the process as this again results in change

In other words: fixed price deals result in fix bid projects where both budget and scope are tightly controlled and change is kept to a minimum.

We’ve all concluded in the past that agility and flexibility during a project’s execution is something that’s desirable. Given this and the above, fixed price deals are not the way to go if you want agility and flexibility.

So, what is the answer then?!

So if we know that fixed price contracts are not the solution if projects that accommodate change are a desirable thing, what contractual agreement should be used? Well, this is a question not easily answered.

Seth Schubert states things very elegantly in his blog entry on {codesqueeze}:

It is very difficult to arrange a contractual agreement that accommodates change. At the end of the day, your client’s accounting department is going to want to know how much the project will cost, and when they can expect to receive working software.

A bit further on Seth states that

a client will tend to perceive a fixed bid contract as less risky. By controlling the scope and budget in a project, the client’s stake in the project are seemingly protected. The risk of project failure by defining scope to early is not altogether intuitive or obvious.

He talks about the exact risk that we identified above. The risk of implementing too many or useless features, the risk of the supplier not thinking along with the client to prevent him from running into pitfalls, et cetera.

Next, Seth states that:

Even when presented with this information, a new client may still may be unwilling to enter into an open ended contract.

This is what it comes down to: having no prior relationship with the supplier, customers often simply cannot relinquish control over either budget or scope right at the start of a new project. To some extent, I find this completely understandable; after all, how can a customer trust the supplier in his doing the right thing? It’s the first time he’s met the supplier.

Based on this, the question still remains: what contractual agreement makes it possible for the customer to let go of budget or scope in the long term?

There’s in fact plenty of research out there and examples of contractual agreements that facilitate this, some of which I might highlight later on. For now, we’ll first discuss some of the alternative at JTeam and see which ones are suitable for our practice. I’ll report some more of my findings later on.

In the meantime, if you have experiences in this area, you’re obviously more than welcome to share them here .

Well, being true Open Source Believers from the early days, JTeam is very pleased that the world out there is finally starting to adopt the Open Source Model. More and more companies understand  the value of Open Source technologies (for example iLocal) and are convinced enough to build their business on top of it. And as for now, even the Dutch Government is starting to change. Well that’s a positive thing.

It shouldn’t come as a surprise that JTeam was (and still is) involved in the decision. We empowered the Minestry of General Affairs  (Ministerie van Algemene Zaken) and its personnel for about a couple of months and helped them to setup a good development process as well as taught its employees everything they need to know in order to execute this project by themselves. This is also something that pleasantly surprises me.  Instead of outsourcing IT projects and lightling candles every day hoping that their development partners will successfully deliver, they’ve become more mature and decided to give a try themselves. Having this knowledge & experience in house will eventually result in better quality and less costs. Why? Because governmental projects are dynamic as well and also require an agile project management methodoly combined with XP development skills. It is questionable if outsourcing partners can deliver the same quality and communication skills as their internal department does. But let’s see how this project (and all related side projects) will eventually end.