Late March this year I hosted David J Anderson’s first official Kanban Traning Class in Norway. Having David over to teach one of his classes was definitely both exiting and a great learning experience for me personally. I’ve been using Kanban for a while now and really come to appreciate the evolutionary way of pursuing continuous improvement and learning.
Now, if you’re going to arrange a course you need some way for people to register, so I decided to create a small web application for this purpose. I did not have much time and I had to do the work during evenings, after getting the kids to bed. In other words, I was in need for some rapid web development. If you want to deliver quickly I think the following is very important:
- Choose a tool/framework that lets you focus on doing the job
- Deliver often
Feedback loops are important. We get lots of different feedback from various sources when developing software (unit tests, acceptance tests, manual tests, stakeholders etc..) The most important feedback however, is the one you get from the users of your software. To get that feedback you need to deliver often. But first let us take a look at a web development framework that puts you in a position to deliver in a fast pace.
Play Framework Lets You Focus On The Important Stuff
I tweeted this a while back. Since then I could have tweeted it many more times. In my day job, I write software for the enterprise, deployed on Oracle Weblogic Server or similar. Every time I run into a problem, be it an infrastructural or a programming problem, it almost always seem to take longer to fix than I expected. I have worked with Weblogic servers for about 6 years now and one thing’s for sure: Working with the application server has not gotten any easier (often times it actually feels more like working against it).
With Play Framework it is quite the opposite. Whenever I run into a problem it always seems to take less time to solve it than I expected.
The way Play Framework is built, it lets you focus on the important stuff, building features which hopefully delivers business value (whatever that is) to your organization. So to when building the registration application for the course mentioned previously. Granted, the application in question is not a particularly complex one. The domain is straightforward and there are no complex integrations with external applications. It does however contain a fair amount of features: The possibility to register for both the training class and the free half-day Kanban seminar we hosted, mail sending, information about the course and seminar, information about Kanban and a separate admin application. Play Framework made the job really easy. Whenever I had some new features ready I just deployed the application to the cloud. In case of errors I just rolled it back to the previous working version.
Approaching Continuous Deployment With playapps.net
There are a lot of deployment options for Play applications: Google App Engine, Stax Cloud Hosting Platform, EC2 or their own Playapps cloud solution. I chose the latter, partly because I wanted to try it, partly because it contains all the infrastructure needed: Runtime, mysql database and that would pretty much be it. After all, it is a simple application. The most important reason for choosing playapps.net however, was that it looked really easy to use. My deploy to production now consisted of typing one command and then just following the command line instructions. Although not automatized it’s still pretty simple.
Limiting WIP reduces fear
Ok, so what does this have to do with Kanban? Well, one thing I learned in the process of developing the registration application was that an increase in code inventory also increased the fear of releasing the code. And the increase in inventory didn’t have to be substantial at all before fear was creeping in.
So to defeat this fear I set up a Kanban board using Flow.io.
As you can see, the workflow is fairly simple and the limits are kept low, this will help in keeping the average cycle time low. I realize that this approach is not a 100 % continuous deployment (and it’s manual), but it’s a start.
Even for this small application I found it incredibly useful to visualize and limit the amount of work in progress. It helped me to keep focus and to deliver features and bug fixes quickly into the production environment, if not entirely continuously, then at least regularly.