Kanban for kids

Facing the arrival of another child, I set out a few months ago to experiment with ways to help each other get things done together as a family without becoming a task-master of a father. A very simplified Kanban board seemed like a good fit for our kitchen wall, as it visualises what needs doing or other fun things that are planned, helps us to help each other when needed, and enables the kids to take part in the planning and organising of the day.

The photo of our board above is what we’ve ended up with after a few months. It is really a habit tracker – with most of the items on the board being things that we do daily, every few days, weekly or fortnightly. Some points that we’ve found helpful:

• Items specific to the kids are colour coded (ie. we have a “Put clothes away” item for each child in their colour).
• We have some incentives – each item has a number of associated “service points” [1]. For eg. 5 for putting away clothes, 15 for taking the dog out for a walk etc. (agreed with the kids and adjusted on feedback).
• We have incentives to have fun doing items together – if you complete an item together with someone else, you get 50% extra service points, simply to encourage having fun doing things together (we put a magnet on the item to signify this).
• We very rarely tell the kids to do something – in extreme circumstances I’ve told my daughter I need her to take the dog out now as I can’t do it myself, but it’s something we generally avoid, in fact…
• The kids generally choose what item they want to do next and when they want to do it (ie. “You’d like to help daddy set the table for lunch? Shall we do it now or after playing Lego for a while?”).
• Each item has a drawing and is laminated with a small magnet, so that we can stack certain items together (for eg, we have a stack of cards related to the dog which are done in order each day – dog breakfast, walk 7am-ish, Walk 11am-ish, etc).
• We start each day by pulling things that we want to do into the backlog (in addition to the daily stuff). Some items are weekly, which we store in a stack for each day on the top-left. Other items are ad-hoc which we pull in from the mess on the bottom left.
• We limit the number of cards in the TODO and Doing lanes to 4, to help us help each flow (or review whether we really want to do something).
• We don’t put normal stuff like playing lego or dressups there – the kids can play whenever they want without feeling they need to have an item on the board

So far it’s been a great help, but as always, a continual learning process. Each child is motivated by different things, and yet the end goal is that we’d all enjoy helping each other without extrinsic motivation. Interestingly, one of the most freeing things has been for the kids (and my wife) to get used to the fact that it’s OK to say, no, I don’t feel like doing that today, I’m just going to move the card over to Thursday for the moment. That is, the board is something we control – a helpful way to organise and communicate – it does not tell us what we have to do.

[1] Service points – The kids can use the service points at the end of the day in ways such as staying up a bit later (1minute per point, within reason), or going out on their own with mum or dad for an ice-cream desert (50 points). We haven’t yet found a good solution for left over points, and are currently converting to Euro-cents as pocket money at the end of the week which works well in terms of value, but I don’t like the direct connection of being paid money to do stuff around the house. Another option I’m trying at the moment is using saved service points as bargaining power for larger items that the kids need (like a new school bag). I’d be glad to hear of other ideas.

More YUI and html5 fun

Continuing on my YUI MVC experiment, I got to spend a bit of time last week playing with my prototype for Open Goal Tracker, and was blown away by the simplicity of two new html attributes: x-webkit-speech (just ‘speech’ when standardised) and contenteditable. Here’s a 2min video showing how I might use both of them in practise (in dire need of styling as usual):

 

 

Behind the scenes I’m still loving Yahoo User Interfaces application framework together with the unit-test api, which allow me to create tests like “creating the view should render stats for existing goals”.

Next week I hope to start implementing the server-sync and investigating integration with Ubuntu’s notification system. Once I’ve sorted out the application-cache and build/packaging etc. for both Ubuntu and Android, I want to do a initial dummy release and then start iterating the features that will make Open Goal Tracker actually useful for facilitating social-yet-individual learning, both within and without of classrooms.

You can play with the little open-goal-tracker prototype (I’ve only tried webkit so far) or run the tests yourself.

Working in the cloud

For a while now I’ve done all my development work and irc communication via SSH and byobu – I love the freedom of just grabbing my netbook (ie. switching computers) and heading to a cafe and picking up right where I left off (or even letting tests run while I walk).

The one pain-point was that I SSH’d into my own box at home – and if my home connection went (anything from a thunderstorm to a curious kid pulling a chord), I had to then work on my much slower netbook.

Now, after reading on an email thread that Aaron was doing something similar, I’m running a tiny cloud instance for my irc and development work, and documenting everything that I’m doing to get my dev environment just right – so that I can automate the setup (not really something for an ensemble formula – just a simple script).

That, and having all my music in the cloud for the past 6 months make switching computers and/or physical locations a non-obtrusive part of my work-day.

If anyone has small tips that make their own dev environment enjoyable, let me know!

Code-reviews as relationship builders

I really enjoyed the emphasis of Ben’s Code-reviews as relationship builders post over the weekend. The focus on healthy learning relationships both for new and old is great – something I’ve tried to focus on myself over the past few years working in distributed teams.

On a related note, I’ve wondered of late whether I could use “Agreed” rather than “Approved” when reviewing a branch. Agreed (IMO) implies one type of relationship – peer discussion resulting in agreement – rather than an approval from an authority (perhaps without interaction). It is a small and maybe insignificant distinction…

Experimenting with daily stand-ups

My direct team-mates at Canonical live everywhere from the US west-coast through to Poland, so we don’t have the option of doing a ‘traditional’ stand-up each day.

In the past we’ve done IRC standups – each pasting our notes at one point in the day when we’re all online – which helps a few points (recording what we’re up to) but has quite a few drawbacks in my opinion (see Vincent’s thoughts on irc standups also). A lot of us on the team admitted that we didn’t always give the irc standups our full-attention.

Right now we’re trying an experiment which is kind-of neat. We’re doing voice standups in pairs/triplets with people in similar timezones, but adding our standup notes to a wiki page before the call. The advantages are that the calls are easy – I can read through Lukasz’s notes and we just discuss any issues or successes as well as the plan for today, and vice-versa. Also, as we all subscribe to the wiki page for email notifications, we actually read everyone else’s notes from different time-zones asynchronously (and all stakeholders can take part in calls or read the notes as desired).

Personally, having a brief voice call as part of my day is a huge benefit – just touching base with another voice from work, and having a bit of a chat after going through our stand-up gives a more human touch to working from home. It’ll be interesting to see whether others on the team find it more or less helpful.

Moving on from Launchpad

I’ve been working at Canonical for nearly two years now, in a role that I think of as a support role for all the awesome Debian, Ubuntu and application developers out there who use Launchpad to publish their software in Ubuntu. Most of my time has been spent making it easier to get software to users of Ubuntu (technically, working on Launchpad’s archive features such as Personal Package Archives), but I’ve also enjoyed improving processes for designing new features collaboratively in an open environment.

It’s been a great two years and I’ve learned an incredible amount while working with the Launchpad community. And although I’m not leaving the community, I will be spending the majority of my time developing tools on a different team in Canonical. I’m excited to be spending more time doing Django development, and am hoping that the skills I’ll be building there will give me opportunities to work on a bunch of open-source education-related tools in my own time to support life-based open-learning – something I’m quite passionate about…

The work that we all do in the open-source world impacts thought and philosophy far beyond the circles we work in. Principles from open source software have already been changing the way people think about copyright in education (the free high-school science texts project is an incredible example of that), but I believe they will also change the way we facilitate the learning of the next generations (from my edu-focus blog). Educators in schools and universities are already adapting to new mediums and principles but – in the same way that early film commercials re-implemented the stage on film - educators are often just re-implementing the classrooms of the past online (with “Learning management systems” that deliver content and keep the teacher/institution managing the learning). Schools and other education institutions need either a revolution or speedy evolution, and I’m excited to be a part of that both indirectly through my work and in my own time.

Testing Launchpad Soyuz features

When hacking on Launchpad’s soyuz application – and creating tests to verify that your new functionality works, you’ll often need sources or binaries published in very specific scenarios.

This demo of using Launchpad’s SoyuzTestPublisher for testing shows you how you can setup those scenarios using the Soyuz Test Publisher which – as the name suggests – was created for this exact reason (by Celso).

To save you typing (or squinting if you can’t view the hi-res version of the demo), the python script for the demo is available also.

Ubuntu 9.10 on EeePC 1008HA

After reading lots of reviews, I went out and bought an EeePC 1008HA (‘Seashell’) netbook last weekend and installed the alpha Ubuntu 9.10 Netbook Remix… and everything just worked. Very impressed.

I haven’t decided whether I’ll stick with the Netbook Remix launcher interface, or just go for a cut-down desktop with Gnome-do launcher, but eitherway it’s lovely to use.

Trusted software archives

During the Ubuntu Developer Summit there were a number of discussions around how debian operating systems, such as Ubuntu, can best enable people to add trusted software archives to their computer (see the blueprint AptURL-policy for Ubuntu Karmic).

As far as I understood, there are three competing issues:

1. There is currently no easy way for a person to evaluate whether a software archive might be trustworthy – other than trusting a centralized white-list,
2. Installing software directly from a web-browser click should be minimized and discouraged,
3. There should be an easy way for people to share (and maintain) software that they develop

I’m only going to discuss the first point here. DoctorMo has some great mockups demonstrating gpg-keys being used for identity and software trustworthiness, but a few people have commented on the problem of confusing the “web-of-(identity)-trust” that gpg keys currently provide with some sort of general trust that the identified person will be responsible with my computer.

Reading all the comments there leaves me wondering whether we should stop using the phrase “web-of-trust” and instead use the more verbose “web-of-identity-trust” to avoid confusion – even though it doesn’t roll off the tounge so easily. I love Martin’s idea – the concern is real – but am wondering how it could be implemented in a decentralised way.

Of course, it would be possible to add this as an api feature of Launchpad – my feeling is that Launchpad should be a source of the social value of an archive (ie. user ratings etc.), but not necessarily a source of this fundamental trust-relationship.

So here is an idea: what if the repository contained this infrastructure itself, such as a directory of meta-information, ‘identities-who-trust-this-archive’, which contained signed trust files ‘trust-of-canonical.txt’ or ‘trust-of-joe-bloggs.txt’. The text could just be a standard paragraph, or be modified by the signer if needed. The installer on the operating system would allow the user to check the trust text etc. Could this work? Can anyone see any issues? (hmm… revoking trust would not be possible without revoking the key used to sign the document?)

Outside-in development on Ubuntu

For over 6 months now I’ve been working on launchpad.net – collaborative development for open source software – using Python (Zope). It’s been an unreal experience seeing various testing strategies on such a large code-base, but the two things I miss the most while developing on launchpad are:

1. The ability to do outside-in development properly – as is possible with ruby’s Cucumber project (although, this could be used, but it’d be adding yet-another-technology to the stack – I haven’t tried pyCucumber, but it doesn’t look too active), and
2. Something similar to rspactor – allowing tests to be run automatically as I edit files, and reporting them via the OS’s notification system.

But trying to communicate exactly what I mean by that to people who haven’t used rspactor or Cucumber is kind-of tricky, so here’s a video demo’ing how I’d love to do inside-out development on Ubuntu…