Cross Platform Mobile Applications

Archive for May, 2009

Already Missing my Android

Today I am handing over my beloved phone to a colleague. I have had the pleasure of using an Android for some time now, and I must say that I am really happy and impressed by the usability and performance of this phone.

The Android G1

I have done testing and development on the Android to see how it will support mBricks applications. The Java based Android platform is a perfect match for mBricks. The idea is to keep all the business logic, message layer and most of the UI in mBricks, then use Android native API for the functionality that needs higher performance and integration towards the hardware, e.g. web browsing and maps. This will ensure a very cost efficient way of creating high performance applications for Android. My colleague will continue the work with Android and mBricks. I think its going to be a important platform for us.

The Blackberry Bold
My new phone is going to be a BlackBerry Bold, not a bad exchange I would say. I think that BlackBerry will get increased marked shares in Norway and with their strong focus and appeal for business users it fits mBricks perfect. I will start porting some of the mBricks applications to the Blackberry platform, I will keep you posted about how development for Blackberry proceeds.

Pål Berg, CTO mBricks

Agile Product Management - the way we do

A good friend of mine ask how to include bugfixes in the Scrum sprint, Scrum - the way I like to do it. We have also struggled with this at mBricks, the bugfixes always seems to take attention from the planned tasks since their priority is often valued higher. We have had a couple of strategies to avoid this at mBricks.

First we tried to put one person responsible for bugfixing according to their internal priority. This strategy gets the bugs done without interrupting the sprint, but it is not very including for the person that is responsible for bugfixing, and often also discussions with the rest of the team is needed, which in turn results in unwanted interruption of the sprint.

Then we tried a strategy with defining one sprint to be a bugfixing sprint, but we were not fully satisfied with that either. The bugfix sprint came to seldom for high priority bugs and also we lost progress in new development.

Now we are trying a new strategy, which is to include the bugfixes in the sprint. Actually we do not differ between a bug/issue and other development tasks. They are all priorities according to their value for the end users and of course weight against their required effort.

Our Product Management tools

There is a lot of different tools available for product management. The one that we re using now is JIRA, which is a system for issue tracking and release planning. It can be extended by a well of different plugins and addons. There is two important plugins that we use:

1. Subversion for source control reference
2. GreenHopper for scrum planning

It was important for us not to have to many different systems to maintain. Now everything is nicely integrated and build around the JIRA core.

GreenHopper

GreenHopper is a great tool that gives us the possibility to plan the new releases of mBricks divided into several smaller sprint releases. All the tasks are different issues in JIRA and the workflow is mapped to the Scrum process. The only missing functionality that I see is to flag an impediment for our stakeholders.

This is the planning board:

GreenHopper Planingboard

This is the burndown chart:

GreenHopper burndown chart

The issue mapping and workflow definition:

Issue mapping

Workflow mapping

As I started by saying; we now do not handle the bugs any different than the rest of the tasks in the Scrum. They are all the same in our system.

Pål Berg, CTO mBricks

mBricks © 2010. All rights reserved