To Scrum or Not To Scrum?

The company where I work we have always practiced a version of Scrum and tried to be as agile as possible, all being resource, time and money prohibiting. Everything I mention in this post I am or have been guilty of at some point. 

Friday I hosted a retrospective with the rest of the development team like we have many times before and tried to come up with some areas of improvement as well as bringing all issue to the forefront, plus a bit of venting from everyone. Some of the main points that had been raised are points below:

• Last minute requirements from the business forcing late code changes and rushed releases.
• Lacking of a product owner/area specialist who was willing to take responsibility for the product being released. 
• Scope to woolly and acceptance criteria being defined by development post implementation.
• A constant small stream of tasks which had been deemed maintenance tasks but had really been small features or tweaks to existing code bases of products.

After some debate and some insightful questions the conclusion all boiled down to development work starting to early. This isn't the first time and won’t be the last time that this conclusion will be drawn. Developers weren't strong enough to kick-back tasks at the business when no requirements had been gathered, and the scope so woolly it left it to the imagination of the developers. Time wasted in meetings post implementation trying to define A/C and testable characteristics, basically constantly chasing our tails trying to fill in the gaps we had previously missed out. 

To Scrum or Not To Scrum

This leads me on the next discussion we had: Why do we practice Scrum?  Do we actually practice Scrum anymore?  What alternatives are there? Ever since I joined the team we have been practising a form of Scrum within the development team and things worked well. Tasks would been defined early enough, 90% of the time we stuck to a standard fortnightly release cycle, most of the time we have Product Owners,  most of the time we have Stakeholders, a Scrum Master, try to release every sprint, the business would define the next sprints work and we would estimate and plan. All had been working well (with the minor hic-up) up until the last few months when development changed.

The business started making decisions faster, being more volatile and reactive, this could be due to the financial/industry pressures within the company and or a greater focus on pushing through new products and services which obviously will hopefully be paying my wages in the future. As the business had become more reactive and proactive in the current market climate the development team had not really thought about how the changes will affect the team and development process. We did not have the mind set to deal with the new changes especially the speed and or the volume. We still are thinking in a very iterative and almost waterfall model (it hurts to say it), letting each specialism within the team take responsibility for that function only, i.e. developers just being developers, testers just testing and leaving our business analyst to just be doing the analysis. This is ineffective and we all needed a little reality check!! WE ARE AGILE, we are proud to AGILE and yet we had failed with one of its most fundamental features. I don't think this had been done intentionally and I think this slip up is a recent problem and not one which had been causing major problems previously. So after much more discussion we came to the conclusion that Scrum isn’t really what we practice and if it is, it is being bent and squeezed to fit our current development cycles and current needs. 

I think one of the biggest problems had been the team struggling with the change and the constant rush of new feature requests which had been splitting the team up (and focus), each pair working on varying different tasks but yet the sprint still being classed and termed like it was a standard sprint.

We were not doing the project work originally planned out and the project work we had been doing was falling way behind due to features and changes which the business had been making at a much greater rate. Our team resource had been reduced and not only are we working on a single large several week project but also on many small tasks on different platforms, different projects and other smaller projects being thrown in a sprint half way through. We had not planned for this, our code base is all messed up, and releases had failed. Larger features being coded against the branch as the trunk is un-releasable due to the original large scale project we had estimated would take several releases. We had been doing project based work for some time now, focusing on larger scale projects defined from the business, incrementally pushing out new features with an overall common goal which had been loosely defined. New features/products were now being elbowed into this and simply placed under the same umbrella of our main goal, even though the goal posts had moved. Trying to please all and trying to be as agile as possible we had simply accepted these changes and not taken into account how it would affect the way we had been happily working for some time. Scrum and ourselves had failed to manage the current working conditions, the business at present did not really need a team who used Scrum, it was too ridged and we had been practicing a very fluid ad-hoc style and it doesn’t fit anymore. 

What’s next?

Kanban or Scrum-ban had been raised as a possible alternative to Scrum and is possibly a much better alternative way for us to manage the ever changing needs of the business. Scrum-ban sounds like it would be a great place to start, “Scrum-ban is especially suited for maintenance projects or (system) projects with frequent and unexpected user stories or programming errors. In such cases the time-limited sprints of the Scrum model are of no appreciable use” – wiki. Making the move from Scrum to pure Kanban may not have the same benefit and the change may be too great and too quick for the first step. Changing from Scrum to Scrum-ban hopefully will be beneficial to the development team and if all fails and we revert to the old pure Scrum methodologies then we only land back at where we are now. We need to ensure we retrospectively follow up each change. Making adjustments if required will hopefully mean the move will be a successful one.

As development we have work to do, improving communication and being more agile all around would make our reactivity much better and reducing the problems mentioned earlier. We had improvements to make in our source control management, having three streams not just a trunk and branch, but also a development branch which would improve flexibility of our code base and not render it redundant if features have been half finished or stories had been dropped from the sprint. Team functions need to be less isolated, developers can help out if testers are behind and testers can pair with developers on particular tasks to ensure test coverage is complete.

All in all I looking forward to practicing in a slightly alternative management style and it may just be the making of our team. I’ll report back on the changes made, how they fit in to our development team and the successfulness. Comments and feedback always welcome. 

James.

Groovy, Apache Batik and a little syntactical sugar speeds up Android development

As I read more and more of Android in Actionand further delve into the world of mobile development, one of the newer concepts I have come across is how to scale android applications to various different sizes of screen, hardware and resolutions.Google have good documentation in this subject area and have an entire section of the developer portal dedicated to this but this doesn't mean that trying to ad hear to them isn't a time consuming activity.

The problem I have been having is as I further try to improve the usability and functionality of my current Android applications in development, and try to follow the guidelines laid out by Google for simple things such as various different icon sizes depending on different screen resolutions, this process is eating all my time!

Table 1. Summary of finished icon dimensions for each of the three generalized screen densities, by icon type.

Icon Type	Standard Asset Sizes (in Pixels), for Generalized Screen Densities
	Low density screen (ldpi)	Medium density screen (mdpi)	High density screen (hdpi)
Launcher	36 x 36 px	48 x 48 px	72 x 72 px
Menu	36 x 36 px	48 x 48 px	72 x 72 px
Status Bar (Android 2.3 and later)	12w x 19h px (preferred, width may vary)	16w x 25h px (preferred, width may vary)	24w x 38h px (preferred, width may vary)
Status Bar (Android 2.2 and below)	19 x 19 px	25 x 25 px	38 x 38 px
Tab	24 x 24 px	32 x 32 px	48 x 48 px
Dialog	24 x 24 px	32 x 32 px	48 x 48 px
List View	24 x 24 px	32 x 32 px	48 x 48 px

I aim for all the icons I use to be in SVG format simply because they scale well and and can be easily converted to the desired format, PNG in this case. I use Gimp for windows to convert all the SVG files I have to the various different PNG's. This process is very manual and very time consuming which got me thinking......

After a little Google I stumbled across an Apache project for XML image manipulation called Batik. It seemed vast and very comprehensive but thought I'd give it ago.

I created a simple Groovy script which wraps Batik, exposing some Android orientated functionality cutting down the time to convert images from minutes to seconds, and when you start trying to convert larger numbers of SVG's to PNG in various sizes with the same name outputting them in different folders it can take hours.

I simply define various required image size groups which hides the mess and allows me to simply say I want this SVG converted to the required ANDROID_TAB dimensions.

Below is what I ended up with.

class SvgImageCreator {

 public static void main(String[] args) {
  new SvgImageCreator().convert(SizeGroups.ANDROID_DIALOG, [
   "menu_bug",
   "menu_clear_stats",
   "menu_credits",
   "menu_email",
   "menu_improvement",
   "menu_play_again",
   "menu_settings",
   "menu_manage_groups",
   "menu_add_group"
  ])
 }

 def convert(def sizes, def filesToConvert){
  filesToConvert.each{ file ->
   sizes.eachWithIndex { i, index ->
    println """Converting ${file} to W:${i[0]} H:${i[1]} for folder: ${SizeGroups.FOLDERS[index]}"""
    convertToPng(file, SizeGroups.FOLDERS[index], i[0], i[1])
   }
  }
 }

 def convertToPng(def name, def folder, def width, def height){
  final SVGConverter svgConverter = new SVGConverter();
  svgConverter.setSources(["images/svg/${name}.svg"]as String[]);
  svgConverter.setHeight(height);
  svgConverter.setWidth(width);
  svgConverter.setDst(new File("images/${folder}/${name}.png"));
  svgConverter.execute();
 }
}

At present it consists of a simple Groovy script with a runnable main method. With the aid of some Groovy syntactical sugar making this script easy to read and easy to extend if needs be. I created a static helper class containing definitions of all the various sizes and folder names. All it does is simple loop round the given SVG's and converts each one to the three different sizes specified and places these PNG's in various different folders depending on size. I imagine as a new app features get created and thus maybe further graphics are required you could simply add your new conversion definition and job done. 

After thinking about this over night, you could extend this to be quite intuitive, creating an eclipse plug-in which scans chosen folders outputting images of various sizes depending on file naming conventions. You could also have this as a standalone runnable jar which you booted up when you started development and performed the required actions after looking at a definition files in which would layout the conversions to and from. Obviously it doesn't do that at the moment and to be honest it has solved my problem saying me vast amounts of time as it stands so hopefully someone else may also benefit from it.

Please feel free to check out my GitHub where all the code is available: https://github.com/jamesemorgan/AndroidSvgToPngConverter. As ever comments are always welcome.

To get the project running simple clone the above project and add the missing dependency on Batik by downloading the source files from http://xmlgraphics.apache.org/batik/Groovy Eclipse plugin installed you should be fine.  

An example of the above images used in and Android menu can be seen below:

Reading Files inside a jar file correctly

Recently I've ran into some problems when trying to create a simple jar package containing multiply SQL files which in-turn would be ran against several databases. The application isn't complex, but simply a utility application which would be ran once a week/month against very large data sets in order to clean up data and fix known issues. The jar file would be invoked via a cron script and left to run over several hours on a weekend. I used the maven-assembly-plugin to build the jar file, simply specifying the main method to invoke.

First time I tried to deploy the program when it ran, all the files where trying to be loaded via a none relative path, i.e. trying to access files on the files system not inside the jar itself. After several different attempts at trying to read in files I found a simple solution using Google Guava.

Google guava has many helpful and functional utility libraries, commonly I use classes in:

• com.google.common.io  - Utility methods and classes for working with Java I/O, for example input streams, output streams, readers, writers, and files.
• com.google.common.collect - Generic collection interfaces and implementations, and other utilities for working with collection.
• com.google.common.base - Basic utility libraries and interfaces. 

The solution I found simple used a new class to me found inside com.google.common.io  called Resources. 

/**
 * @author James Edward Morgan
 */
public class ResourceFileLoader {

 /**
  * @param location
  * @return a {@link String} {@link List} of all lines in the file
  * @throws IOException
  * @throws URISyntaxException
  */
 public static List readLines(final String location) throws IOException, URISyntaxException {
  return Files.readLines(new File(Resources.getResource(location)
   .toURI()), Charsets.UTF_8);
 }

/**
  * @param location
  * @return The {@link File} Resource
  * @throws URISyntaxException
  */
 public static File readFile(final String location) throws URISyntaxException {
  return new File(Resources.getResource(location)
   .toURI());
 }

 /**
  * @param location
  * @return String the complete loaded file
  * @throws IOException
  * @throws URISyntaxException
  */
 public static String readAll(final String location) throws IOException, URISyntaxException {
  final StringBuilder builder = new StringBuilder();
  for (final String line : Files.readLines(new File(Resources.getResource(location)
   .toURI()), Charsets.UTF_8)) {
   builder.append(line);
  }
  return builder.toString();
 }
}

This utility class simply wraps the use of the Files and Resources class in side google.io to expose a few cleaner utility methods which will in turn be used to load any text files needed. The solution is neat and simple, and since the project already has a dependency on the Google guava the over head is minimal.

All in all, Google Guava contains a very useful set of utility classes which in my opinion should almost be as standard as using the Apache Commons libraries.

All source code, tests and the original class I created with many good/bad and ugly attempts as over coming this problem can be found on my Git Hub account @ https://github.com/jamesemorgan/SampleJarReading