Coloured lists in Trello

Background colours on selected lists in Trello

Background colours on selected lists in Trello

As you probably know, we’re big fans of Trello here in the web team.

We have a number of project boards, overseen by one master, everything-we’re-doing™ board called @Web team. It currently has 24 columns (or lists) which makes quickly navigating to the right list a little tricky at times.

So today I quickly wrote a hacky little Tampermonkey (Chrome) / Greasemonkey (Firefox) script to add background colours to certain lists.

For colours, I simply selected an at-random theme from Adobe Kuler.

It could be optimised but it does what I need to without too much of a performance hit, and already I’ve found it really helpful to immediately identify the “in progress”, “this week” and “done” columns, as well as marking our project backlog columns.

// ==UserScript==
// @name Web team - Trello highlight lists
// @description Highlight certain columns in Trello.
// @include https://trello.com/b/YOUR-BOARD-URL
// @require https://code.jquery.com/jquery-1.11.0.min.js
// @version 2.1
// @copyright 2014, Gareth J M Saunders
// ==/UserScript==

$(document).ready(function() {

var black = '#393939',
brown = '#a39386',
green = '#a8C0aa',
red = '#a7585b',
white = '#fff';

$('body').hover(function() {
$("h2:contains('PROJECTS'), h2:contains('TEAM ADMIN')").css('color', black).parents('.list').css('background', brown);
$("h2:contains('IN PROGRESS')").css('color', black).parents('.list').css('background', green);
$("h2:contains('THIS')").css('color', white).parents('.list').css('background', red);
$("h2:contains('DONE')").css('color', white).parents('.list').css('background', black);
});
});

Please feel free to use it, adapt it, improve it, comment on this.

Obviously, change the ‘contains:’ keywords to find your own list headings, and the @include URL to that of your board.

Update

  • I noticed that I was trying to pull in the jQuery file under http rather than https, which was causing problems.
  • It turns out that the DOM loads long before the content, as there is some Ajax jiggery-pokery going on. So I’m using a hover event on the body to force the colours to change, which is a horrible hack but works, and does also pick up new lists created with these keywords.
  • 2014-12-08 I’ve discovered that rather than // @include https://trello.com/b/YOUR-BOARD-URL, I can use // @match //trello.com/* which will then work across all my Trello boards and follows the protocol of the board being viewed (which seems to always be https:// for me).

To do

  1. Use arrays and or variables to store common colours.
  2. Improve the event handling to determine the best way to load the script.
  3. Reduce duplication with regards to identifying the column (h2:contains gets repeated a lot) and adding the CSS rules.

Drop the assumptions, re-frame the question

More than two years ago, on 7 November 2011, I created a new card on our Trello board called “Fix memos on internal homepages”.

It then sat on the board for the next 24 months, and was not touched, apart from to shuffled around the board a bit, from one list to another: from ‘backlog’ to ‘this week’ to ‘backlog’ to ‘known issues’ to ‘backlog’ to ‘bugs’ to ‘known issues’ to ‘backlog’ before it was finally scheduled to be done four weeks ago, three weeks ago, two weeks ago, one week ago… this week.

In the end it only took about 30 minutes to fix!

The issue

The issue in question was this: if a user visited the current staff, current students’ or current postgraduates’ homepage (and a few other school websites) under a secure connection (https) then they were not able to read the memos or events. Instead, they were served an error message, e.g.

An error has occurred fetching the memos.

An error has occurred fetching the memos.

The problem

The problem wasn’t affecting too many people, either. We would maybe receive one complaint about it every six months, so there was no urgency. But we considered it a significant issue to keep it on the board. For two years.

The reason that nobody fixed the issue was, I suspect, two-fold:

  1. Fear
  2. Prejudice

Fear

We feared that this problem would be very complicated and time-consuming to fix. Our fear led to inaction.

It sounds like it should be a complicated thing.

It sounds like we should need to know exactly what happens at both the server and browser levels when content is served using Hypertext Transfer Protocol Secure (HTTPS) compared with a non-secure communication.

It sounds like we may need to delve into server configurations or look up obscure chapters in books about PHP security to figure it out.

We didn’t.

Prejudice

Each time we discussed that card (as we shuffled it around the board trying to settle on the best list on which to ignore it) we spoke vaguely about what we suspected we needed to do, rather than simply stating the problem we were experiencing.

We always spoke about this incident with a particular solution in mind. And that solution was one that had emerged from our fearful speculation rather than simply stating the facts about the problem.

“Oh, that’s the problem where we have to force the pages to be loaded as http rather than https, isn’t it?”

And we would all agree.

“We’re going to have to do that using either .htaccess or PHP, aren’t we?” someone would continue.

And we’d all agree.

But we were wrong.

Drop the assumptions, re-frame the question

At the start of the week, I volunteered to look at this card.

I already had our pre-conceived idea at the ready and so I immediately spent a couple of hours reading up on forcing https pages to reload as http using .htaccess files.

“Boy this looks complicated!” I thought. “Surely there’s an easier way.”

And it was only at that point that I suddenly realised what I was doing. Or rather what I wasn’t doing. I wasn’t considering the actual problem itself; I was leaping straight to a solution.

The problem wasn’t that these pages weren’t forcing the page to be loaded under http, it was that the memos and events wouldn’t displayed if the pages were loaded under https. That’s a whole different issue.

I rewrote the ticket in Trello to reflect this: “Allow memos and events to be viewed under https“.

I then wrote myself an Agile-style story:

  • As a member of staff…
  • When visiting the staff homepage under an https connection…
  • I would like to view the events and memos, rather than an error message.

And it was at this point that I suddenly realised what the root cause of the issue was: the browsers were not pulling in the events and memos because they were hard-coded in the PHP and JavaScript files to be served under http.

So I changed these to protocol relative URLs.

Now, rather than referencing http://www.st-andrews.ac.uk/my-file.php I changed this to read //www.st-andrews.ac.uk/my-file.php so that the browser uses whichever protocol it’s currently receiving (see section 4.2 of RFC 3986 Uniform Resource Identifier (URI): Generic Syntax for details.)

And like I said, it took me about 30 minutes to update all six pages that were affected.

The lesson for next time: drop the assumptions, re-frame the question. Perhaps the answer is more simple than you first thought.

Trello now has a calendar view

Trello now with added calendar

Trello now with added calendar

It’s no secret that we are big fans of Trello here.

A fabulous feature they added in August—which may make the tool more useful to some people—is the addition of a calendar view.

For as long as I can remember, Trello has always had the ability to set due-dates on cards. These dates turn orange when the due date is near, and red when it has past. A useful visual cue. But now being able to view cards’ due dates by week or month in this new calendar view is tremendously helpful.

It’s been really well thought out too:

  • You can drag and drop cards from one date to the next to change the due date.
  • New cards can be added directly to the calendar.
  • Dates with more than one card clearly show you there are more cards, which appear in a small, scrollable pop-up window when you click on them

If you’ve not already, then sign up for Trello. It’s a really useful, flexible tool to tracking just about anything.

Trello at St Andrews

At the meeting of the Scottish Web Folk, on Thursday 31 May held at the University of Edinburgh, I gave the above presentation about Trello from Fog Creek Software.

Trello is, according to its own help text,

a collaboration tool that organizes your projects into boards. In one glance, Trello tells you what’s being worked on, who’s working on what, and where something is in a process.

We’ve been using it since December 2011 within the web team at the University of St Andrews and are finding it really useful.

Summary of presentation

The first part of the presentation outlines something of our journey from a team of two members to (hopefully) six by the end of 2012. As our project backlog grew we knew that we needed to manage projects and tasks more collaboratively, to get details out of people’s heads and into a centralised tool.

We started to adopt Agile practices in 2008 which led to us creating a scrum board in the office. But in September 2012 Steve, our Web Manager, broke his foot and when he returned to working from home in December we knew that we needed to move the board online.

We had checked out a number of online, free and hosted applications such as Basecamp, Pivotal Tracker and Jira. However, Trello proved to be for us the perfect match.

The second part of the presentation takes a quick tour through the Trello interface and how it works.

The last part of the presentation involved a hands-on demo of the software. I’ve replaced this with two simple slides representing the two ways that we use Trello.

  1. We have one board called “Web team” which tracks the big picture: project requests, current projects being worked on, know issues, admin tasks, backlog of tasks, etc.
  2. Then we have multiple project boards, one for each project. These have a standard number of columns (backlog, in progress, waiting for, testing, done) and the labels (new feature, enhancement, PHP/JavaScript, bug, documentation, web team admin) are the same across every project.

If you have any questions or observations please leave a comment below or email me directly (gareth.saunders@st-andrews.ac.uk).

Note: this article was also posted to the Scottish Web Folk blog.

Moving our team task board online to Trello

20111104-taskboard

For the last few years the Web team have been using, and adapting, a form of Agile/Kanban board to manage what tasks need to be done and by whom. It has served us very well, but this week we moved it online to Trello, a free, hosted service from Fog Creek Software.

Why we went digital

When we started using the board the Web team consisted of three people: Steve the Web Manager, me (Gareth) the Assistant Web Manager, and Chris the Web software developer.

We all sat in the same room together, and the board was just a few steps away from our desks. It was handy, and quick, and accessibly. But as the team has grown we’ve now spilled out into an office on another floor of the same building.

It’s not quite so easy now for all five members of the team to add to or move tickets around the board. Occasionally some of us work from home too.

The main catalyst, however, was in response to a recent crisis in which our intrepid leader, Steve, fell of a ladder and broke his foot (you can see photos of his recent x-rays on TwitPic). He could be working from home for some time now and we wanted to make him feel included so we moved to Trello.

Trello

20111104-trello

It was pretty painless to set up and add users to our newly created organisation and board. I then spent a couple of hours migrating our open tickets over from the whiteboard into Trello.

Labelling and assigning tasks to users was simple thanks to Trello’s excellent keyboard shortcuts.

I did wonder if I’d miss physically moving cards from one column to the next, but Trello has a neat little trick whereby when you ‘pick up’ a card it rotates it a little to indicate that it’s been picked-up. It’s really effective and surprisingly satisfying:

20111104-trellomove

We’ve decided to trial working with Trello for a few months, certainly while Steve is recovering and may have to work from home.

So far the response from the rest of the team has been very positive (after we switched off email notifications). It’s attractive, it’s simple and it’s intuitive. No doubt we’ll report back in a few months with our thoughts on how the move from analogue to digital has gone.

Our journey into Agile, pt.2

Encountering Agile

Back in April 2008 I attended the Scotland on Rails 2008 conference in Edinburgh; I literally have the t-shirt to prove it.  It was an absolutely fascinating (read: über-geeky) conference let down for me slightly by the fact that I really didn’t have a clue what they were talking about most of the time as I had only just begun to explore Ruby on Rails.

It really was the most hardcore conference that I’ve ever attended. Most of what was said went way over my head as the speakers went into minute details about which new functions were available in Ruby 1.9 (does Ruby even have functions?! See: not a clue!), advanced class design, and there was even a talk called “Bonus Erlang Session”.  That could be the name of an experimental band from Germany for all I know.

But there were a couple of things that I really enjoyed, one was the keynote speech by David Black which was just inspirational (check it out on iTunes, it’s called The Flying non-Scotsman: or, My thirty-two year trip from the Borders to Edinburgh), the other was the number of speakers who kept talking about BDD (Behaviour Driven Development), SDD (Story Driven Development) and Agile.

 

The Art of Agile Development

The Art of Agile Development by James Shore and Shane Warden

 

O’Reilly had a book stall at the conference with a 10% discount.  So I bought this book: The Art of Agile Development by James Shore and Shane Warden.  It’s a great book that gave me a thorough grounding in Agile and XP practices and processes.  I thoroughly recommend it.

Planning poker

Fast forward a year and a half to December 2009 and there we were, a rather broken-looking Web team sitting around a table in Web HQ staring at a spreadsheet listing over 120 requested projects.

In The Art of Agile Development the authors write

XP assumes that customers have the most information about value: what best serves the organization. Programmers have the most information about costs: what it will take to implement and maintain those features… A successful plan needs to take into account information from both groups, as every decision to do something is also a decision not to do something else.

Taking that to heart, that we had the most information about costs, we sat down over two days and played planning poker using home-made cards with the list of projects.

Agile planning poker cards (PDF, 24.5 KB)

Planning poker (or the ‘planning game’) is normally used by teams to estimate individual tasks in a larger project, but we used it to estimate the size of projects themselves.

We looked at each project one-by-one on the list. Whoever knew what it was about would explain it to the rest of the group, something like

Okay, so this project is about replacing the virtual tour movies on the website, which are currently QuickTime movies, with the same movies but in Flash format.

Once we had enough detail we would silently vote on the complexity of the project.  We used homemade cards (you can download them above) using a sequence that was loosely based on the Fibonacci numbers.  Our cards used 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ? and Break.

Each player would select a card and then at the same time everyone would lay their cards out on the table.  We were looking for a consensus of opinion.  As I was facilitating the process I would invite whoever laid down both the lowest and the highest values and ask why they scored it that way.

That’s where the real value in the process came in.  It gave everyone an opportunity to speak about every project.

Someone who scored it low might say something like:

“Well, I scored it a 2 because I’ve done this before and it was really easy. We just need the source Flash files and then we already have a media template for Flash movies so it’ll take no time at all”

Then the person who scored it more highly might offer something like:

“See, I gave it a 20 because it’s not as straight forward as it initially looks for a couple of reasons.  We do have a media template for Flash movies but it doesn’t allow us to embed multiple movies on the page. And then there is the issue about lack of Flash support for iPhones and iPads.  Should we be thinking about going down the HTML5 path?”

Having heard the evidence we would vote again until we had a consensus.  Sometimes we would end up with three 13s and one 20, for example, in which case I would ask the person who scored it 20 if he was happy for it to be given a score of 13 or if he felt very strongly about the 20.

It was a really useful exercise.

By the end of the two days we still had a list of 120+ projects but each project now had a value indicating how difficult or complicated we reckoned each one was.

Prioritization

We took this list to our boss and she prioritized them, according to the factors that she was aware of and how they fitted in with wider University priorities and projects. P5 was high, P1 was low.  Over 20 projects got binned straight away.

By the end of day three we now had a list of just under 100 projects but we now knew the approximate size or complexity and their priority.  The project list didn’t feel quite so daunting. We also, crucially, had the commitment from our boss that all new project requests should first go to her.

We then used this list to start disengaging from and postponing half- (or hardly-) completely projects that had a low priority.  Most people, to be honest, were very understanding.

Next post I’ll finish this series by explaining how we broke down our projects, what we’re doing now and where we’re hoping to go.  I’ll also take a look at Agile tools that we’re using.

Our journey into Agile, pt.1

Scrum sprint

Diagram of a Scrum sprint, taken from Scrum in five minutes from Softhouse

In November of last year (2009 if you don’t have a calendar to hand) we started to seriously look into using Agile methodologies to better manage and run our Web projects.
The crunch came when we realised that in many cases we weren’t delivering what we had promised to do, we were snowed under.  We took a day out to evaluate where we were and to our horror we discovered that we

  1. were working on over 20 projects concurrently.
  2. were not moving very quickly on any of them.
  3. had a backlog of over 120 projects, which we estimated would take around 13 years to complete if things continued as they had been going.

Something had to change.  We had to change.  We needed to stop saying yes to everyone about everything and we needed to find a way to more efficiently and effectively plan and manage our projects.

Agile

That’s when we turned to Agile for assistance.

Agile software development is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams

Definition of Agile from Wikipedia

Agile is something that we’d looked into a couple of times in the past. It struck a chord with us: iterative, incremental development was something that we did anyway.  We often practiced pair programming, we were using something akin to a Scrum task board, we had a daily stand-up meeting each morning, at times we would have ‘customers’ sit with us to iteratively work through a design.

Simply adopting certain methodologies doesn’t make you Agile though, but it was a good start. Iterative and incremental, if you like.

Almost Agile, even.

Oh, hang on …

Multiple projects

One of the things that we struggled with most was how to run multiple projects using Agile. Because everything we read talked about the importance of running only one project at a time.  Everyone that I spoke to from commerce or business about it stressed the importance of running only one project at a time, and everyone from higher education I spoke to stressed how impossible it was to run only one project a time.

Then I discovered this paper from Karl Scotland, formerly Development Team Leader at BBC Interactive: Agile planning with a multi-customer, multi-project, multi-discipline team (DOC, 225 KB) who gave me the confidence that it could work. In this conclusion he wrote:

The team is able to manage the various complexities of multiple customers, projects and disciplines by working in a way which allows them to treat the work as if there were only a single customer, project and discipline.  Thus they work on a single pool of stories which are shared by all the different customers, projects and disciplines.

So we could run more than project at a time, if we were careful.  We got planning.

Next week I’ll explain what we did next…