= Launchpad Kanban Review =

We ran a survey with the Launchpad developpers after two months to evaluate
how this process was going. The survey was run from April 7th to April 16th, 2010.

The feedback was very positive. 90% of the developers wanted to continue with
this process.

Major improvements that Kanban brought were:

 1. having an overview of what is going on
 2. spotting and resolving blockages
 3. finding what to work on next

The thing to improve that was reported was to have Launchpad integration so
that the status of things don't have to be maintained in two places. Another
issue reported was the exclusion of the community from the overview.

Based on this feedback, we will continue the experiment and work on two-way
sync between the Kanban board and Launchpad.

Interestingly, the net promoter score for the process was +15, which means that usage of this process is likely to spread beyond Launchpad :-)


== Survey Results ==

=== 1. How much improvement do you feel Kanban brought to the following aspects of development: ===

||  || '''This is now a nightmare''' || '''Things are worse''' || '''No change''' || '''Improved things a little bit''' || '''Makes a hell of a difference''' || '''Rating Average''' ||
|| having an overview of what is going on || 0.0% (0) || 0.0% (0) || 5.0% (1) || 10.0% (2) || '''85.0% (17)''' || 2.65 ||
|| coordinating work with colleagues || 0.0% (0) || 0.0% (0) || 25.0% (5) || '''60.0% (12)''' || 15.0% (3) || 1.05 ||
|| spotting and resolving blockages || 0.0% (0) || 5.0% (1) || 5.0% (1) || '''55.0% (11)''' || 35.0% (7) || 1.55 ||
|| finding opportunity for process improvements || 0.0% (0) || 10.0% (2) || 35.0% (7) || '''40.0% (8)''' || 15.0% (3) || 0.75 ||
|| reducing the feeling of being overloaded || 0.0% (0) || 0.0% (0) || 35.0% (7) || '''40.0% (8)''' || 25.0% (5) || 1.15 ||
|| finding what to work on next || 0.0% (0) || 0.0% (0) || 20.0% (4) || '''50.0% (10)''' || 30.0% (6) || 1.40 ||
|| feeling productive || 0.0% (0) || 0.0% (0) || 30.0% (6) || '''50.0% (10)''' || 20.0% (4) || 1.10 ||

=== 2. Do you think we should continue using that process? ===


|| Ditch it || 10.0% || 2 ||
|| Keep it || 90.0% || 18 ||

=== 3. What did you find most effective in this new process? ===

  * The overview of what I am working on and what to work on next is really effective. It's also quite nice to not have to write this down in status notes every morning - moving cards around is much easier and I tend to do it during work rather than rushing it right before our daily standup call.
  * I still believe that engineers did not QA work promptly because the bug tracker does not provide a status...the state is not visible. Kanban columns show the state, so kanban is more successful. Yet some how, I think we chose to let Launchpad bug fail.
  * Making it easier to spot where the blockages are.
  * Easy overview of where things stand and where they are going.
  * Visualization.
  * Having an overview of what the team is doing at the moment.
  * It gives me the ability to see what needs doing and pull a task from the list without having to search bugs in LP.
  * Better standup meetings, less pressure to report status. It's on the board! You also get to see and learn what your team's regular responsibilities and duties are. All team members become better team managers.
  * Nice UI.
  * Quickly, easily see what others are working on. Easily see what to pull next from the queue. Satisfying feeling of making progress as I dragged my bugfixes through the process.
  * Working with lanes makes it easy to see where we're spending our efforts as a team and keeps us focused.
  * Having activities all visible and being able to see how the overall progress is going.
  * I like everything the board offers: overview of WIP, marking blockers, analytics, etc. The features that the board has are very nice and kanban for managing a team's work is a huge improvement from using Launchpad milestones.
  * Being able to spot stuff that's not moving and seeing who are the culprits who work on a lot of stuff at the same time.
  * - helps managing self and others - sharing team state internally and externally is very valuable
  * The way you can visualize the whole team progress and the lane limits. I think the limits really helped reducing the feeling of being overwhelmed and forces us to break tasks in small units that can be worked on and move on the lane faster. The QA column helps a lot on making the teams do the QA through out the cycle rather than at the end of the cycle.
  * Seeing blockages, which leads to getting QA done early and not working on too many things at once.

=== 4. What did you find the worst in this new process? ===

  * I don't like the way it excludes the community.
  * There were still a few bugs in the leankitkanban web interface, though they seem to have disappeared mostly by now.
  * Keeping bugs and blueprints and their status in two places.
  * The lack of integration with launchpad, and the manual process of moving stuff around.
  * UI is painful. System designed for a wall doesn't work on a screen. Imposes lots of constraints. Not designed for tasks that can block. Not designed for distributed teams where ability to cooperate is limited. In general, a bad fit. No cascading tasks. Constantly having to mentally recalculate dependencies between tasks because they are not visible in the UI.
  * Duplication of data.
  * Duplication of updates we also make in Launchpad.
  * The UI. Too much playful noise in the UI. I can only use it because Firefox allows me to zoom out. I don't need the thing too look like an actual whiteboard with actual cards, things need to be more abstract and compact.
  * I keep forgetting to update cards in the Kanban.
  * Non-code items for other projects, managerial responsibilities, etc. are not visible. One still needs to talk to their manager about these out-of-band responsibilities, so that your manager knows that you aren't just slow :)
  * Duplicate data entry.
  * Lots of browser/AJAX bugs that made the UI fail to function in the way it was obviously intended to sometimes. Otherwise, I really liked it.
  * Working on smaller pieces from the backlog (marginal bugs and tasks) doesn't fit quite as good (but still it's useful to have these items in the same system).
  * Creating the habit of moving the cards around, but that's my problem. :-)
  * The only complaint I have is what's missing from the board -- Launchpad integration. Sometimes a developer will toggle a bug in progress but not put a card on the board, or vice versa. Two-way sync between Launchpad and the board and this would be a perfect setup.
  * Keeping it up-to-date is hard work and an overhead.
  * - nagging people who don't find it valuable to keep things up to date - keeping my own things up to date :-) but it is pretty easy
  * No critics so far. I'm really enjoying the new process and the kanban tool. I had some glitches with the tool (e.g. drag and drop not working) but those are sorted now.
  * Updating two things for each change (bug + kanban).

=== 5. If we were to continue using this process, what changes do you think would make it more effective? ===

  * Sync Launchpad with kanban
  * More links with launchpad
  * Kill the drag and drop UI for one where cards can be moved with menus. Kill column constraints, and drive from Launchpad.
  * Buy the company and launch https://board.launchpad.net/ ;) In other words, integrate it with Launchpad a bit. For example, it would be nice if bug cards could be auto-populated with the description and assignee, and contain a usable link to the bug report.
  * We should make this integrated with Launchpad.
  * Track changes as they are made to bugs/branches in Launchpad.
  * Launchpad integration but I think you already knew that ... ;-)
  * If cards could be tied to LP bugs using the API so that I only have to change data once that would be a massive win.
  * The Kanban board software itself still needs improvement.
  * Adding items to the backlog without copying/pasting would be nice. The main conceptional difference I see between this and Launchpad is that each card represents a branch that fixes one or more bugs; therefore, the throughput isn't misleading when you are working on several trivial bugs in a single branch. All the other features could be emulated in Launchpad with bug tags and a page to display bugs in column for each tag. Actually, grouping bugs could be handled in Launchpad also by checking for branches that are linked to multiple bugs.
  * Open it to the public -- at least on a read-only basis, though I wouldn't mind finding some way to involve the community devs in a read/write way too. (In case you didn't guess, this is Karl writing :-) ).
  * It would be good to be able to link bugs in Launchpad to the cards in the kanban.
  * Launchpad integration, per previous comment. Not having LP integration is not a blocker to me supporting this process, but it sure would make life even nicer.
  * Link it to the LP API as soon as possible so it's automatic. Then it will be great!
  * I look forward to having different controls on the kanban board. In particular, I'd like to be able to control how many active cards a person has at a time.
  * When you're blocked by some other team or person, it'd be nice if that blockage could be shown on that person/team dashboard that he's blocking you. Better integration with Launchpad (i.e. If I add a bug number to a card, it could fetch the title and description from LP)
  * Some sort of integration with lp.bugs, but only if it's worth the effort - it's not such a big deal to update two things.

=== 6. How likely is it that you would recommend using a similar process to your Canonical colleagues or other developers that you know? ===

|| '''0: Not at all likely''' || '''1''' || '''2''' || '''3''' || '''4''' || '''5: Neutral''' || '''6''' || '''7 '''|| '''8''' || '''9''' || '''10: Extremely likely''' ||
|| 0.0% (0) || 0.0% (0) || 5.0% (1) || 0.0% (0) || 0.0% (0) || 5.0% (1) || 10.0% (2) || 15.0% (3) || 30.0% (6) || 20.0% (4) || 15.0% (3) ||