Archive for the ‘EN’ Category

Multitouch brainstorming in Edinburgh

Monday, June 7th, 2010

As part of their design case project, four User System Interaction students from Eindhoven University of Technology (Sophia Atzeni, Annemiek van Drunen, Aljosja Jacobs, and Dirk Verhagen) have designed a multitouch brainstorming application for Future Workspaces. See this earlier post. They have written a paper about their project that has been accepted for the Create10 conference, June 30th – July 2nd in Edinburgh, UK. A PDF copy of the paper is available here.

Sophia, Annemiek, Aljosha, and Dirk: congratulations and good luck in Edinburgh!

VN:F [1.9.1_1087]
Rating: 5.0/5 (2 votes cast)
VN:F [1.9.1_1087]
Rating: 0 (from 0 votes)

Paper is here to stay

Monday, June 7th, 2010

“Paper is here to stay”. Are you curious to know why? And do you want to know what lessons can be learned from the use of paper - for example, to improve digital systems for document management? In this presentation, Olha Bondarenko (currently working as a Productivity Professional at Philips) summarizes the results of seven years of research into this subject, carried out at the Eindhoven University of Technology, Océ, and Novay.

VN:F [1.9.1_1087]
Rating: 0.0/5 (0 votes cast)
VN:F [1.9.1_1087]
Rating: 0 (from 0 votes)

Distributed Agile: communication and common ground

Friday, January 29th, 2010

Cross-posted from Mathemagenic

With the holidays I somewhat took a break from blogging on our work on the distributed Agile case, but there are still quite a few things there that I wanted to share to hear what do you think. This one is a bit scary since I picked up some ideas from linguistics without having a proper reading of the work behind it, but at times this is the price to pay* for sitting between research and practice.

Communication and common groundSo, the picture on the right is a simplified version of the work of Herbert H. Clark:

According to Clark, in order for one person to understand another, there must be a “common ground” of knowledge between them. He shows how people infer this “common ground” from their past conversations, their immediate surroundings, and their shared cultural background. [This is from a back of Clark's book "Arenas of language use"]

In my terms: communication is enabled by the common ground between the participants and, in turn, contributes to building more common ground over time. Taking it a bit further, it is useful to distinguish between two components of the common ground:

  • information that the participants share (not necessarily explicitly, as it is often assumed that others know about X because of shared cultural, educational or work background) – I talk about shared knowledge and awareness of the bigger picture here
  • relationships between the participants – knowledge about each other and trust

Now to the distributed Agile teams. At a starting point there is a big distance between the team members:

  • different locations that make it difficult to rely on team-building and ad-hoc interaction that naturally happens in a co-located team;
  • time differences that in some cases provide only a small window of opportunity for interactions;
  • different cultures, organisations and levels of technical expertise create difficulties of getting a team “on one page” needed for seamless work.

Communication and common groundDistance between team members across different locations creates a vicious circle:

  • lack of common ground, the need for using technology and addressing time issues make communication challenging
  • challenges in communication make it difficult to overcome initial differences between teams, to build relationships and shared understanding of the bigger picture behind work

This picture is not that far from what you can learn by reading about the challenges of distributed Agile and solutions to address them, but hopefully it can help to address the problems in a more systematic way: spending time on establishing shared understanding and relationships in the team (especially in the beginning) and finding ways to shape communication processes and tools that not only allow to get things done, but also contribute to growing awareness and relationships over time.

My personal “hobby horse” is around the last point. From what we have seen, the communication in distributed teams often shrinks to purely functional and, compared to face-to-face settings, there is much less unstructured informal interactions – this works for getting the work done (at some level), but seriously limits the opportunities to build awareness of the bigger picture and relationships. Most of the solutions in respect to building the common ground in distributed Agile teams still rely on making sure that there are opportunities to visit each other, while there is a lot of space for a technology-mediated ways to do so next to the f2f.

* The ideas behind this post are grounded in insights coming from research on computer-mediated communication and distributed teams, but I need more time to read papers and to integrate research ideas in a systematic way. Hope to blog about it soon.

VN:F [1.9.1_1087]
Rating: 0.0/5 (0 votes cast)
VN:F [1.9.1_1087]
Rating: 0 (from 0 votes)

A brainstorm application for a multi-touch wall

Tuesday, January 5th, 2010

During their design case project, four User System Interaction students from Eindhoven University of Technology (Sophia Atzeni, Annemiek van Drunen, Aljosja Jacobs, and Dirk Verhagen) have designed a brainstorming application for our multi-touch wall made by SOCO Amsterdam. Below they briefly describe their project and the results.

The multitouch wall, custom made for Future Workspaces by SOCO Amsterdam

“On assignment for Future Workspaces we have looked into how to improve collaborative moments for knowledge workers using multi-touch technology. One of the most promising collaborative activities that could be improved was brainstorming. An interactive system already offers many advantages, and especially during the idea clustering phase the advantages of multi-touch can be leveraged. We have developed such a brainstorming application in collaboration with knowledge workers and validated the concept using focus groups.

With our application we try to bring a good deal more fun to the brainstorming process by providing brainstorm participants with interactive games. These games bring participants to the multi touch wall, and also release some of the tensions associated with selecting ‘winning’ ideas. Next to that, we also made large improvements on the clustering process. We feel it is important to be able to freely try different clusterings, and be able to play around during this phase. Using intuitive gestures, and using a ’bubble’ metaphor, brainstorm participants are able to create, move, remove, resize, rearrange, undo and relate clusters and ideas. During the entire brainstorm we support structuring the discussion with a ‘compare idea’ tool so participants can backtrack decisions and their rationale.

Are you curious to see how this all works together to support an entire brainstorming session, from creation of ideas to the selection of them? Then please, check out our movie prototype below. We welcome any comments you might have.”

VN:F [1.9.1_1087]
Rating: 5.0/5 (1 vote cast)
VN:F [1.9.1_1087]
Rating: 0 (from 0 votes)

Shrunken communication in distributed teams (the egg of communication :)

Wednesday, December 9th, 2009

Cross-posted from Mathemagenic

As promised – more thinking from our project looking at the challenges in distributed Agile teams. One of the first things we have observed was a heavy focus on goal-oriented communication between people in different locations: they would talk (this includes ‘type’ :) about solving particular problems around work, but hardly anything else. I drew a picture to explain what happens in this case that others found useful and quickly nicknamed “the egg” – so, here it is.

Communication in co-located and distributed teamsYou can look at communication in a team across two axes. The first one (horizontal) is about what triggers it. I find it useful to distinguish between goal-oriented and opportunity-driven communication:

  • Goal-oriented communication is about work-related problem solving and coordination. It’s the task at hand that forces you to approach others to sort out things with them. This is the case where you wouldn’t hesitate to plan a meeting, send an email or pick up the phone to call.
  • Opportunity-driven communication is about things not 100% necessary, but potentially useful, or, even, not very useful, but just said at the moment (“good morning everyone!”). Think of the cases where you wonder if your email is ’spamming’, add “by the way, do you also know…” or most of the conversations at the coffee corner. In this case communication is triggered by an opportunity – bumping into people, interesting things happening, ideas floating by or just an awkward silence that forces you to look for a topic to continue. This type of communication is piggybacking on something else: either happening around goal-oriented communication (e.g. side conversations at a meeting), other activities (having a coffee together) or observing others (e.g. seeing a colleague and remembering to ask them about something).

Vertical axis is about the ‘pre-arrangeness’ of communication (I’m not sure with the terms here, so any suggestions are welcome):

  • Structured communication is expected and, to an extend, formalised. Planned meetings, promised memos and status reports are here. In this case there is time, space and resources needed to communicate (or, at least, nobody questions that they should be there).
  • Informal communication is about everything else. It’s also expected, but in a more fuzzy sense (“let me know if there is a problem”). It’s not likely to be known in advance when and how it will happen, so it’s more difficult to allocate the resources for it.

In a co-located team all types of communication have place (the whole egg :) . There are enough triggers for an opportunity-based communication and being in front of someone makes negotiating about time, space and channels for informal communication easy (you rather make a minute to talk about the thing, say “no” or make an arrangement about communicating later on).

In a distributed team communication shrinks to the basics (egg yellow :) . From one side, when there is no “easyness” of face-to-face settings, we are likely to rely on structured communication, since negotiating time and resources for informal communication is more challenging (e.g. email might be not read for a while, phone is interruptive and costly, etc.). Informal communication is still happens, especially in the goal-oriented space, but the chances for it are lower, because it’s extra taxing (e.g. questions that would be asked in a meeting may not get get asked in email or IM chat). For opportunity-driven communication it’s even worse: lack of shared physical space results in far less triggers that might turn into a conversation: there are not many non-essential activities (no drinking coffee online :) , it’s more difficult to observe others and even goal-oriented communication mediated by technology tends to be more “on topic” (from my experience “social talk” at a face-to-face meeting happens much easier than in a phone conference or email exchange).

There are quite a few more things to add here (in particularly about the negative effects of shrunken communication and ways to extend it), but nobody likes very long blogposts :)

VN:F [1.9.1_1087]
Rating: 0.0/5 (0 votes cast)
VN:F [1.9.1_1087]
Rating: 0 (from 0 votes)

Distributed Agile: the black box of co-located team

Wednesday, December 2nd, 2009

Cross-posted from Mathemagenic

First, a bit of the context: we are working on a project helping distributed Agile teams to identify challenges they have to deal with and to find solutions for them. Also, as much as I would like to make it a proper research project (with in-depth state-of-the-art review, large scale data collection and time to process all that), it is more of a research-based consulting: we observe a bit, interview some people, scratch the surface of what had been said on it and hope that our research backgrounds would help to fill in the gaps to come back with useful insights.

Second, a disclaimer: I’m not an expert on Agile software development, but have been learning about it in the past few months. And, while my research is pretty much about technology-mediated ways of working, research on distributed teams is not at the core of it. But all that shouldn’t prevent me from writing about it, isn’t it?

Now to the point. I’ll start from the values behind the Agile approach, as articulated in Manifesto for Agile Software Development:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Those values are supported by a set of principles and a variety of methods and practices that address those principles in practice. Now the part that is directly relevant to our case: while it’s not always immediately obvious, Agile methods are designed for a co-located team, articulated in one of the principles:

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

From one side, this makes the whole exercise of figuring out how Agile can work in a distributed team pretty pointless: it’s not designed for it. From another, there are various reasons for distributed Agile teams and examples where they work (some links). So the question is not if distributed Agile is possible, but how to make it work.

For me it translates into the focus on understanding what is actually happening face-to-face and then figuring out what of it and how exactly can be supported in a distributed settings.

Distributed Agile This is a simplified picture of what we have observed in our case. It is heavily based on Scrum as a main method, which could be described in terms of roles, ceremonies and artifacts. In a sense those are the known ingredients for the success, so a lot of effort goes into figuring out how they can work when the team is distributed. This involves, for example, finding tools and adjusting processes to support ceremonies (e.g. daily stand-up meetings) and figuring out how to share and update artifacts online.

However, next to those known ingredients there is a big black box: co-located team. Co-location and face-to-face interaction is one of the cornerstones of Agile, but from what I’ve seen there is not that much understanding of what exactly happens there. Which is fine when the team is co-located – we have evolved to make the best uses of face-to-face and don’t even have to think of what and how we do. But when the team gets distributed that lack of attention to the black box results in all kinds of challenges. And, given that Agile philosophy places so much value on informality, putting efforts into articulating and formalising the blackbox ingredients doesn’t get much momentum.

So, this is more or less what we are doing in the project: bringing research instruments to open the black box and then working together with the teams to figure out how to make it work in distributed settings.

[As you have probably guessed two previous posts are directly related to this one: Why sharing a team room might be not so good and What a coffee corner provides, how to call it and a research agenda. More to come :) ]

VN:F [1.9.1_1087]
Rating: 0.0/5 (0 votes cast)
VN:F [1.9.1_1087]
Rating: 0 (from 0 votes)

Do you need a webcare team?

Tuesday, December 1st, 2009

helpdesk2At the Dutch National Architecture congress (LAC2009) we have given a talk on the organizational and architectural aspects of introducing Web2.0 tools. One of the main issues we discussed was how to support your employees to make responsible use of social media and how to deal with negative responses, complaints or online discussions about your brand that are getting out of hand. One of the interesting approaches companies such as ING and UPC are experimenting with is a webcare team.

A webcare team monitors online conversations on Twitter, blogs and other social media and has a strategy on how to deal with various types of negative responses via social media. When necesary, they can join the conversation, offer support, provide facts or anything else to steer things in the right direction. But it is not just about customer care, the webcare team can also do PR (discovering and preventing issues) and marketing (educating customers or providing feedback to product development).

Why do companies actually care about what is being said in social media? More and more companies realize that, in line with the Cluetrain Manifesto, “markets are conversations”: customers trust opinions of friends a lot more than they trust company websites, and they use information about products and services found on social media to make informed choices.

Who should be in your webcare team?
From the type of work a webcare team has to do, it should be clear that this is not a job for the IT department. Instead, people from marketing and corporate communication should be involved, and maybe even experts on your products and services. Pick your team from people who understand the norms of social media and are able to respond from a personal perspective. As such, your manager PR and corporate communication is probably not a good candidate for the job.

The tools of the trade
Webcare teams get more and more tools to discover what is currently being said about their brand, products and services. Important tools of the trade are Google Alerts, Twitter search, Technorati and Google blog search. These tools are all aimed at discovering relevant online conversations, without having to spend the whole day looking.

What is a smart social media strategy?
Unfortunately, there is no universal recipe for a smart social media strategy yet. Nevertheless, an important starting point is to accept each opinion as such, and not call opinions into question. As with any employee that takes part in an online conversation, the norm is to identify yourself as an employee of the company and behave accordingly. Also it seems important not to be drawn into online discussions: seek direct communication with the person behind the complaint. For more inspiration on social media strategies, I suggest you take a look at the IBM Social Computing guidelines.

I would like to hear your experiences with webcare teams!

The slides of our talk (in Dutch) are available via slideshare:

VN:F [1.9.1_1087]
Rating: 0.0/5 (0 votes cast)
VN:F [1.9.1_1087]
Rating: 0 (from 0 votes)

Method: bias storm

Monday, November 9th, 2009

The bias storm is a method we apply at the start of collaboration, when the people who have to collaborate come from different backgrounds, cultures or organizations. The method aims to get prejudices they might have about the other in the open. Talking about these prejudices helps to understand the other and clears the road for fruitful future collaboration.

How it works
This method should be used during the initial session of people who have to collaborate. Immediately after the initial round of who is who and why are we here together today, form pairs of people from different backgrounds, cultures, organizations or whatever barrier you wish to level. Ask these pairs to write down on sticky notes what prejudices their colleagues might have against people from the other “side”. It is important not to ask what prejudices they have; as that might result in only the politically correct responses. While they are writing these down, walk around and stimulate them with questions such as: “What did your colleages say when they heard you had this session?”.

After a few minutes, when you notice that “the popcorn stops popping” ask the people from one “side” to read out what they have written down. Write key terms on a big piece of paper. Try to defer any defence (“I would like to react on that…”, “Let me put that straight…”) to the next phase. Then ask the people from the other side to read out what they have written down and collect their key terms on a different piece of paper. Then start the next phase by just asking “Who would like to react?

Our experience is that this method is a powerful starter for cross-organizational collaboration projects.

(c) photo: http://www.flickr.com/photos/agharti

VN:F [1.9.1_1087]
Rating: 5.0/5 (1 vote cast)
VN:F [1.9.1_1087]
Rating: 0 (from 0 votes)

Comparing tools for cross-organizational collaboration

Friday, October 2nd, 2009

Since one of our customers would like to experiment with close collaboration across organizational boundaries (discussing information), I am currently comparing a series of tools. The table below represents my findings from testing the different alternatives. The information in the row “User friendliness” is subjective: it indicates how easy I could find my way around the tool. If you see information in the table that you consider to be not correct, please let me know or post a comment. (more…)

VN:F [1.9.1_1087]
Rating: 4.6/5 (5 votes cast)
VN:F [1.9.1_1087]
Rating: 0 (from 0 votes)

Keeping Mobile Workers In Sync and In Touch: Big Challenges, Modest Solutions

Thursday, September 24th, 2009

Within Future Workspaces, Jennifer Curtis conducted a study of mobile workers in partial fulfillment of the requirements for a Professional Doctorate in Engineering in the area of User-System Interaction from Eindhoven University of Technology. Her findings are summarized in this post. The complete project report can be found here, and corresponding presentation here.

The two main goals of Jennifer’s project were to: (1) Identify the consequences and challenges of mobile work – particularly with respect one’s ability to stay up-to-date (i.e., in sync) and connected (i.e., in touch) with his or her distant colleagues; and, (2) come up with potential design solutions to address these challenges.

  (more…)

VN:F [1.9.1_1087]
Rating: 0.0/5 (0 votes cast)
VN:F [1.9.1_1087]
Rating: 0 (from 0 votes)