Wednesday, 20 February 2013

Textual description of firstImageUrl

To Mind Map or not to Mind Map

Testers love mind maps. We love them like kids love toys and kittens love balls of string. I am a great fan of the format, but I do find that as a community we have developed a tendency to use it at the exclusion of all other options. Mind maps are a fantastic way to capture information in certain contexts, and I use mind maps for a wealth of things. They are not, however, a panacea and there are situations that I've tried to unsuccessfully using mind maps to achieve certain tasks only to settle on another, more appropriate format for capuring and representing the information. I don't, for example, currently use mind maps for capturing exploratory testing activity.
Surprisingly, given that I've been using mind maps in testing for about 8 years now, I've not written specifically about my use of them. So when Lisa Crispin and Gojko Adzic independently contacted me in recent months to ask about how I use mind maps it prompted this post. I thought I'd put together a more detailed list of things that I do use mind maps for. At the same time I'll highlight what I see as some of the limitations of the format and some uses for which I have found them less appropriate:-

What are they good for

  • Capturing meeting output
  • The clue's kind of in the name here. A mind map is a really handy means of capturing and mapping collective thought processes. Occasionally I use an electronic mind mapping tool for this, although in this context most folks I work with go with a white board approach, taking photographs afterwards to capture the output. The presence of a central topic in the map helps to maintain focus and identify if the meeting is straying off topic. The map format allows each category to be explored whilst concurrently maintaining an overview of the whole picture. This allows us to link in common elements and help to identify when we are going to deep into specific areas at the exclusion of other relevant ideas. Moving to another nodes of the map can help to keep discussion at the appropriate level and can provide stimulus if ideas in another area are drying up. In my company we specifically use mind maps for capturing our elaboration meetings in which we try to establish the targets for each user story. We'll typically break the story down into areas such as targets, simple use cases, risks and any assumptions we are making about how the system needs to behave. Using colours for text and branches helps to make the map clearer, a common colour scheme I use in elaboration meetings is black for central ideas and criteria, blue for assumptions and red for risk areas.
  • Adding structure to a discussion
  • A danger that is particularly apparent in meetings with software development professionals is that focus moves too quickly to what can be achieved at the expense of really examining why it is required. On a couple of occasions where there was a risk of this I have found that drawing out a simple structure of second level branches around the main topic - Who, Why, What, How, When - can help to ensure the appropriate attention is focussed around the relevant customer and their underlying problem rather than rushing into the discussion of a solution.

    In a recent discussion on a development for a customer we'd spent some time discussing a possible technical solution before drawing out a higher level mind map, at which point we identified that the requirements around timescale and potential impact for the solution meant that what had been discussed was not workable.
  • Planning
  • Whether I am planning a talk, a blog post or a training course I generally start with a mind map. The process of adding and grouping ideas gives a great overall picture of the potential content and how it is related to the central subject. Once some logical groups are identified then it is much easier to decide what to include. One of the dangers with using a mind map to plan a talk or article is that you end up with a kind of random collection of everything that you know on the subject. I find that a great approach to avoid this is to start with a mind map to get your initial ideas down, then refine into a second diagram such as a fishbone timeline (see below) to refine your subject matter and introduce an element of flow.
  • Breaking down something confusing
  • Mind maps don't necessarily need to be persistent, in fact I find that the format is more appropriate when used as a tool for immediate understanding rather than for long term capture. The structure of hierarchical levels of branches provides an excellent structure for breaking a subject down into categories. A few times over the last couple of years I've been faced with a dauntingly complicated project or application which I was struggling to understand. Using a mind map to categorically break the system down and identify areas for individual focus allowed me to get a better picture of the system, and the scale of any task associated with it, clear in my mind. This can be particularly useful as a group activity when starting a project. Last year a group of colleagues did exactly such an exercise on a particularly complicated development. We didn't refer extensively to the model afterwards, we didn't need to. The process of breaking the task down and mapping it out had clarified matters in the heads of the group and highlighted the requisite actions in each area such that the map itself was no longer required.
  • Mapping Personal Development
  • One of the best uses that I've found for mind maps is in building incremental personal development plans for members of my team. With their personal development as a central topic we can identify second level skills that they want to work on and then build up groups of activities under each to build on their skills. Using simple iconography for priorities and whether tasks are in progress allows us to easily identify their progress and status.

All of the examples above share common elements that I think makes them particularly appropriate for mind mapping.
  • The subjects of the map involve a single central subject or event and a need to represent breakdown or categorisation of this.
  • Whether created through a single event or incrementally, in each situation the map represents a snapshot in time, there is no attempt to represent chronological events or the concept of causal relationships.
  • Probably most importantly for me, the consumer of the map in each case is the group or individual involved in its creation. It is notable that none of the uses above involve the publishing of the map to external parties

    What I don't find them so useful for

    As I mentioned at the start, there are many situations where I feel that mind maps are inappropriate. Now this might seem pretty obvious, they are a tool and so are not universally applicable. I'm not talking here about obvious inappropriate uses, such as sending a "Dear John" message. I'm talking about situations where I've tried to use mind maps thinking that they are appropriate, only to find limitations in the format have resulted in me turning to other tools to achieve what I need to:-
    • Sharing information
    • For me the main value of a mind map lies in the ability to document and/or reconstruct a mental process. In order to do this I think you needed to be part of the mental process that created the map. Viewing a mind map after the fact is like hearing about other peoples dreams or holidays, possibly interesting but lacking the relevant subjectivity to really appreciate it. In my early attempts at group based exploratory testing I attempted to share the mind maps from the sessions with the product managers. I did this as I thought it would help them to understand our thinking behind the issues that arose, but it did not work well. The feedback that I received was that the mind maps were most appropriate for review by people within the session and didn't mean much to folks who weren't there. There are exceptions of course, and some of the mind maps on testing subjects generated by Rosie Sherry at the Software Testing Club are a good counter-example. I'd suggest that for a mind map to be useful as a communication tool to others then it needs to be generated with that purpose in mind.
    • Tracking sequential activity
    • Activity that takes place in chronological streams of events including some causal relationships between events does not translate well into mind map representation. This is one of the reasons that I prefer other formats for capturing the output of explporatory testing. Exploratory testing is a sequential process where the outcome of prior events affects subsequent decisions. In not capturing the sequential nature of the information can remove some relevant context around the decisions that were made and I think that the mind map format suffers in this respect. I know that there is a requirement for building a sequence when planning talks and articles as mentioned above. There, however, I was referring to using a mind map and then refining the information to create a sequence in another format (see below), whereas it is in the capturing of the events output from a sequential process that I find them less appropriate.
    • Information with multiple categories
    • Mind maps rely on information branching out from a central subject. The format works great if you are looking at one main categorisation, however when considering multiple related categories then I find that they quickly get confusing. Just this week I was trying to do some planning around the division of our development into two teams using Xmind. I was trying to structure the testing across the teams, an operation which included people, responsibilities, resources and special interests. I found that adding individuals and responsibilities to the mind map worked well but when I tried to link the hardware needs and tie these to responsibilities the format broke down into a mess of floating topics and a mess of links.

    What are the alternatives

    It is all well and good my coming up with things that I don't find Mind Maps useful for but it is not a great deal of use without presenting some alternatives. As there are so many alternatives I've limited this list to a couple of things that I have used to specifically overcome the limitations of mind maps mentioned above.
    • Tables
    • Tables are a great way to present more structured information where there are a number of factors under consideration with fixed categories and relationships. I find a table in excel with coloured sections is a much more effective way of organising this kind of information than a mind map. In the planning task mentioned before I laid out a table of teams and hardware on each axis and then populated with the tasks that needed completing.
      I found this to be a much easier and more logical representation of the information for this task.
    • Fishbone Diagrams
    • Also known as Ishikawa diagrams, this format is much more appropriate for mapping causal relationships. The purpose of the fishbone is to identify the causal factors that resulted in a specific event. Whilst the original format was specific in terms of the categories applied to the diagram. Some folks have subsequently applied the structure more loosely and even reversed the format to target a result and the factors that can help achieve it, typically referred to as a "reverse fishbone". I don't tend to use the fishbone diagram in its original form, however Xmind use much the same format for their "timeline" diagram
      which I find really useful to refine and structure a talk as a follow up to an initial mind map to capture ideas - an example of this approach can be seen in my preparation for EuroStar 2011
    • A Wiki
    • Whilst on the face of it a completely different use case, I think that the inclusion of a wiki is valid in this list. Where a mind map is not a great means to share information, a wiki is for this exact purpose. Turning the ideas captured in your mind map into a well structured wiki page makes them digestible for others and also searchable for folks wanting to research the subject later.
    • Your Own Voice
    • Mind maps are a great way of organising your ideas. There is still, in my opinion, no better way of presenting your ideas than in your own words. Ideally in a conversation or possibly via email or other media, I find that well chosen words to be the most effective way of sharing our thoughts. The use of a mind map comes in organising these thoughts to allow us to present our ideas with clarity and structure.

    Further reading

    I hope that this post has given some food for thought on appropriate and inappropriate uses of mind maps. Here are a couple of useful resources on the subject for anyone wanting to explore the format:
    • Whilst the format was used previously, Tony Buzan really pioneered the concept of mind maps and has software (iMindMap) and training on The 'Who, What, Where, Why image in this post was generated from iMindMap
    • Darren MacMillan's excellent Mind Mapping 101 is a must read for anyone thinking of using mind maps in testing
    • Gojko Adzic has an interesting "zero friction" mind map tool development in MindMup which looks to be an exciting addition to the mind mapping arena.
    • My tool of choice for Mind Mapping electronically is XMind. It has a really intuitive keyboard shortcuts which allow rapid map generation, plus very simple addition of icons, if being a little limited on choices of colour and layout. Most mind map images on this post were generated using Xmind.