Saturday, May 19, 2012

Using Kanban for Work


I've been using agile development methodologies (Extreme Programming (XP), RUP, Scrum, etc) for over a decade now. In every job I've had in that time I've touted the benefits of using agile rather than whatever process was prevalent (usually just basic waterfall). In some cases the teams totally bought into it and saw fantastic productivity improvements (like a 300% increase at one company). I've had grassroots support in the trenches only to have senior management balk at it ("too hard to track", etc. - the typical NIH issues). In some cases, the team decided to implement it anyway. Other times the team thought they knew the technology but just ended up with iterative waterfall (smaller waterfall cycles).
Example KanbanFlow board
For all of my work with Otto Von I've done agile in some way. I've been doing primarily XP with some modifications given I'm a one-man shop. But lately Kanban has been getting a lot of traction in my mind and I've just started using an online Kanban board (see this post for a little more about it). What I like about Kanban is that it's really better adapted to how I need to work and what I focus on from an agile perspective - take on a small chunk of work, complete it, move on to the next.
A slice of cake is like a story
So what does Kanban offer? First, as in all agile methodologies, you start with decomposing the work that needs to be done into small pieces. The key concept is to look at the entire project as a cake that you cut into vertical slices. In most applications there are layers that need to be built (back-end, UI, storage, database, etc). With the slice, you focus on doing all of the work on the layers at one time in the slice while providing some small element of value to the project. In the picture above you can see that I've got stories like "Add Friend". These require UI changes. back-end code, and DB changes. That's my slice for that piece of work. These can sometimes relate to "functionality" or "features", but traditionally features are larger than a story would allow.
Your first column is usually the "backlog" or "To Do" list. These are the stories that you've started to define but aren't really complete enough to really consider for developing. Ideally you prioritize the backlog so you can quickly identify those stories that you need to finish defining first. Your "Ready to Pull" list are the stories, in priority order, that can be worked immediately if you have the bandwidth. The "In Progress" is just that - things that you are actively working. Sometimes called your "WIP" (work in progress), this should contain only those stories that you can work on and complete in two weeks (the standard iteration/sprint length). This insures that you don't try to take on multiple tasks that de-focus you from working something through to completion. Finally, when you've completed a story you move it to the "Done" list. It's pretty straight-forward, but the challenge is making stories/slices that are usable and small enough. It takes a lot of practice and even after a decade I struggle sometimes.
Kanban allows you to have multiple work items in process (your WIP limit). For me that's generally one. I need to focus on that one thing, get it completed, and move on to the next. With a larger team than I have (i.e., more than one),  your WIP limit will be larger. Using the Kanban board lets me prioritize the work that needs to be done. I can add new stories, shift priorities - all things that are important in running a small project.
KanbanFlow, the free(!) online board I'm using doesn't have some typical user story fields (and no, I don't get a kickback for rating them so highly, but maybe I should; are you listening, KanbanFlow?!). For instance, it tracks time in hours not points. I guess you could use the "hours" field as a "points" field, but overall it's a small thing. So far I am very pleased with the software and able to work around (or ignore) the things I don't require.
If you're looking to get some focus on your work, Kanban is certainly one methodology that you should explore. And KanbanFlow is a very good free service should you choose that direction. Good luck and happy coding.

Thursday, May 17, 2012

Stupid relearnings

It's been a while since I've written any iOS code. All of my work on OttoJotts lately has been in PHP working the back-end pieces. I've written quite a bit of the web interface to break up the code into functions that I'll be able to use for both mobile and web. It's been a lot of work, but it's starting to come together finally. I've got a few more pieces of functionality to add to the back-end to allow folks to use a web page to play the game. Which will be interesting and should really exercise the code without having to have everyone download a new iPhone app. I can then finish up the iPhone version and maybe actually be done with this app.
On an aside, I've been using KanbanFlow (link here) to track the work I've been doing and the ToDo for future work. I was using Google Wave to do that originally. When Wave first came out, I was horribly excited because it meant that I could document my ideas, see how those ideas morphed over time, and keep the most up-to-date version of the thought process available. And then I could share that with someone else if I needed to (like bringing someone else into the project). Since Wave is going away and all of the waves are read-only now, I needed something new. Given that I've more than a passing familiarity with agile (having done it for over a decade now), I decided to give some kind of Kanban board a shot. I ended up picking KanbanFlow - it's met my needs so far by allowing me to track multiple boards (I have one for regular ToDo and one for OttoJotts ToDo's).
KanbanFlow's UI
I love that I can customize the columns (although I don't need to) and I can easily move things between the columns. It also allows you to track the estimated to time to complete a task and how long it actually took. I'm not really using those features, but I suspect I will later. Plus, you can color-code your tasks to track different elements of the project. Very cool stuff. I may write up a quick post on using Kanban for development later. Anyway, that's not really the point. Nor is that I've been working on OttoJotts back-end. What IS relevant is that because I've been doing that I've been away from iOS too much.
I decided to work on a quick project to see if I could do it in my "copious free time", but it's a little application for my toddler. The idea is an app that plays Old McDonald and lets him pick from one of three animals and then it strings the song together with the order he's selected. Pretty basic stuff, but it will be fun for him, I think.
What I've been relearning is the basic constructs to make the application, which sounds terrible (and is more than passingly so). I had thought "This might be easy in OpenGL" and then I looked at what was really needed there (gesture detection, processing, etc) and decided quickly - "Um, no". So then I decided that I should probably make a basic UIView application and I'd add UIImages to it. Which would have been fine, but again - need to check for "clicks". Then I *facepalmed* myself and realized that I just needed to have UIButtons. They have all the functionality I need - they can be "clicked" and they can have images associated with them. D'oh. So now I'm making some good forward progress, but it just seemed like a ridiculous amount of time to spend on something so basic it beggars the imagination. Such is the curse of being away from a technology too long...
What does this mean for all the apps I'm working on? Absolutely nothing. This is pretty much a one-off for my kiddo. I might post it to the App Store to share it. But that's neither here nor there and we'll have to see how it feels when it's done. Right now, though, it's got a date with a very important audience of one. Guess I better get back to it.