Archive for January, 2014

cr3bits

Kanban Board Enhancement Proposal

Too much information kills information. — Proverb

The Kanban board was initially used to visualize the workflow of a production process but it can also be used for knowledge work like the software development process. A simple board can be implemented with sticky notes on a wall but it can also be implemented in software with tools like Kanbanery.

The objective of this post is to propose enhancements for the Kanban board that could potentially improve the user experience. The enhancements result from analyzing the properties of the board using principles from the Semiology of Graphics.

Graphical Analysis

Open Active Closed

Item 1
Item 2
Item 3
Item 4

The information in a Kanban board consists of the work items assigned to a team for the duration of a sprint (or iteration). This complete and unchanging definition common to all data points is called the invariant. Each work item must at least specify a summary and status, but it can also specify a priority, owner, estimate, tag, etc. In turn, these variations between items are called the variables (or components).

A variable has a level of organization that is fundamental for reordering, comparing and grouping information. The level can be characterized as:

  • Qualitative: Like the owner of a work item, it doesn’t have a universal order so it can be reordered arbitrarily for information processing purposes.
  • Ordered: Like the status, it has a single order from open to closed to convey the progression of a work item.
  • Quantitative: Like the estimate, it is possible to say that an item is estimated to take twice as long as another item.

The board is a two dimension plane containing a few geometric elements, each representing some information:

  • A point indicates a position on the plane with no theoretical length or area, it can be the size of an avatar to represent the owner of a work item.
  • A line has a start and end position with a measurable length but no area, it is primarily used to evaluate the number of work items under a status column.
  • An area is composed of points linked by lines which delimit a part of the plane, it is used to represent individual work items capable of containing more information.

The values assigned to a variable are represented with images that reflect different levels of classification. The separation of values, like the different owners, can be expressed by:

  • Color: Range of all color sensations which are not always perceived by everyone.
  • Orientation: Hatching of lines varying in orientation from horizontal to vertical.
  • Shape: Given the same surface, an image can have many different shapes.

The ordering of values, like some priorities being higher than others, by:

  • Grain: Hatching of varying lines ranging from fine to coarse-grained.
  • Value: Intermediate colors between black and white.

The quantity of values, like estimates in hours, by:

  • Size: Height of a column, surface of a line or a quantity of equal images.

Open Items

At the beginning of a sprint, work items are all open and appear under the left column of the Kanban board. This is the same effect as a degenerate binary tree where all the nodes form a linked list. For team members, as for computers, this is inefficient to choose the next item to work on.

An enhancement would be to move the open items to another board. Instead of using the status as columns, another variable could balance the items across multiple shorter columns. If the items are tagged, it might be more efficient to choose from a column with items of the same tag. The problem is that open items with a lower priority might be chosen from one column before other items with a higher priority in another column.

Tag 1 Tag 2 Tag 3

High Priority
Item 1
Item 2

Low Priority
Item 3
Item 4

This could therefore be extended with areas ordered by priority spanning all tags, as illustrated on the right. The items from the highest priority area are clearly visible while keeping an overview of the remaining work items. Another problem is that fragmenting the board breaks the complete workflow which is core to understanding how the work proceeds.

The actual benefit depends on whether the gain of choosing work items more effectively outweighs the cost of breaking the workflow.

Closed Items

During the course of a sprint, more work items are closed and appear under the right column of the Kanban board. This gives the impression that the length of the column can be compared with the length of other columns to evaluate the amount of work completed so far. This might be misleading because the length is proportional to the number of work items rather than the hours of work.

An enhancement would be to change the representation of work items from punctual elements without a theoretical length to line elements with a length relative to the estimate. By adding these elements under the status column, the length becomes proportional to the total hours of work. The problem is that the estimate for the closed items might be different from the actual time spent which might affect completing the sprint on target.

80% 100% 120%

Item 1
Item 2
 
Item 3
Item 4

This could be extended by moving the closed items to another board where the columns would be the relative difference between the estimate and the time spent, as illustrated on the right. The columns should look like an upside down normal distribution where skewness to the right indicates the sprint might not be completed on target. This suffers from the same problem as before of breaking the complete workflow.

Another enhancement might be to supplement the Kanban board with a burn down chart (or burn up chart). The benefit is that the chart is like a time series that displays the progress of the whole sprint whereas the Kanban board is more like a data map that only displays a snapshot of the current state.

Summary

This post proposed enhancements for a couple of areas in the Kanban board; open and closed work items. The enhancements sometimes solved problems only to be replaced by other problems. So, the benefit of their adoption actually depends on context.

The enhancements also attempted to extend the board with more variables which ultimately resulted in more boards. So, adding more variables doesn’t necessarily add more information; it might actually kill information.


Mathieu Trudel-Lapierre
Last month, I blogged about urfkill, and what it's meant to be used for.

The truth is, flight mode and proper killswitch (read: disabling radios on devices) handling is something that needs to happen on any device that deems itself "mobile". As such, it's one thing we need to look into for Ubuntu Touch.

I spent the last month or so working on improving urfkill. I've implemented better logging, a way to get debugging logs, flight mode (with patches from my friend Tony Espy), persistence, ...

At this point, urfkill seems to be in the proper state to make it, with the latest changes from the upstream git repository, into the distro. There is no formal release yet, but this is likely to happen very soon. So, I uploaded a git snapshot from the urfkill upstream repository into Trusty. It's now time to ask people to try it out, see how well it works on their systems, and just generally get to know how solid it is, and whether it's time to enable it on the desktop.

In time, it would be nice to replace the current implementation we have of killswitch persistence (saving and restoring the state of the "soft" killswitches) currently in two upstart jobs — rfkill-store and rfkill-restore — with urfkill as a first step, for the 14.04 release (and to handle flight mode on Touch, of course). In the end, my goal would be to achieve convergence on this particular aspect of the operating system sooner than later, since it's a relatively small part of the overall communications/networking picture.

So I call on everyone running Trusty to try to install the urfkill package, and file bugs or otherwise get me feedback on the software. :)
Mathieu Trudel-Lapierre
Last month, I blogged about urfkill, and what it's meant to be used for.

The truth is, flight mode and proper killswitch (read: disabling radios on devices) handling is something that needs to happen on any device that deems itself "mobile". As such, it's one thing we need to look into for Ubuntu Touch.

I spent the last month or so working on improving urfkill. I've implemented better logging, a way to get debugging logs, flight mode (with patches from my friend Tony Espy), persistence, ...

At this point, urfkill seems to be in the proper state to make it, with the latest changes from the upstream git repository, into the distro. There is no formal release yet, but this is likely to happen very soon. So, I uploaded a git snapshot from the urfkill upstream repository into Trusty. It's now time to ask people to try it out, see how well it works on their systems, and just generally get to know how solid it is, and whether it's time to enable it on the desktop.

In time, it would be nice to replace the current implementation we have of killswitch persistence (saving and restoring the state of the "soft" killswitches) currently in two upstart jobs — rfkill-store and rfkill-restore — with urfkill as a first step, for the 14.04 release (and to handle flight mode on Touch, of course). In the end, my goal would be to achieve convergence on this particular aspect of the operating system sooner than later, since it's a relatively small part of the overall communications/networking picture.

So I call on everyone running Trusty to try to install the urfkill package, and file bugs or otherwise get me feedback on the software. :)
David Murphy (schwuk)

HP Chromebook 14 + DigitalOcean (and Ubuntu) = Productivity

Although I still use my desktop replacement (i.e., little-to-no battery life) for a good chunk of my work, recent additions to my setup have resulted in some improvements that I thought others might be interested in.

For Christmas just gone my wonderful wife Suzanne – and my equally wonderful children, but let’s face it was her money not theirs! – bought me a HP Chromebook 14. Since the Chromebooks were first announced, I was dismissive of them, thinking that at best they would be a cheap laptop to install Ubuntu on. However over the last year my attitudes had changed, and I came to realise that at least 70% of my time is spent in some browser or other, and of the other 30% most is spent in a terminal or Sublime Text. This realisation, combined with the improvements Intel Haswell brought to battery life made me reconsider my position and start seriously looking at a Chromebook as a 2nd machine for the couch/coffee shop/travel.

I initially focussed on the HP Chromebook 11 and while the ARM architecture didn’t put me off, the 2GB RAM did. When I found the Chromebook 14 with a larger screen, 4GB RAM and Haswell chipset, I dropped enough subtle hints and Suzanne got the message. :-)

So Christmas Day came and I finally got my hands on it! First impressions were very favourable: this neither looks nor feels like a £249 device. ChromeOS was exactly what I was expecting, and generally gets out of my way. The keyboard is superb, and I would compare it in quality to that of my late MacBook Pro. Battery life is equally superb, and I’m easily getting 8+ hours at a time.

Chrome – and ChromeOS – is not without limitations though, and although a new breed of in-browser environments such as Codebox, Koding, Nitrous.io, and Cloud9 are giving more options for developers, what I really want is a terminal. Enter Secure Shell from Google – SSH in your browser (with public key authentication). This lets me connect to any box of my choosing, and although I could have just connected back to my desk-bound laptop, I would still be limited to my barely-deserves-the-name-broadband ADSL connection.

So, with my Chromebook and SSH client in place, DigitalOcean was my next port of call, using their painless web interface to create an Ubuntu-based droplet. Command Line Interfaces are incredibly powerful, and despite claims to the contrary most developers spending most of their time with them1. There are a plethora of tools to improve your productivity, and my three must-haves are:

With this droplet I can do pretty much anything I need that ChromeOS doesn’t provide, and connect through to the many other droplets, linodes, EC2 nodes, OpenStack nodes and other servers I use personally and professionally.

In some other posts I’ll expand on how I use (and – equally importantly – how I secure) my DigitalOcean droplets, and which “apps” I use with Chrome.


  1. The fact that I now spend most of my time in the browser and not on the command-line shows you that I’ve settled into my role as an engineering manager! :-) 

The post HP Chromebook 14 + DigitalOcean (and Ubuntu) = Productivity appeared first on David Murphy.