You are currently browsing the monthly archive for March 2010.
A few months ago I was asked to build a taxonomy for a new wiki portal for informal learning. The portal was to be an authoritative source of information, knowledge and wisdom for the practioners of our flavor of the Agile software development process.
For content research, I had access to an existing wiki portal which had developed and grown organically. The existing portal was open, and anyone could add, delete or comment on any page. It included a preliminary glossary of Agile terms, consultant documents, team home pages, and much more. Our user research revealed that many learners hesitated to go to the existing portal for information because it was hard to navigate, inconsistent in nomenclature and definitions of terms, and because their feeds showed them that the portal information changed almost every day, every time someone added something new to it. How can a portal be trusted as a source of truth when it keeps changing? some asked. However, it is the nature of the Agile process to be…well, Agile.
Nonetheless, I needed to find out what were the main buckets into which our learners tended to cognitively toss different aspects of their Agile work.
I began by creating my own high-level categories for the taxonomy, by analyzing what I had seen on the exiting portal. I used Google Analytics, ethnographic field studies (talking to people around the office), and my own thought processes, to come up with this first list of category names:
- Key Agile concepts
- Processes/phases of Agile
- Agile tools
- Roles and responsibilities
- Job aids
Then, under each category name, I listed Agile-related terms used on the existing portal, and in the literature of Agile. Then I removed the buckets, and listed all of those terms alphabetically. I had about a hundred terms. The terms were evaluated by several subject matter experts. A few terms were removed as being unimportant to the process, and a few terms were added.
Our internal usability person, let’s call her Grace, conducted five in-person interviews with a people from different teams and with different levels of Agile expertise. She wanted to see what the gaps in knowledge were.
Next, Grace set up a twenty-minute test on WebSort, an online card sorting tool.
Grace emailed an encouraging email to selected respondents, and gave them a deadline. After the date had passed, I walked around the company and visited the people who had not yet completed the test, and invited them to do so.
The test instructions asked respondents to sort my list of 100 terms into categories, and give each category a name.
After the results were in, we analyzed them. Our respondents agreed strongly on certain items being grouped together. Some of their categories matched mine closely, while others didn’t match my groupings at all. The respondents were fuzzy, disagreed, or lacked knowledge around how to group some Agile terms, however. This was useful information to pass on to the people in charge of Agile learning in general.
Grace created a spreadsheet which conveyed our key findings, which we shared with the people who had asked me to do create the taxonomy. We hammered out definitions for some of the terms where our respondents had had disagreed, or just plain didn’t know what to say, so that we were clear about the meanings of most of the key terms.
After we had discussed what we saw, I locked myself in a small room with my laptop and a supply of Diet Cokes. Some time later, I emerged with an eight-page outline numbered taxonomy. This was basically a content outline for the portal, which also could serve as a framework for developing a training program for new developers. My main content buckets did not match what I had started with, nor did they match exactly what the card sort respondents had given me, but that had all been good fuel to create a taxonomy that I felt would be very useful.
While I was at it, I created a rough draft of a glossary which was an attempt to capture all the term definitions I had gained an understanding of over the past several weeks. I also provided a sitemap and a wireframe which showed a homepage structure for the new portal. One of my top recommendations was that one specific person be presented in the role of “Agile authority” on the portal home page. Another recommendation was that some key pages on the portal be locked down, and that only the “authority” could make changes to them, with the caveat that as our Agile process evolved, Mr. Authority would have to update those pages in a timely way, or else risk losing credibility again. Much of the existing portal content could be repurposed but some new content needed to be written, and so two tech writers were added to the project. One of the Agile implementation team members took over the task of actually building the portal, which is looking slick in our Confluence Wiki. They are all still at work, but they have done an awesome job of adhering to the spirit of my taxonomy, while adding their own enhancements.
Now, that’s Agile.
Tim found his childhood bike in his dad's woods
Time travel has always been an implicit function of media.
A book gives us tangible access to the past, present and future. The way in which a book is constructed reflects the way we Westerners view time. For we consider time to be an arrow targeting the future, which in our culture is in the right-hand direction; while the past is the shaft of the arrow to our left.
While reading a page of a book, or any print media, I am always in the present on the page I am reading, yet I have ready access to both the past (pages I have already read) and the future (pages I have not yet read). In fact, I hold past, present and future in my very hands. I can feel the weight and heft of the book and can even see the edges of the pages. I can easily and quickly see any page I want to see.
On the other hand, the browser, the electronic book reader, and the web application tend to extend the duration of the present moment. These offer the promise of time travel, but haphazardly deliver. A dead battery, a failed connection, the wrong password, and you are trapped in the present and cannot do anything about it. It’s like listening to a public speaker with a stammer. In attempting to surf on a wave of information, one experiences not simply a gap, but an expectation that is not filled, creating an unpleasant experience of duration, leading to frustration.
The sense is one of being trapped in the present time, poised to move forward, but stymied.
When we go “back”, we don’t really go back in time. We’ve gone into the future by reading history.
The real problem, however, is that applications and sites are currently architected and designed according to the “time as arrow” paradigm, whereas folks in general are moving rapidly towards a “simultaneous time” state of mind. For how we live in time is a mass hallucination, which, like all forms of information, evolves. But that’s another story.
Sometimes when I draw a Rich Picture, I will use the term “soft information”.
“Hard information” includes verifiable data and knowledge.
So, soft information includes feelings, perceptions, opinions, values—which are often the key to project success or failure. For example, with a project I am currently working on, four information architects are working together in a team, with their manager. Here’s some soft information about our project:
- Our manager seems to value getting some concept wireframes done fast.
- It seems like all the team members value understanding the nuances of the big picture, doing a competitive analysis, a gap analysis, etc. etc., before creating concept wireframes.
- One of the team members has feelings around the fact that he’s going skiing for a week right in the middle of this project.
- For my part, I’m excited about the work but I perceive that our stakeholders may be a shifting group, so I’m a little apprehensive about which direction to take with my work.
- The company values the Agile method.
- One of our stakeholders is of the opinion that we should be conservative in our concepts.
You get the idea. These feelings, perceptions, opinions and values are pretty important to the project. Yet typically, when putting together a list of project parameters, these kinds of soft information are disregarded, or not even noticed in the first place.
It’s the mix of the hard and soft information that puts the “rich” in Rich Picture.
In case you missed my recent post on the subject, a Rich Picture is a cartoon-like diagram which you can draw in order to:
- find out about the problem situation
- create a preliminary mental model of the situation.
Usually, when I draw a Rich Picture, I’m the only one who ever sees it — because they are messy and too hard to explain. Occasionally I’ll show my Rich Picture to other team members, if I’ve cleaned it up enough for public consumption. Once in awhile I’ve drawn a Rich Picture on the whiteboard in a team meeting, to walk a team through my mental processes as a begin a new project.
I use the menomic “COW TEA” to help myself remember the elements of a Rich Picture.
C: Customers or users: the people who will use the system you are making
O: Owner(s), the person(s) with the power to make approvals or cancel actions
W: World view, or some kind of overall perspective on the project
T: Transformation of inputs into outputs, the core activity, or the primary change to be brought about. In other words, “We are going to build a system to <x>”
E: Environment, or factors which impact the project, such as time and resources
A: Actors, or performers of tasks on the project
Peter Checkland introduced the concept of the Rich Picture in 1981 in his book Systems Thinking, Systems Practice, the textbook on his soft systems approach to creating solutions to human problems.
Donald R. Woods, professor emeritus of chemical engineering at McMaster University, has done quite a lot of research into what different MBTI types consider to be good exam questions. Don is perhaps most widely known as a pioneer of McMaster’s distinctive learning strategies: inquiry and problem-based learning. I ran across a reference to his article, Models for Learning and How They’re Connected–Relating Bloom, Jung, and Perry, which was published in the Journal of College Science Teaching, v22, n4 p250-54, Feb. 1993. After spending half an hour hunting around on ERIC and in various university libraries, I could not find a source, so I dug up his email address on the internet and just contacted him directly.
I’m working with the learning aspects of our travel web site. I was interested to know how to correlate MBTI types to the levels on Bloom’s Taxonomy . I had the idea of associating the categories I came up with to differences in the types of questions people might have when they come to the web site.
Don promptly responded with helpful information.
Sensing/Thinking (ST), which is 30% of the US population, includes ISTP, ESTP, ESTJ, and ISTJ. They ask questions on the Knowledge/Remember level of Bloom’s taxonomy. Questions like, What does it cost to check a bag? What is an e-ticket?
Intuiting/thinking (NT), which is 10.4% of the US population, includes ENTJ, INTJ, ENTP, and INTP. They want to Understand (Bloom’s second level), and appreciate questions that ask them to compare and contrast.
Intuiting/Feeling (NF), which is 16.3% of the US population, prefer Evaluation questions (what if?)
Most interesting to me is the Sensing/Feeling group, which comprises 43.4% of the US population. They want to know, “How would I feel if…?” and this is not usually the type of question that is addressed in a scholastic exam or on a travel web site:
- How would I feel if I choose this trip A compared with trip B?
- Would I be at ease in this hotel room?
- Would I be happy if I choose this car?
- How comfortable would I feel if I choose this airline seat?
However, the use of sensory information such as rich media, video, sound, images, diagrams and visualizations of data speaks powerfully to this type of sensing/feeling person, which, if you give credence to this type of analysis, comprises a huge chunk of any potential audience of learners.
