Month: November 2012

Back in the “good old days” I started looking into BPM, or more precisely the BPM notion. They way we intended to use it on that particular product was, to apply a universal way of modeling processes across department, teams and continents. Said in a different way, we wanted to make sure that everybody drew things in the same manner. Of course, this is pretty standard, however, our organization was not only a result of an acquisition, but also an organization that had a lot of sub contractors, both foreign and domestic.

The plan was a actually fairly simple; to train people in the use of BPMN 2.2 and upgrade their Visio installation and then basically make BPM diagrams a mandatory part of any specification, user story etc. True to form, these were never implemented, despite the fairly big investment in BPMN, and since nobody really had the time, mandate or ownership it seemed like the project fell between two chairs and died quietly.

Now the scene has changed, at least for me personally. In my new organization we are also working on implementing BMP, but in a much larger scale. Not only do we use the notion as a normal part of our every day work, we are actually going to implement the processes underneath, in order to manage our work flow. Pretty cool stuff actually. We are still pretty early in the process, but I am looking forward to getting my hands on Jdeveloper to see what we can actually do with this thing. Until that day comes, I have signed up with our good friends at Orbus to the stencils I need to get this show on the road. Hopefully I will get around to writing more about implementing BPM as our project progresses.

I have been in my new job for over a month now, and I a better grasp of the development methodologies. Obviously, I keep comparing the methods to how we did at my old job, since the differences are quite explicit. Whereas before I was submerged in a SCRUM world, I am now working in a team that applies a waterfall model for development.

In all honesty, the beginnings were a little difficult to getting used to. For many years I have been moving at break neck speed with a release every two to three weeks. On top of that there were the ever present bug fixes and panic solutions that characterize that particular organization. This is not meant as a negative critique of anything or anybody since I thoroughly enjoyed most of it. However, the stark contrast between the two methods does merit a comment.

The waterfall approach is without a doubt more cumbersome than the agile approach – that goes without saying. However, I am starting to appreciate the actual analytics that go before actual coding starts. Unlike before, it seems that there is time to identify problems and intricacies a priori as opposed to dealing with them a posteriori. I am pretty excited to see if this actually makes a difference when we start the coding, but I have high hopes that the development phase will be a lot more controlled than what we were able to do when I was apart of an agile team.

One could argue that the comparison in this is invalid, since the agile team made commercial software, and the waterfall team makes software for internal use, which basically changes the premises for the whole reason for developing a piece of software. However, I believe it is pretty valuable to experience both sides of the fence in order to ascertain which parts are useful, and which parts are not.