BLOG:JUEL:ME

So, who knew? I got a new job, which means I will be leaving my employer through the last five years. Actually, it’s five years to the date.

For the most part, the last five years have been pretty good. I have had my share of big exciting projects, and I have been part of transforming a financial institution into a lean agile software machine. Well, we tried anyway.

Now that my last day looms ever closer, I find myself being oddly at ease yet reflective. I suppose that is a good thing though. It suggests that the previous five years meant something on some level.

Leaving the familiar and venturing out into something new can be a bit unnerving, but this time around I feel much better prepared compared to earlier. I guess with age comes experience. Be that as it may, switching jobs will provide me with the space to do some of the things I want to do outside of work, but it also keeps me receptible to change. As a Scrum master I think it is important seek out new input and inspiration. In other words: staying lean and hungry. Over the course of the last 12 months or so, I have felt more fat and lazy than I’d like, and that is all the reason I need to make a move.

I will continue to be a Scrum master, however, in a more scaled environment. I will also stay in finance, which I still find interesting.

Anyway, enough rambling, I have some packing to do.

I got Garmin Forerunner 630 for Christmas and this little bad boy actually supports Android notifications. Who knew how much fun you could have with a phone OS that is actually being actively developed. So anyway, when my Fitbit started coming apart I started using the Garmin full time just to try out the whole wearable thing for a little while.

So far it works pretty smoothly. The Bluetooth connection seems to be rock solid, and I get most of my notifications on the watch now.

However, I am not sure what to use these notifications for at the moment. Now it’s my watch that vibrates instead of my phone (not really, they both vibrate). I guess the benefit is that I can quickly see if it’s a notification I have to react to or not.

For now I don’t really see the point, but at the same time I am oddly interested in this, so I will keep the experiment going a little while longer.

I have pretty much stopped blogging, so there’s a bit of irony in this post. Be that as it may, the best blogging tool out there, Windows Live Write has now been open sourced. At the same time it has been renamed to Open Live Writer. Scott Hanselman has been one of the driving forces behind this initiative, so a big thanks to him.

Update: Here’s the link to the community and download page.

I am doing some analytical work on a side project these days. Currently, we are in the process of defining the scope of the system, so as the good analyst that I am, I have fired up Visio 2013. Now, I didn’t get the big flashy version of Visio, which means that I don’t have all the stencils I need. In another blog post I wrote about the BPMN 2.0 stencil, but this time around I have to use the UML stencil as I am working on use case diagrams and data models. Luckily the Internet is my best friend, and I managed to track down not only UML stencils but also crow’s feet.

You can grab the UML stencil here and the crow’s feet stencil here. If you are looking for BPMN 2.0 I recommend Orbus. Enjoy.

Computerworld has a pretty interesting article about the truisms of Hans-Joachim Popp. I am not sure how new these things are, but it is pretty refreshing to see a CIO making these statements. Here are the greatest hits:

1. Huge projects will fail
2. A rare and inexplicable error will come back – for sure
3. Spec will be finalized in the course of system development
4. Coding (the India part) is of less importance to the project success
5. Database applications will have performance problems
6. Professional project managers will make the project look on time until one day before release
7. The genius super team from the early prototype will fail during rollout.

Scott Hanselman is nothing short of a blogging god. Seriously, he is. Scott has a really good good post about the ultimate developer tools, which he updates around this time every year. Since I am not a developer, this list is of limited interest to me, at least in a work context. However, during Christmas dinner I started talking with my sister’s boyfriend about software development processes, he’s working on getting his start up off the ground, and I thought of the ultimate developer tools list. So, in stead of emailing a long list of links, I thought it might interesting to compile a list of tools for analysts and product owners. So without further ado, here’s my list of tools of the trade:

Rally: Rally is an online tool that allows a scrum team to manage their sprint backlog as well as their product backlog. As a product owner you simply create you’re a card for every feature you want in our product, and then the development team take these cards and add them to their sprint backlog. As far as I can tell, there’s no support for user stories, but you can always put these on your Sharepoint site.

JIRA: JIRA is Atlassian’s eqivalent to Rally. We used it in my previous work, and it worked very well. JIRA allows you to create Kanban cards as well, and has a pretty nice dashboard feature. As far as I remember, there are a couple of nice features for the project managers as well.

Confluence: Confluence is also made by our good friends at Atlassian, and I am a pretty big fan. It’s basically a wiki with limited blogging functionality. It’s really easy to use, and you can create teams wikis as well as a personal wiki, that also works a bit like a blog. I used both features quite a bit, but I think the blogging functionality could benefit from an update. Support for Windows Live Writer for instance.

Any emails over five paragraphs are in my opinion a blog post, and Confluence is so easy to use that it becomes an easy thing to incorporate in your daily work.

Blogging: If you are looking for more of a dedicated blogging platform, there are quite a few useful options out there. I prefer WordPress, but Community Server and to some extend Sharepoint offer workable alternatives.

Pencil project: For my mock up needs I currently use the open source tool Pencil project. It is a nifty little tool, which allows you create simple mock ups. It is not the most advanced piece of software, but it serves a basic need very well.

WebMatrix: For HTML editing I tend to use WebMatrix. Well, I used to. I don’t have the rights to install it on my current work PC, and to be honest it might be overkill too. However, I used to have copies of our front end HTML, which I would modify to reflect new UI requirements. Once you get to spend some time with it, it is a really fast way to create mock ups. The added benefit is that you can use the correct CSS in you design, thereby letting the developer know exactly how you want the front end to look.

I have tried to get into Microsoft Expression, which is now a free tool. As far as I can tell, it is a really useful tool, but to be honest, I find it pretty hard to learn. It might be me who is too dense, but I like my tools fairly light and very easy to use, and I am not sure Expression is just so. That being said, I fully plan on leaning it once I start my paternity leave.

As an analyst XML is the cornerstone of any project. Normally I use XML Spy, which is pretty much the standard app for working with XML. However, it’s a fairly expensive piece of software, and fortunately, there are alter alternatives.

XML Notepad is another little useful tool, however, I rarely use it for some reason. It’s probably because I use Notepad ++, which is really excellent, especially if you know how to work with regular expressions. When it comes to extracting data from large chumks of XML there’s nothing quite lik eit.

As wrote earlier, I have been participating in quite a few digitization projects. Usually, the basic premise for the projects has been to emulate a human based process in a digital manner. Or, we have tried to make the shoe fit the foot. One of the things I have noted, is how requirements seem to be incompatible with the how a system works. In my experience, human processes are very agile and easily adaptable to any problems that may arise. As human beings, we are able to improvise very quickly in order to finish a process that has gone awry. IT systems, on the other hand, are very stringent in the manner in which tasks are handled. They can only handle tasks in a given number of ways. This, of course, presents a problem in some cases, as we will not be able to support all human processes in the system.

My suggestion is to reverse the train of thought. Instead of adapting the human process to the system, maybe we should rethink the human process for starters. I am not suggesting that we ignore user requirements at all. I am suggesting that making changes to the human process may indeed yield increased benefit from the system support, since we will be much better equipped to support our users. Most human processes have been cultivated over several years anyway, and it might actually be beneficial to have another look at them, since technology has evolved so much over the years, and maybe able to better support the users in their daily work, if their processes are changed.

What I am looking for here, is an authentic digital process. Not an adapted one. A good example of this is the Windows Phone operating system. The designers did not look to recreate “real life” on a screen, but rather designed a new digital process, which then supports given human tasks. In my opinion, it makes for a much cleaner and more effective process, which hopefully will support human tasks as well as the other scenario.

For a couple of years now, I have been working on various digitization projects, both in the private sector and the public sector. A common characteristics has always been the pursuit of cost cutting, meaning that the basic premise for even starting the project was to lower cost associated with a given operation or process. Most of the times, a business case has been created in order to prove the actual benefit of said project.

These projects have always been ran as IT development projects, and always with a pretty tight deadline. In my experience, the deadline itself will at some point be the holy grail of the project for pretty much all the stakeholders. Anybody who has been part of a project like this knows that when the deadline approaches, we start to redefine the scope. In SCRUM we will prioritize which features we want first and which features are less important. More often than not, the result is a system that does not live up to the requirements of the business case. Or in other words, the system cannot yield the benefits that the business case assumes, thereby rendering the return on investment calculation invalid.

Now, don’t get me wrong. I am fully aware that there many reasons why we change scope. There’s a resource aspect – if we prolong the project the cost of manpower is going up, if we don’t start production on a given date, we miss savings opportunities etc. My point is just that by going through this exercise we violate the principles on which the project was started in the first place. The next question would then be, are we in a better position after we have released something to production than we were to begin with? We can really only hope so. I would stipulate that the business case is doomed to fail, any which way you look at it.

I suppose it would be possible to apply an equation here that would allow us to determine whether or not to proceed with a project, if the feature benefits are out scoped. Food for thought at any rate.

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.