Our checklist for running a daily meeting with kanban

The squad I manage is fully distributed, like most of Canonical's employees.  We are all in relatively overlapping timezones--ranging from Italy to the American east coast--but none of us work in the same building, or even the same city.

We also are on the Lean journey.  We're not nearly as far along as others you'll find blogging on the web.  However, maybe we're interesting because of the combination: lean, plus a distributed workforce.

I suspect that working in a distributed team increases the importance of good practices.  When they are not followed, the pain is more intense.  For example, I think that writing everything down is important for running a business well; but it is essential, or more obviously essential, for a fully distributed team.

Another good practice like this is a daily meeting.  We've done this for many years now, and it is essential to our coordination.  We combine it with an online kanban board, which is central to our daily workflow and coordination.

We've also recently combined it with another good idea, checklists, and that's what I want to share right now.

Yellow Squad Weekly Retrospective Minutes: June 15

Introduction

What is this post?

I'm the lead for the "Yellow" squad in Canonical's collection of geographically distributed, agile squads.  We're directed to work as needed on various web and cloud projects and technologies.  Every Friday, our squad has a call to review what happened in the past week and see what we can learn from it.  We follow a simple, evolving format that we keep track of on a wiki.  This post contains the minutes of one of those meetings.

Yellow Squad Weekly Retrospective Minutes: June 8, 2012

Introduction

What is this post?

I'm the lead for the "Yellow" squad in Canonical's collection of geographically distributed, agile squads.  We're directed to work as needed on various web and cloud projects and technologies.  Every Friday, our squad has a call to review what happened in the past week and see what we can learn from it.  We follow a simple, evolving format that we keep track of on a wiki.  This post contains the minutes of one of those meetings.

Why read it?

The point of the meeting, and of these minutes, is to share and learn.  We'd be happy if you do both of those.  You might be interested in our technical topics, or in the problems we encounter, in the process change that we try to follow based on our successes and failures.

What are we working on right now?

Our current project is applying LXC virtualization to the 5+ hour test suite of the Launchpad web application.  By parallelizing the test suite across lightweight virtual machines on the same box, we've gotten the time down to under 40 minutes.  That's still not ideal, but it is a whole lot better.

Now read the minutes!

Yellow Squad Weekly Retrospective Minutes: June 1, 2012

Introduction

What is this post?

I'm the lead for the "Yellow" squad in Canonical's collection of geographically distributed, agile squads.  We're directed to work as needed on various web and cloud projects and technologies.  Every Friday, our squad has a call to review what happened in the past week and see what we can learn from it.  We follow a simple, evolving format that we keep track of on a wiki.  This post contains the minutes of one of those meetings.

Why read it?

The point of the meeting, and of these minutes, is to share and learn.  We'd be happy if you do both of those.  You might be interested in our technical topics, or in the problems we encounter, in the process change that we try to follow based on our successes and failures.

What are we working on right now?

Our current project is applying LXC virtualization to the 5+ hour test suite of the Launchpad web application.  By parallelizing the test suite across lightweight virtual machines on the same box, we've gotten the time down to under 40 minutes.  That's still not ideal, but it is a whole lot better.

Now read the minutes!

Clojure/conj: The Talks

The previous mammoth post was about the questions and answers I found at the Clojure/conj conference and training.  This mammoth post is my notes from the talks.

Clojure/conj: The Questions and the Answers

Wow. I just had a full immersion experience into the Clojure language and community, and it was awesome.  I'll write about in two posts: questions I tried to answer, and notes from the presentations.  Here's the first.

Open Source

Canonical has encouraged us employees to blog about the work we do on open source. I intended to include these comments as part of the previous post, but that one was too long already.

Open source has been a huge part of my life for many years now. A friend once suggested I commission a song cycle about it, but I haven't been inspired in that particular direction yet. Reflecting back on my open source participation is interesting. I'll start with...

Launchpad

I'm one of the team leads on the Launchpad project. Launchpad's mission to connect open-source software developers within and between projects, and with Ubuntu packagers and users, is an amazing goal. Pragmatically, part of the goal is to help make Ubuntu the best Linux distribution available, and even the best general operating system available. That's a business goal. Beyond that, though, the engineers and managers behind Launchpad truly want it to be a part of improving the entire environment of open source. It's a huge, ambitious effort, and I'm proud to be a part of it.

Since I'm a manager at Launchpad, I have people to point to also.

• Leonard Richardson has already spoken for himself on his blog.
• Benji York doesn't have anything up on his blog yet as of this writing, but in addition to Launchpad, he has a long history of contributing to open source software. I think that Manuel and zope.testbrowser are highlights.
• As part of the QA team, Diogo Matsubara works on analysing the "oops" reports (error logs from the Launchpad application), bringing the prominent ones to the engineers' attention. In the analysis work, sometimes Matsubara suggests ways to fix the bug or finds the root cause, saving the LP engineers time. To accomplish that analysis, Matsubara maintains and improves the Oops Tools, a soon-to-be-open-sourced Django application that helps summarize the oops reports. Matsubara has also been working on improving the testability of Launchpad API clients. The first mission was to convert the Apport tests to avoid screen scraping and use launchpadlib. In a related effort, he's working on defining a API SLA, using the Apport work as the initial test case. Finally, Matsubara helps with process changes to make the Launchpad development easier, more fun and faster. He helped design and hack on the changes to make the recent "merge workflow" process plan work and rock for the LP team.
• Ursula Junque is a very valuable QA engineer for the Launchpad project who has initiated and contributed to many different parts of Launchpad. If she gives me a nice summary like Diogo's I will post it here. :-)
• Stuart Bishop, Launchpad's database administrator, is crucial for keeping Launchpad running smoothly. Beyond that, he has produced several open source projects. Perhaps his biggest contribution is his own timezone library, pytz, which to my knowledge is the standard Python library for this task.
• Maris Fogels hasn't posted anything yet either, but I know he has contributed to Windmill and done some great work on Launchpad's open source libraries.

Speaking of Launchpad's open source libraries, I should mention them too. None of them are mine, but I'm not sure anyone else will mention them all. If you head over to the LAZR project, you'll see many. I've heard mention of a few people finding uses for them, and I hope many more will too!

Zope

The Zope project was the biggest thing that brought me into the world of open source, and I learned a huge amount from it. It's been a big part of my life, and I wouldn't be the same engineer, or even the same person, without it. I think the changes that are happening in the Zope community that I talked about in the previous post are important and good, even if they are a bit painful to see sometimes.

I've contributed a lot to the Zope 3 project, and to the ZODB. Some of the projects I've done that are reasonably popular are zope.copy (over 25000 downloads, and actually useful in pure Python with only a dependency on zope.interface), zc.queue (over 19000 downloads), zc.relation (over 4000), zc.blist (890 downloads; heh, maybe I should move it out of "beta"), zc.async (only 355, but I know some use it heavily), and zc.catalog (meh, 267; I thought it was bigger than that). I have other, older and/or smaller ones too.

I've also contributed to the core projects, like ZODB, over the years as well.

Moreover, often while working on Zope projects, I've also made several other Python contributions. I'll mention those next.

Other projects

I just added the ability to use system Python packages with Buildout. That's a big deal for some.

I added the ability to have "latent slaves" to Buildbot. This means that, for instance, buildbot can start a slave on EC2 on demand when it needs to run a test. Hudson can do that now too, but at the time I added it, it was new, I think.

I did a bit of work on mechanize. The biggest job was teaching it to understand form labels, which made zope.testbrowser tests much more readable and usable.

I tweaked some table generation code in ReportLab.

It is fun to believe that I've contributed a decent amount to the world, and even (usually) had jobs while doing it.

Related work

Finally, since I'm here at a conference, I can't help but reminded that conferences--particularly presenting at conferences--can be very hard work too. I've presented several times (OSCON and DZUG most recently), and always about open source. I've also done crazy stuff in the past like writing a Zope 3 newsletter to let people in on all the changes when it was first being designed, and other promotional work for open source efforts.

In conclusion, though I don't share some of the more extreme opinions that some open source advocates espouse, it is a huge part of my life, and has been so for years. I hope I can keep working with and on it throughout the rest of my career. Maybe I'll even have the energy, time, and interest to work on it when I retire. :-)