There are quite many posts on visualization in our Edge of Chaos blog. While we haven’t emphasized the difference between visualizing data and visualizing information, mostly, there is still one between those two. Without delving into any greater depths of theory, one can assume that data visualization is more closely related to quantitative data. This means that figures rendered into a visually clear form make sense faster as compared to when one looks at figures only. Today I’d like to give a few examples of using visuals (namely, mind maps) as an aide in the cognitive processes of research and problem-solving; I will also share some thoughts on when mind maps work at their best to amplify cognition.
Mind maps are often used to put together concepts related to a certain problem. These visuals help to get to the core of a problem or a phenomenon that we explore. When we link concepts in a network, things seem to make more sense to us, and the process of binding those nodes somehow helps to bind pieces together in our heads. The following mind map represents a case of digging to root causes of a problem (problem-solving):
Another case of using a mind map visual is to make a summary of some information that one has already digested. A mind map conceptualizes this knowledge putting it into various perspectives. As learners and researchers, we often feel the need to re-arrange some previously acquired ideas based on our own thinking, to shuffle and to categorize them in some new ways. This mind map was used to write the Patterns for Information Visualization article:
The next example looks as a mind map on the surface, but in essence it’s not exactly that. Technically it is a mind map, as it consists of some nodes linked together. Such a visual, however, would seem more appropriate if drawn at a group meeting with people discussing the dynamics of their team work. We can say that this visual facilitates a group discussion:
Here’s another example of a mind map that could have been used as a graphic facilitation when discussing Scrum process:
It depends a lot on the personal preferences and the context whether a mind map would help to amplify cognition. For example, the team reflection and the Scrum process visuals might work better at a group discussion or in a conversation. It’s cool when a person that runs a meeting draws such images in the process of speaking, as the others look at the funny images, share a laugh and put their cognitive abilities to a better use through this distraction. As a solo researcher, one might draw such images automatically, focusing on the problem and thinking deeper.
Summing up, mind maps work well for an advanced solo research and problem-solving as people make graphic sketches in the process of thinking. They also work well for group meetings to facilitate discussions related to some common context, in a shared space. However, mind maps do NOT work well when someone totally new to a subject area hopes to learn all and everything from a mind map sketched by someone else. Depending on how new the student is to this subject, the mind map might make no sense to them at all, or it will just give them a general idea, at best.
It wouldn’t be an exaggeration to say that posts on daily stand-up meetings take a top standing (*pun intended*) among the blogs related to Scrum. Looks like I’m ready to put my two cents in as well.
When researching on some practice, I first look if there are any meaningful clues in its name. According to the classical definition, daily stand-up meetings are held with people in upright standing position for the reason that looks quite ridiculous: discomfort of standing for too long is supposed to keep the meetings short. Hmm… If there’s no other motive to keep the meetings short, rather than the urge to get seated faster, something must be missing in the whole concept of daily stand-ups. It means they can get so boring, that people would lose focus even in less than 5-10 minutes. Most likely, they would have trouble focusing on what the others are saying, because it’s in no way related to their current work (or related remotely). As a consequence of this boredom, the team skip preparation for the stand-ups since they know that it’s a formal thing, and sometimes all they have to share with the others is: “I was digging into some bugs, looking how to fix them, will go on with that today as well”. No commitments are made, and the same status updates are delivered for several days in a row.
All of the above are surefire signs that your daily stand-up meetings need a serious health check. If people go with the formal “what” (I’m doing), “how” (I’m progressing with my task), and “when” (will I complete the task), and this seems to be of no interest to everyone present at the stand-up, then it’s time to question the “who” (is attending), and “why” (the reasons for attending).
It might be that the crowd of folks at a stand-up gets too large, and as they still think of themselves as one development unit (and they are, on a higher level), their daily tasks have become more autonomous, and progress reports they share don’t seem relevant as daily updates anymore. Could be they’re each doing smaller features, or sub-projects; or it could be that your large team has inconspicuously turned into several smaller teams. Now, will the guys in those mini-teams be genuinely interested in sharing and listening to tiny details about the work that isn’t in their current focus? Daily? For sure, not. But they would want more meaningful high-level progress updates from the other mini-teams, as they are still interested in the bigger picture. It would never do harm for everyone else in a larger team to know what’s going on if those mini-teams report on their overall progress as one unit, not as standalone developers.
So, a daily stand-up meeting can morph into various shapes, depending on how your team morphs into various work landscapes. Boredom and lack of focus are sure signs that “who” and “why” need to be questioned. Naive hacks such as keeping meetings short by standing-up, or other trickster stuff like that will not get to the root of the issue. All the problems with daily stand-up meetings eventually boil down to sharing the irrelevant information. If you sense any single hint of boredom in the air, it’s time to do a health check. No need to make it time-specific: what good it is if you decide to re-frame stand-ups once a month, or once in 2 weeks, but something in the work changes, and adjustments have to be made right away?
Your daily stand-up may turn into a status meeting, nothing wrong with that. It’s just another example that the goal is not to follow some practice by the book (a daily stand-up is a recommended practice for Scrum), but tune it to the way you work, not the other way around. That’s what they call Agile, and that’s what the “work-get feedback-iterate-get feedback-iterate” loop is about. In this case, the feedback cycle would run in the context of daily stand-up practice.
Earlier this year I published several posts on meetings, uncovering some reasons why they can be a waste of time, or why they can be productive. This subject has many more perspectives than seen on the surface, and today I’d like to highlight one basic idea.
Any meeting includes the following 3 components, and its success would depend on how well those components fit together:
Problem — issues to be addressed;
Goal — the desired outcome;
People — they need to have a shared understanding of problems and goals.
The quirky green-red thing in the middle is supposed to visualize the volatility of the conjunction.The notorious feel of wasted time at meetings is usually related to the bad cohesion of those 3 components.
The so-called technical meetings is where the components fit best. Such meetings can happen on the fly as 2-3 experts discuss a clearly outlined technical problem, looking for a clearly outlined goal. This is straightforward, the technical problems are obvious, they are discussed openly, and with focus. The “instant” meetings always have the right people due to the very nature of the subject matter. This is a perfect setup, as all the three components share an overlap.
Misfits begin when at least one of the components breaks loose from the nucleus. This usually happens at decision-making meetings (non-technical). If not all people have a good understanding of the subject matter, however valuable their input might be, it would take extra time to bring them on the same page with the others. In this case, it would be reasonable to narrow down the selection of the participants OR take some time before the meeting to educate them. We all must have been at meetings where 3+ people are waiting until someone is catching up with what all the rest understand. The 3+ people are getting impatient and irritated while this education process takes place. It’s not bad to explain things to people though. But this has to be done elsewhere, at some other “educational” meeting, not at the decision-making one.
Next, the integrity of meetings is ruined by blurred goals. For non-technical meetings, the goal should clearly be identified as one of the following: is this meeting supposed to uncover any missing facts to back up the decision, or is it purely a decision-making meeting? Some strategic decisions might require a series of prep meetings, until it gets down to taking a group decision.
The key to successful decision-making meetings would be this: try to make them technical. Cut them down into pieces, and bring together as few people as possible to resolve a clearly outlined problem, with a clear goal in mind. It’s more effective and reasonable to break the subject matter into smaller problems, address them in turn, and take to the next decision-making level, and to the next meeting. The PGP abbreviation in the name of the post implies this approach with the play on words: PGP=Pretty Good Privacy.
Soap, Laundry and Company Boards
Skype Is (not) The Limit..?
I’d like to write more about meetings today. It’s not a series of posts (officially), but looks like it’s evolving as one, since I’m picking up on my earlier posts on how to reduce the toxicity of meetings and how Skype works as on organic supplement for knowledge sharing in our company.
On top of the usual UX meetings and dev kick-start meetings, we’ve introduced a new kind of meetings recently. The company board meetings. We’re just in this phase of growth when it’s about time to try boards for decision making. At the moment, we’ve got the Product/UX Board, the Development Board and Marketing Board. The founders/stakeholders board (the Head Board) has been in action for several years by now; this board is responsible for taking decisions about the company policy, some strategic visions, etc. It’s those 3 new boards we’ve started just now. The boards, usually 5-7 people, work by a simple 5-2 vote (or a 4-1). The board members are of a mixed background: marketers and developers are sitting in the Product/UX board along with the UX people and feature owners (check who the feature owners are); developers and designers mingle with marketers in the Marketing Board. The good sign that confirms the integrity and the common shared vision of our team is that it rarely gets down to any other than 5-2 split-up of the votes. If it’s 4-3 or 3-4, this usually means that the subject requires more discussion, as some essential details might have been left out.
We’ve started the boards for several reasons. One of them is to be able to come up with unbiased visions. As a marketer, you tend to focus on the marketing things alone, so if developers infuse some of their blood into the veins of marketers, or if the UX people get involved in the decisions related to marketing — it’s good. From my experience, a more common case is when things are seen rather from the dev perspective, and developers need to be educated in marketing.
I’ve been at some of those board meetings but for the moment I prefer to keep a certain stance of cross-boardability. I try to make my point to people who sit in the board meetings, but I stay away from being too deeply immersed in the activities of any particular board. Why so? I have noticed one interesting trend. The boards start wearing out once they get into action (check the header image). It’s about the same, the more you rub the board washing your laundry, the more soap foam is generated, blurring the clarity of your vision. Well, this does not necessarily mean that the laundry will come out dirty, rather the other way round. But the laundry lady needs to clean the board from the used-up soap foam to be able to see if the laundry is clean. Not sure if someone actually does laundry this way — we’ve got washing machines after all — but, well, there’s no machine for the board’s decision-making, that’s why I’ve applied the soap-and-washboard metaphor here.
The intent behind creating our boards has been exactly that: to keep the vision fresh and clear, and consider things from all possible perspectives. Looks like some rotation is needed to maintain the freshness, and might be it has to be done more frequently than we supposed at first. Or, a fresh quick look from someone who is not a board member, but a keen observer could be helpful. If you’re not rinsing off the old soap foam, your vision will lack clarity and perspective, not to mention the notorious brain drain which would then creep in and poison your board meeting . Perhaps, we need to come out with more sophisticated rotation patterns. Or, perhaps at some point, we might need to merge the UX/Product Board and the Dev Board into one Production Board. Or, make it Marketing Board + Product Board and UX Board+Dev Board. We keep looking and trying.
P.S. Happy 8th of March, ladies :)
A similar post:
Competent Decision-Making and Rusty Tinman
In one of my previous posts, I contemplated why meetings are exhausting, and uncovered a possible reason for that: people get tired naturally when they try to share too much within too short a time frame. It appears that asynchronous communication in between meetings helps to minimize this drain, so I’ll tell more on how we do it in our company.
In general, this is searching for the most comfortable process of knowledge sharing, which wouldn’t interrupt the personal productive flow of people and at the same time keep them informed just enough of what the others are sharing, in the context of each other’s responsibilities. One of the traditional ways of asynchronous communication are all kinds of comment threads – just like in this blog, if you scroll down a bit. We have the threads of comments built-in into TargetProcess, and they work mostly as status or diagnostic messages, like “changed the code”, “need the design”, “rolled out to production”. For meetings and creative exchanges, something in the middle is needed. Not as slow as email, even not as slow as comments, but something that allows a delayed reaction and powers the dynamic exchange of ideas at the same time. Note, that I’m speaking only about the communication within a team of like-minded people here. Google Groups, Wikis – can you believe it, we even tried CampFire. Michael was tempted by its design, and decided it’s worth a try. It didn’t last long however. Just wasn’t as convenient as .. yes, you guessed it right, the good old Skype.
Whatever we tried, we ended up going back to Skype. Turns out it works best for our purposes, and in our environment. Of course, we’re not using it as an “instant” information machine-gun; people are not required to answer right away. We’ve set up a number of Skype chats. For example, there’s a “TargetProcess Design Folks” chat. The design people use this chat to build the collective taste in UX, they share links, discuss drafts and help each other come up with the UI concepts. I’m pretty sure, not any number of the formal UX meetings will cover the wealth of ideas and references that this Skype roll contains. So, for this creative exchange a Skype chat is a perfect tool. The only concern might be that every task has its due time: time to exchange ideas in the chat, and time to go deep into yourself to come up with your own thing. Fortunately, one can turn off instant notifications for Skype chats, or have the notifications sent out only if a certain word(s) is mentioned.
Among the other Skype chats, there’s one called “Product”. Anything related to TargetProcess as a product can be discussed here. Feedbacks, ideas, improvement suggestions, some of those suggestions can then be added to the backlog and implemented in TargetProcess. Our support and infrastructure team have their chat as well. Unlike the chats about UX or the Product, or the chats for various boards, this one quite often requires an instant reaction.
Skype chats are a good multi-purpose tool indeed. They provide instant notifications to support and infrastructure teams, and at the same time, they work as an optimal async communication tool, when it goes about ideas/knowledge exchange to back up the team thinking. The consistency of this async exchange keeps everyone on the same page when at a meeting, and people are less tired. There’s no way one can stay completely fresh after a meeting, sorry, I wouldn’t commit to a “how-to” here :)
The more I think of it, the more it looks like Skype has the features that an agile team needs to generate ideas from the common pool, to react quickly, and to get into action. It might be that Skype won’t appear that universal for a company less agile than ours. I’m just telling about our experience.
Over the last several months I’ve published 2 parts of the series on agile retrospectives, and the 3d part is supposed to come up as it gets closer to spring. By the way, the Groundhog Day will be this Saturday, so I’m eager to find out what the groundhog predicts :)
This whole work, research and observations led me to musing about meetings in general. Most probably you’re familiar with the “Meetings are Toxic” maxim from the “Getting Real” book by 37 signals. I tend to agree with it. In short, meetings are huge energy drainers and productivity flow breakers, so the deal is to figure out if this energy drain is actually worth it. However, there’s at least one great thing I’m very happy about when it goes about our meetings: there’s no space left for elephants in the room! Unlike in the picture below. :)
I’ve been a part of some meetings in our company, and I’ve talked to people asking if meetings are productive? What are the other ways to reach the desired outcome? As always, there’re pros and cons. If we try to follow 37 signals and their maxim, we will most likely miss something vital at the end of the day. People get together and talk at meetings. Getting together and talking is good, that’s for sure, but is it paying off the value? The answer would be “yes”, despite the subject drift-offs, someone holding the attention of the group for more than it’s appropriate, being poorly prepared due to the overload with other tasks and commitments, etc.
One note though: this “yes” holds true for our company, and it depends. Besides, there’re various kinds of meetings. Developers get together to discuss, sketch and define the way to do some functional feature. These meetings occur all the time, and they don’t seem to interrupt the productivity. They really do matter. What I’m getting at are product management meetings, UX meetings and other larger company meetings.
It appears that the core of the “it depends” is hiding in the ability to create an asynchronous loop of valuable inputs into the product vision and UX concepts. What if we all were able to see as one without the drain of a meeting? To give it a personal perspective, through all the years of working with clients I’ve felt a disconnect, a slight or at times a larger one, between what production does, and what leads and customers want and feel. We’re doing better now, which is great, and people who interface with leads and customers are able to make a meaningful input at the product board meetings. In our company, the product board is a 7-member decision-making unit, which includes developers, UX-ers and people who interface with leads and customers. The only nasty problem that persists is that meetings are a work in itself. If only someone’s job would be solely to attend meetings. There’re other tangible tasks to do. Designers need to actually create sketches and prototypes, developers need to build the architecture and write the code, and marketing/support people need probably even more energy as they are always in the trenches, talking to leads and customers. Oh. And product managers and feature owners are responsible for smart product decisions.
Unfortunately, smart product decisions are not 100% guaranteed by those meetings only. We’re sticking to the board meetings approach so far, and it’s definitely a step ahead in our evolution. Seven minds are always better than one mind. But is there a comfortable, slow-paced way for those 7 minds to unite in one vision? If seven people are trying to share their product perspectives over a short time frame, as in a meeting, that’s where the ultimate, never-mentioned source of this exhausting drain sits. It’s simply about the way we are wired. You just can’t pour your vision from your brain to someone else’s brain in one quick shot. It’s not like with whisky. It’s exactly for that reason that we inevitably face the need for building the gradual, asynchronous awareness of the product as a whole. This is related to Michael’s recent Specialize or Generalize post, and it goes beyond the boundaries of software development as such.
Back to 37 signals. Their “Meetings are Toxic” judgement is sharp, clear and perfectly correct in the context of their evolution. We’re doing things our way, as we try to back up meetings with various asynchronous ways of building and sharing a versatile product vision e.g. Google Groups, internal blogs, wikis, talks in the office kitchen, etc. Asynchronous exchanges are compulsory homework before the meetings; they work great for any knowledge work, for many reasons, and it would take a yet another blog post to tell more about that. For now, I will just reference this great article on asynchronous communication.