Although we at Redstream are developing software in an agile way for years we recently started to do it the Scrum way. We already knew the theory about Scrum but we really got excited when we attended to the ScrumMaster course lead by Jeff Sutherland himself.

And now, while we are a few sprints underway, I must say it really makes the job even more fun! We deliver what we said we would, with the quality we agreed upon and on time. In my opinion the biggest advantage of using Scrum is the avoidance of creating waste. I noticed that the team is building what is asked for and nothing more, whereas in the old days we would tend to build extra functionality we thought would be handy in the future. But, as we were told during the training, almost 2/3 of the functionality that is built in a system (not using Scrum of course) is rarely or never used, so this is a great way to improve the productivity.

I’ve been brainwashed for two days by Scrum Trainer Arlen Bankston and Scrum Practitioner and Agile coach Marco Mulder to get the Product Owner certificate. Don’t take me wrong, this was not a punishment but more an eye-opener for someone like me who has been working in IT for more than 25 years and only is familiar with traditional project management tools like PRINCE2.

I am used to put together a business case and defend this by heart to get the commitment and necessary funding from a project board to start a project. Scrum has another approach; “Just give me the money and we make this work”.

It is difficult for an organization to put money at stake with apparently no guarantee. But if you hold this method against the light, it could be combined with PRINCE2 in an easy way and you can share the benefits of both worlds; Agile and Control.

To make this successful, project managers should be able to be in less control and have confidence that their team can deal with the responsibilities. I consider myself to be “Agile” so this should not be a problem. But where do you introduce Scrum? In my opinion, the best way is in a project where people are developing software. There you can create a dedicated team that live by the rules of scrum.

However, what about other possibilities. Take for instance the start of a business club where you bring together all kinds of expertise within IT in order to be ready for battle and able to sell “Yes we can” to every question for a complete solution from your customers.

The basis for this business club is based on trust because there are general interests but also individual interests that should be taken into account. Scrum could be the answer to deal with this. Instead of working out every aspect regarding collaboration which will take ages, you could easily start small and have the minimum in place to begin.

So, when the user story, after an evening of discussion, with a minimum of requirements is defined and accepted it is time to plan your sprint and release the first version of the collaboration. In the meantime make sure that the backlog is filled with additional enhancements to make the next step.

Currently we’re evaluating the Mule Management Console: a new product from MuleSoft that replaces Mule HQ.
We have had a look at Mule HQ before and decided that it was not offering the functionality we were looking for. Apparently we weren’t the only ones with this conclusion because MuleSoft decided to build a new Management Console from scratch. It is now available as an Early Access release and MuleSoft asked us to evaluate it.

As soon as we have set up a test environment (similar to our live situation) and done our first tests we will post the results here so stay tuned!

XML is quite common nowadays, especially in the application integration business that I am involved in. However, I still see companies making big mistakes when they decide to start using XML (for example as the exchange format with their business partners). This series of posts is about mistakes (or at least clumsiness) in using XML that I noticed during several projects.

No use of versions in namespaces

In the previous post I already explained the usefulness of using namespaces in your XML schemas. The next improvement would be to make a version number be part of the namespace. Imagine if you don’t do that and you have to modify your schema. And with modifying I mean a serious change like adding a mandatory element to your schema. If you make this change then all systems and clients using your schema for their interaction will fail to do so as long as they haven’t changed their side of the interface. So actually you are forcing others to make modifications to their system. If I were a client of such a supplier I would definitely be unhappy with this kind of actions.
A nice way to avoid this situation is when you add a version number in the namespace of your schema. In that case you can create a new schema with a new namespace.
For example, the old situation:

xmlns:tns=”http://www.redstream.nl/message

becomes

xmlns:tns=”http://www.redstream.nl/message/v01_0

Now you can let the users of your schema decide when they are going to use the newer version. Of course you can provide a roadmap about when which version will become deprecated or even unusable.
This post concludes the series about using XML in real life projects. There are a lot more issues to discuss but I thought these were the most relevant to share. The final thing I want to mention is that you should use XML as meaning to get at your goal, it should not be the goal itself.

XML is quite common nowadays, especially in the application integration business that I am involved in. However, I still see companies making big mistakes when they decide to start using XML (for example as the exchange format with their business partners). This series of posts is about mistakes (or at least clumsiness) in using XML that I noticed during several projects.

Not making (useful) use of namespaces

As blogged before I had situations where I received XML files to describe the interface file without a schema (XSD). In this situation I did receive a schema, actually several schemas. Unfortunately, they forgot (?) to make use of XML namespaces. In each different XSD they added a description of the same xml type ‘OrderType’. You can imagine the rework you have if you have to change this ‘OrderType’; they have to modify all XSD’s and we had to regenerate all our JAXB objects. It would be much better if they supplied a separate XSD for the order element, gave it a namespace and import that in the other schemas. Another big advantage of using namespace is the possibility to distinct different versions of the same schema. I will clarify this issue in the next post.

XML is quite common nowadays, especially in the application integration business that I am involved in. However, I still see companies making big mistakes when they decide to start using XML (for example as the exchange format with their business partners). This series of posts is about mistakes (or at least clumsiness) in using XML that I noticed during several projects.

Only change the syntax of the CSV file (no normalization)

With this I mean that there has been existing interfaces based on character separated values like:

car-height|car-width|driver-name|driver-gender

And when they start to use XML they change it to:

1
2
3
4
5
6

<row>
  <car-height>xxx</car-height>
  <car-width>xxx</car-width>
  <driver-name>xxx</driver-name>
  <driver-gender>xxx</driver-gender>
</row>

More readable would be something like:

1
2
3
4
5
6
7
8
9
10

<row>
  <car>
    <height>xxx</height>
    <width>xxx</width>
  </car>
  <driver>
    <name>xxx</name>
    <gender>xxx</gender>
  </driver>
</row>

The fields concerning one entity are now grouped together, like you would do when normalize a relational database. This not only increases human readability but it also increases the chance to get to a reusable schema. With this latest example you can imagine that you can use the ‘car’ element also in another scheme.
So the tip of the day is: perform normalization in your XSD where possible.

XML is quite common nowadays, especially in the application integration business that I am involved in. However, I still see companies making big mistakes when they decide to start using XML (for example as the exchange format with their business partners). This post is about one of the mistakes I noticed during one of my projects.

Not using a schema (XSD) or DTD

In this situation I contacted a business partner to ask them how the XML file/message should look like if I want to communicate with them. The reply to the question was just an example XML file with the text: ‘it must look like this’. In this case there is no way to check if the XML is valid according to their specs and it is unknown if it can be processed by the other party.
Although they might check the xml very well when they process it, it would be much better if I could do some checking at our side. It would reduce the network traffic and increase the performance a lot. Also using Object-XML mapping tools like JAXB become difficult (or even impossible) which may working with the XML files harder in a Java environment.
The final issue I want to mention is that you can’t use XML mapping tools like Altova Mapforce. These tools really make your life easier if you have to transform one XML to another XML format. But they are based on XSD’s so without these you can’t create your XSLT for mapping purposes.
There might be a lot more disadvantages but I think the point is clear: when using XML files make sure you have an XSD for them.

As posted here I have been busy last few weeks studying for my upcoming exam to become Sun Certified Developer for Java Web Services. Well, the exam was today and I am happy to announce I made it :-). So I can finally remove this one from my wish list. Oh, and for the JAXR part of the exam I had 100% score… Would that be coincidence or because I had been playing around with JAXR and jUDDI???