Checklists
Checklists have a somewhat bad reputation in the Agile world, probably because they “smell” of too little self-organisation and too much process. I find this reputation is entirely undeserved as they can be extremely useful as a memory aid, or to visualize a workflow.
Checklists play an important role in areas where missing steps can have disastrous consequences, such as in hospitals or airplanes; or in situations where people are likely to forget individual steps, such as when they’re stressed and tired; or while learning a new process or way of working.
At work we mainly use checklists when we want to introduce a new workflow and need to make sure we don’t forget about the process or any of its steps.
Here’s an example of our checklist for the sprint workflow and working with user stories:
We usually keep our checklists visible until the new workflow has become second nature and we don’t need reminders or memory aids anymore. Although, in saying that I realize that we created this particular checklist 6 months ago and we still like to have it around :-)
For us checklists are a very useful learning aid and workflow visualization tool, and as long as we decide on the processes ourselves we don’t feel they interfere with our self-organisaton.
Visual Workspaces: Kanban for One
One of the things that immediately caught on when we started our journey towards being Agile at Snapper was the use of visual workspaces. The team loved the sense of achievement of moving a task from "In Progress" to "Done" and found the board helped them stay focused and co-ordinated. Everyone from team member to operations to management appreciated the level of visibility and transparency. Even my partner's 11-year old daughter thought my work place was the coolest ever as we had covered the walls in colourful sticky notes and Simpsons characters
This, in combination with my constant rant against excessive multi-tasking, too much work in progress and finishing one thing before starting the next seemed to have struck a chord with Gina, our designer, who started a "Kanban-for-One" movement at the office.
The “Kanban for One” board
The board, at Snapper known as “a Gina board” is used to organise personal tasks. The standard workflow is “Backlog” (stuff I want to/have to do), “Queue” (the subset of the Backlog that’s up to be worked on next), “In Progress” and “Done”.
The limited space for each of those workflow states imposes a natural limit on the number of items in each state, e.g. no more than 4 stickies fit into the “In Progress” area and getting more than 8 items into your “Queue” column is impossible. The lowest area on the board is either used as an expedite lane or for little inspirational messages and reminders.
The creator
Gina is the proud inventor of the Snapper Agile board. Unfortunately she has the least visually appealing board as she is stuck with an early version that had not received the benefit of several iterations of learning.
Spreading like a rash
Since people can place orders with Gina they’re spreading like a rash through our office.
Andrew with a board full of marketing tasks.
Sean, Head of Product, and obviously obsessed with the alignment of stickies.
The Product Owner’s wall
Reminders and ground rules on Gina’s board. I’m a bit confused about the haircuts though.
The Office
Conclusion
Apart from our team Scrum wall more and more people have or have ordered personal Kanban boards to supplement the team view with individual task management. We really like the boards to keep ourselves organized, protect ourselves from the temptations of multitasking and to communicate to the rest of Snapper what we’re working on.
Some people are combining the personal Kanban boards with the Pomodoro technique which seems to work really well too.
To read more about this topic read Courtney’s excellent post “Adapting Agile’s visible workspaces to the humble to-do list” over at Boost.
Tools - the new kid on the block
Mingle has received a fair bit of attention lately and the latest version, 2.1, has just been released.
I’m quite happy with Rallydev but as Mingle is made by Thoughtworks themselves and the guys at Silverstripe keep raving about it I thought I’d better check it out. Also, as much as I like Rallydev and VersionOne - they’re both a bit weak on the usability side.
Below a list of what I like and dislike about Mingle:
Things I like:
1. Installation & Support
- Free web/phone conference with a Mingle representative to guide you through configuring the system after you have received a free hosted trial. Very helpful!
- A breeze to install the downloadable version
- Runs on all operating systems (incl. Max OSX, Linux and Open Solaris) and most database systems incl. Postgres
- It just looks nice and appealing
- Tasks can be completed with relatively few mouse clicks
- If you choose the scrum template the card hierarchy of sprints - stories - tasks is very intuitive and standard scrum
- You can create epics for your product backlog
- Given you’re willing to spend enough time playing with configuration settings and are inclined to learn Mingle’s proprietary SQL-like language you can configure the tool to fit exactly your needs. Hell, you could probably even extend their JRuby ;-)
- Mingle contains a fully fledged wiki - great for sharing project information!
- All reports are configurable on the wiki
- As expected, very easily done from Excel (For switchers it’d be great to have an automated import/export to/from Rallydev and VersionOne)
- Great that it lets you preview your import before starting the actual import.
Things I don’t like:
1. Concept of cards for everything
- Representing everything as cards is confusing: It does make sense for user stories, which in the physical world are written on story cards but using cards for releases, sprints and tasks seems forced and non-intuitive
- I don’t want to fit my mental models around a tool - it should be the other way around! Scrum concepts such as sprints and releases are a bad fit for Mingle’s generic object model of cards
- I miss the nice overview I have in Rallydev where I can see all my release and sprint dates
- Card trees fill quite a big part of the screen and it’s hard to get an overview at a glance (There’s another, smaller view but it doesn’t show the relations very well)
- Sprints and releases don’t have fields for start and end dates (I can add them myself by configuring cards but not adding them by default seems odd)
- There seems to be no standard way of getting started with a project quickly. There is no step by step process to quickly set up your releases, sprints, product backlog and user stories. Unlike Rallydev which guides you through with a pre-defined process and video documentation Mingle makes you figure it out for yourself.
- Mingle expects you to invest a considerable amount of time learning how to configure the system and how to make it work for you.
- There is no free SAAS version available (By comparison Rally Community edition is free for up to 10 users and Version One’s team edition provides similar functionality for free)
- Hosting Mingle on your own server is free for up to 5 users but I don’t want to wast my time installing tools and maintaining a server.
- The hosted trial for one project is great but only being allowed to keep the instance for 2-3 week is not enough for me to try Mingle on a real project and to make a decision to move all my projects from Rally or VersionOne
Overall, this is a promising tool with an attractive user interface.
It is nice that the tool is extensively configurable but it is way too time intensive to set up. The point is that even though I can configure everything I don’t want to: I just want to get going quickly with 80% of what I need and focus on getting my projects done. Spending time on configuring a tool seems like a waste of time.
As Mingle still seems a bit rough around the edges and does not provide a killer feature that would justify the hassle, learning curve and additional licensing cost I won’t switch from Rallydev this time.
I’ll definitely keep an eye on future releases though!