Kanban Series: Introduction

At my place of work we have been using a Kanban system in place of sprints for just over a year now to great effect.

I firmly believe as a direct result of moving to Kanban we are delivering a higher quality, more stable and just all round better product to our users.  We have pretty much eliminated the need for overtime and have a better work life balance.

I've also came to the conclusion that if you're looking to take the plunge in to agile project management practices then Kanban is a great place to start.  Also if you're struggling with your current process and have difficulty getting buy in, Kanban is worth a look.

I plan to write a series of post about why we stopped doing sprints, how we got started with Kanban, what benefits it's brought us and what's lacking.

The first post will be about why sprints were not working for us and the need to look for something different.

(Note that I said "something different" as I don't really have much against sprints it's just that they didn't work for us so we had change it.)

Resources worth reading

The book for Kanban in Software projects -
Kanban: Successful Evolutionary Change for Your Technology Business

Kanban and Scrum: Making the most of both

Pawel Brodzinski on Software Project Management

Questions tagged Kanban on Project Management Stack Exchange

Down Time! Don't Panic!

In my company we've moved away from Scrum style Sprints in favor of  a Kanban system and a continuous flow of work.

One thing that seems to happen with the introduction of Kanban is people encounter a lot more slack or dowtime due to being blocked.  One of the reasons it happens more often is due to the limiting of work in progress that a Kanban system brings.  When this starts to happen people immediately see it as bad thing and a sort of panic sets in.  "I've got nothing to do, help!" or "I need to to busy all the time".  This usually leads to people breaking work in progress limits or trying to "cheat" the system by starting to work on an item when its not ready or is still being worked on upstream.

One of challenges of adopting a Kanban system is to try and get people to to relax when this happens and to look at how we can use this time.  Aside from the obvious task of looking at the rest of the board to see if you can help out somewhere else, there are other things we can be doing.

I've seen this summed up in a few nice ways:

"Too busy chopping wood to sharpen the axe."
or more bluntly (yep)
"How can we make things better if we never have time to do it."

If you're adopting a Kanban system (or any other way of working for that matter) I think its safe to say your doing it because you want to improve how you work and there are probably lots of areas you want to improve outside of your new Kanban board.  These periods of slack are great opportunity to work on these areas.

• Improve your build process.
• Set up a continuous integration server.
• Write some unit tests for that area of code that keeps causing problems.
• Refactor code.
• Review some of your collegues code or look at bringing in code reviews.
• Clear that junk out of the office that you've been meaning to move for a while now.
• Tidy up the product backlog.
• Look in to some new tools and methodologies.

The list can go on and on.

So next time you find yourself blocked by Kanban work in progress limits, don't panic!  I'm sure there's plenty you could be doing!

Here are some more links on this subject if you are interested (or find yourself with some slack!)

A Myth of 100% Utilization
Slack and a Managers Role is Scrum

Setting up Automated Builds with TeamCity, MonoTouch and TestFlight

We have recently entered the world of iOS development with MonoTouch and one of the first things I wanted to do was get a build process and Continuous Integration (CI) server up and running.

We already had CI setup for our existing Windows product which is integral to our development process so it was one of the first things we wanted to get working.

I might write a more complete post of our build process another time but for the moment here are the details on how I set it up.

I'm going to assume you have some knowledge of TeamCity, although even if you don't have any  its pretty easy to use and worth learning.  I'm also if you use another build server it should be easy enough to apply the information here to it.

Tools used

• TeamCity.  We had an existing TeamCity server running on Windows that we wanted to reuse.
• Mac Mini. A "clean" non-development one to be used as a TeamCity build agent for the existing TeamCity server.
• MonoTouch and MonoDevelop. Lots of reasons why we choose the Mono tools. I'll maybe write a full blog post on that another time.
• TestFlight for automatic distribution of builds to beta testers

Setting up the Mac as a Build Agent.

First thing you need to do is set up your Mac as  TeamCity build agent.  There is a guide in the TeamCity documentation for how to do this here.  My basic steps where:

• On the Mac install the agent from the on the Agents section of TeamCity using the Java Web Start installer.
• Accept all the defaults during the install.
• Follow this section of the TeamCity guide on how to start the build agent at Mac start up.

Note I couldn't get the last step to work by copying to the Launch Daemons folder as there was an error in some Java wrapper.  I copied the file to the /Library/LaunchAgents folder instead.  The downside to this is the agent will not start until the user logs in.  Although the Apple code signing stuff needs a user to be logged in anyway, so no big deal.

Once you TeamyCity server can see the new build agent authorise it via the web interface as normal.

Setting up the build process

The build process I initially set up consisted of 3 steps (excluding getting source from the VCS):

1. Update the App Bundle version
2. Build a class library project and a MonoTouch App project
3. Upload the App Bundle to TestFlight

Update the App Bundle version

The version number of your app is stored in the info.plist file of your MonoTouch project.  I couldn't find a way to auto increment this in MonoDevelop so I had to move to an external tool.  I prefer this approach as I don't need to complicate my build process by checking in the latest version number once its been bumped up.  I let TeamCity track the next version number with its built in functionality.

The Apple Development tools comes with a handy little utility called PlistBuddy.  If you run the following command line it will update you App Bundle version.

/usr/libexec/PlistBuddy -c "Set :CFBundleVersion %build.number%" Info.plist

In TeamCity I added a Command Line build step with that command.

Update build number step

You can use TeamCity's auto increment version number functionality to increase the version number each time.

Build the Projects

Next step was to build the class library and MonoTouch App projects.

For this I used the mdtool command line utility which comes with MonoDevelop.  mdtool only lets you build one project at a time so you need to invoke it once for each project.  Luckily TeamCity will let us do this in the one command line build step by changing the type to script.

My script looked like this (I've split it over multiple lines to make it easier to read, in practice you would need to remove the line breaks):


/Applications/MonoDevelop.app/Contents/MacOS/mdtool build 
  "--project:YourProjectOne"
  "--configuration:%AppBuildType%" 
  "%teamcity.build.checkoutDir%/YourSolution.sln"

/Applications/MonoDevelop.app/Contents/MacOS/mdtool build 
  "--project:YourProjectTwo" 
  "--configuration:%AppBuildType" 
  "%teamcity.build.checkoutDir%/YourSolution.sln"

Upload the builds to TestFlight

For this you need to do an Ad-Hoc distribution build.  This in itself could fill a few blog posts.

These are the guides I followed:

MonoTouch Ad Hoc Distribution Tutorial

Building for Distribution

Its worth getting these working and testing them out in MonoDevelop first before moving to TeamCity.  MonoDevelop has an upload to TestFlight command built in so you can make sure you are setup correctly before automating.

TestFlight (once you have signed up) has an easy to use upload API.  You can upload your build to it by using the built in curl utility. Its also an idea to zip up you .dSYM file and upload it at the same time to get better crash reports.

Again I added another Command Line build step and changed the run option to "Custom Script".  My script zips up the dSYM file and them uploads the App to TestFlight (again I've split it over multiple lines):


zip -r -b . MyApp.app.dSYM.zip MyApp.app.dSYM

curl https://testflightapp.com/api/builds.json  
  -F file=@MyApp.ipa  
  -F dsym=@MyApp.app.dSYM.zip 
  -F api_token=MyAPIToken 
  -F team_token=MyTeamToken 
  -F notes='Built from TeamCity. %env.TEAMCITY_BUILDCONF_NAME%' 
  -F notify=True  
  -F distribution_lists='%TestFlightDistList%'



Final notes

In reality I actually have one build template and 2 configurations that are linked to it.
The base template just gets the files from the VCS and builds the projects.  My continuous integration configuration is based on this with no changes.

I have another Ad-Hoc build configuration also based on this template that adds the two extra build steps for incrementing the build number and uploading to test flight (with the build projects step inbetween the two of them).

At the moment the build process is just about manageable in TeamCity.  If it got any bigger I would definitely move the build steps out to something like Make or MSBuild\xBuild.

Delphi 2009 - How to treat warnings as errors

A long overdue addition to Delphi is the ability to treat compiler warnings as errors. I could have done with this some years ago and have really missed it since moving from C# back to Delphi a few months ago.

If you've had some trouble finding where to enable this option, I suggest you have read at this classic Daily WTF article and then have another go at looking for it.

Turns out that under the 'Hints and Warnings' section of the project options there is an option called 'Output Warnings'. Next to it is a drop down list with the default value of 'True'. Now most sane people would expect there to be only one more option in that drop down list. Turns it there is actually another two! Dropping down the list reveals all 3 options: 'True','False' and 'As Errors'

Hmmm. No wonder I couldn't find it.

I posted a question on Stack Overflow in case others are looking for it.

Dynamic CRM 4.0 Data Migration Manager validation error - Line breaks

My company are in the process of migrating from Outlook Business Contacts Manager to Microsoft Dynamic CRM 4.0.

I've hit and overcame a few brick walls during this process, which is still ongoing. I've decided to document my findings in case anyone else comes up against the same problems.

The first problem I came up against and probably the most common is line breaks in your field data causes the validation process of the data migration manager to fail. It seems to see a line break as the start of a new field even when your data is surrounded by double quotes.

To be more specific it's a carriage return (Cr) followed by a line feed (Lf) that causes the problems. The only solution that I know of is to replace the CrLf pairs with just a Lf.

This can be easily done in Excel with a macro that you run over your worksheet.

Sub repLF()
Cells.Replace What:=vbCrLf, Replacement:=vbLf, LookAt:=xlPart, _SearchOrder:=xlByColumns, MatchCase:=False, SearchFormat:=False, _ReplaceFormat:=False
End Sub

For me that seems to get rid of most validation errors. I've looked at the imported data in the CRM and it seems to be OK i.e. line break still appear properly.

Hope that helps seem people who are facing the same problem.