Het rapport gaat in op belangrijke ICT gerelateerde uitdagingen voor de professional rondom “Het Nieuwe Werken” en biedt oplossingsrichtingen hoe organisaties hun medewerkers kunnen faciliteren met nieuwe werkvormen om toch “connected” te blijven met elkaar. Immers flexibilisering komt met een prijs. Collega’s weten steeds minder waar anderen mee bezig zijn. Informele kanalen veranderen of verdwijnen. Vertrouwensrelaties komen moeilijker tot stand, waardoor het delen van kennis wordt gehinderd. Het rapport gaat hier op in en biedt bovendien een innovatieve aanpak om met kleine interventies de verbondenheid tussen professionals te behouden en zelfs te activeren.

Een PDF-versie van het rapport is hier te downloaden. Wilt u liever een hardcopy, e-mail dan even.

While I came with the communication egg model to talk about things missing in distributed teams I feel that it could be useful in more contexts. In particularly to talk about the differences between different types of social constructions in the knowledge management context.

[At this point it makes sense to go and read Shrunken communication in distributed teams (the egg of communication ]

One of the things I came up when playing with different ideas was to position teams, communities and networks in respect to the most prevalent forms of communication in each case (in all cases the other forms of communication are there as well, but are not at the core of it).

Team communication is heavily shaped by the shared goals and agreed communication formats/processes. It’s very much about getting things done together and strong ties that needed for it.

Communication in communities is a bit further from actual work, but still has lots of connection with it (e.g. Q&A mode, where one uses an opportunity of being together with other experts to ask for solutions for a problem). It’s usually a mix of stronger and weaker ties that help to open up and share local practices. There is enough commonality and trust to hold people together and enough diversity to support learning.

Network communication is more opportunity-based and informal. There is not much in terms of shared goals and recurrent conversations, the ties are weak or latent. However, there is enough connectivity and opportunities to communicate that result in cross-fertilisation and emergent ideas and practices.

I guess the things on the diagonal could be also about the types of communication that is supported by specific managerial practices (performance – knowledge management/professional development – informal learning/innovation) or social tools (groupware – community tools – social media).

You can also use this framework to think on what is needed in terms of moving between different types of social constructions: e.g. moving from network to community by picking shared interests and adding a bit of structure (rhyhm, roles) or community-born projects, where shared goals and even more structures (e.g. deadlines appear to make sure that things get done. In the opposite direction you might think of “usual” KM practice of spotting overlaps between teams and establishing semi-structured community spaces and processes to make sure that practices are shared across and going to networking events or sharing one’s traces online to create opportunities for informal interaction that brings new contacts and new ideas.

***

Does it make any sense? I’m actually more happy with the picture than we the text around it, but anyway all of this stuff is thinking in progress, so hopefully will eventually evolve into something more understandable.

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.

So, 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.

Distance 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.

	Quickr	Google Docs	Ning	Zoho wiki	Office Live	Box .net	Huddle	Con fluence	Base camp
Logging in
Https	?
New workspace
According to template					(1)
Access rights
My workspaces
Documents			(2)
Action points
Traceability	(3)
Notification change
Notification action points
Schedule
Online status
Chat	(4)
Knowledge base
Free	(5)					(6)	(7)	(8)	(9)
User friendly
Web application
Dutch
Ads free			(10)
Standard	DFNAS	DF	NS	DN	DFNAS	DF	DFAS	D	DA

About the demands: based on the way the customer would like to work together with people from other organizations, we have formulated the following demands on the virtual workspace. The words must, should and could in the description indicate the importance of the requirement:

• Logging in. The workspace must be secure and people need to log in before being able to access information.
• Https. Communication over the internet should be secure.
• New workspace: It must be possible to create new sub-workspaces that contain information on a specific topic/case, with specific access rights.
• According to template: It should be possible to create new workspaces according to a template to create a standard structure or to fill them with standard documents.
• Access rights. It must be possible to indicate per sub-workspace which people or groups have access (edit, view, no access)
• My workspaces. It should be possible to have an overview of the workspaces (topics/cases) you are working on.
• Documents. It should be possible to upload documents (Word or PDF) as part of a workspace. In the next phase of our experiment this must be possible.
• Action points. It must be possible to keep track of action points as part of a workspace.
• Traceability. It must be possible to see who made what changes to the workspace.
• Notification change. Users must be able to receive notifications of changes to the workspace.
• Notification action points. Users must be able to receive notifications of changes to the action points.
• Schedule. It should be possible to keep track of scheduled meetings in the workspace.
• Online status. It could be nice to see the online status of other workspace members in the workspace.
• Chat. It should be possible to exchange chat messages with other users in the workspace.
• Knowledge base. It should be possible to create a knowledge base at the highest level of the workspace, with questions and answers that all registered users can access.
• Free. The workspace should be free to use.
• User friendly. The interface of the workspace must be intuitive, clear and appealing (subjective scale).
• Web application. Users must be able to access the workspace via the internet using their web browser.
• Dutch. The workspace should have a Dutch interface.
• Ads. The workspace should not show ads.
• Standard: While it is often possible to store information in a workspace (for instance, notes about a document can be placed on a wiki), this shows which types of information (relevant in the pilot) the workspace recognizes.
  • Documents
  • Folders
  • Notes
  • Action points / tasks
  • Scheduled meetings / events

Notes:

1. Only via pre-defined templates
2. Only via external applications: Ning Apps
3. Only in the Quickr wiki
4. Requires integration with Lotus Sametime
5. The costs are €71 per person per year
6. The costs are $15 per person per month
7. Costs start at $200 per month, see http://www.huddle.net/huddle-price-plans/
8. See the options at http://www.atlassian.com/software/confluence/pricing.jsp
9. See the pricing options at http://basecamphq.com/signup
10. Paid option

Steven’s research project has been a study towards new ways of working for system architects. System architects are responsible for the architecture of complex systems, like printers, MRI-scanners or radar systems. A series of interviews has been conducted with system architects at Océ, Philips and Thales to discuss concepts and obtain insights. This resulted in Project Buzz Tracker, a tool that couples activity information to project and workflow planning. Persons frequently give an update on their actions, thus showing the Buzz in a project. By observing this overview, the system architect can see concentrations or a lack of Buzz. These can be indications of problematic issues. Project Buzz Tracker will further strengthen team cohesion, especially if distant workers are involved.

General Findings
Using interviews, it has been found out that system architects do not have specific communication needs. The communication needs that they have are generally applicable. The system architects do have unique information management needs, because they are the only ones in a project specifically interested in architecting information.
System architects (at least the ones that were interviewed) highly value face-to-face communication. Currently, they succeed in having these face-to-face communications with for example co-workers and customers. Nevertheless, assuming that workers become more and more dispersed, system architects have to find new means of communication too. The tools proposed in this research can play an important role in this respect. By doing a literature study, several aspects of the communication process were identified that deserve special attention, considering the area of system architecting.
When developing future concepts it is better to develop them by satisfying needs than by solving problems. Problems often have a short term nature, whereas needs will still exist in the future. A broad spectrum of solutions was created. By providing solutions for all identified needs, a large and relevant subset of solutions has been created. By combining these solutions into concepts, it is ensured that the concepts are relevant and solve the right issues. The concepts that have been elaborated aim at providing overview in various large data spaces.

Project Buzz Tracker
Because of limited time, only one concept was worked out. This concept is called Project Buzz Tracker. It makes innovative use of the upcoming phenomenon of social media. Project Buzz Tracker provides a clear, graphical overview on which persons are working on what tasks, something that is relevant in architecting. It shows small status updates (buzz) that are mapped on a project planning. The planning can be zoomed, revealing more detailed tasks. It may be less useful in small, closely located, project teams, but extremely useful in dispersed project teams, as there is less sense of what is happening in the project within these teams. Several filters can be applied, to find information more easily.

As this tool has to be used by a complete project team to be useful, it has been described how personal objections against using the tool can be taken away, and which benefits the tool holds for stakeholders. It is clear that the strongest focus must lie on making the tool suitable and beneficial for the whole project team. It is suggested that coupling this tool to to do software is a strong choice in this perspective. Also, providing incentives by integrating Project Buzz Tracker with already used tools should be pursued (i.e. integrate with Outlook). Thus, in further elaborations of Project Buzz Tracker, there should be a focus on making the tool useful for the complete project team.
Second, it has been noticed during various presentations of Project Buzz Tracker that the benefits of this tool were not emphasized enough. People who were presented with the concept, liked it, but failed to see the advantages. For each stakeholder group, a SWOT analysis was made which presents the advantages of the tool more clearly.

If you would like more information, the whole research report can be found here or you can contact Geke Ludden (Geke.Ludden@novay.nl).

1. Social Media Market – a workshop in which we take you and your team through the current Social Media landscape and explore which of these fit your needs and preferences.
2. Social Media Hands-on – a pilot in which you and your team experiment with a social tool of your choice. Apart from enabling and facilitating the use of the tool, we help you in gathering lessons learned and in assessing whether this tool actually provides added value for your team.
3. Social Media Strategic Advice – an independent, realistic advice on what social media could mean for your organization in relation to the business issues you are faced with. This series of activities help you to gain insight in whether or not to apply social media, how to introduce these tools in your organization and how to help your people use these tools in a smart and responsible way.

This line of activities is also a good way of getting to know us and our way of working: with a clear objective, timeline and budget we work together with you to achieve results and learn along the way. And hopefully raise your interest in broader research on future ways of working.

The physical version of the Concept Game can be played individually or in a workshop. It is also possible to play the Concept Game online.

Click here to start playing the Concept Game online. You will be asked to select your favourite and least favourite concept ideas. Please also tell us why you have selected these concepts and submit your choices. It will help us to focus our future plans and concept development.

The online version of the Concept Game was developed by Steven Haveman.

» Start the Concept Game

The participants of the workshop were divided into two groups. One group played with the Virtual Media Office demonstration, prepared by Sefan Burgers from Ericsson. The second group played with the Second Life demonstration, prepared by Bart van den Hooff of the VU.

The result was a nice discussion from which the following elements struck me:

• Staying in touch with colleagues can be facilitated using virtual worlds however currently it cannot complete replace face to face contact. For example, drinking coffee at a coffee corner is still very valuable. Maybe a good virtual coffee machine could be a way to go.
• Choosing (remote) team members using virtual worlds could become more objective as politics and personal aspects play a lesser role.
• Virtual worlds (including avatars) could become a intuitive graphical interface on top of the resources of a worker.
• A lot of workers use tools with a lot of (unintuitive) features (e.g. email), virtual worlds could provide a intuitive interface that discloses all these features in a more natural way, after a learning curve has been taken.
• Not all tasks of a knowledge worker may be suitable to perform in a virtual world (e.g. editing excel).
• The more important decisions become, the more face to face contact is needed to also grasp indirect communication aspects (e.g. body language). Current virtual worlds are less suitable to grasp indirect communications and hence may be less suitable for very important/delicate decisions.

Mike from Jam visualized outcomes of the discussion. More of the results (also from the other workshops) can be found here.

• 14 researchers with a shared interest in how ICT affects work, life, and society;
• they are working in the same research institute, but located over various parts of the building;
• they frequently work elsewhere, for instance during client visits, workshops, conferences;
• they are all working on several different projects at a time;
• they are well acquainted with one another, though not co-working on a daily basis;
• they share a feeling that cohesion and knowledge sharing in the group could be improved. 

Twitter usage13 People in the group used Twitter during the experiment, of which 5 were already using it. Usage statistics (averaged over all participants, those new to Twitter, and those experienced with Twitter) are shown in the table below. The table clearly shows that the new Twitter users twittered less and were following far fewer people outside the group than the experienced Twitter users. During the experiment, 2 new Twitter users gave up on Twitter.

Twitter evaluation

From the people who used Twitter, 11 completed the Twitter evaluation form. The form contained 10 statements, to be answered on a 5-point Likert scale (from -2 to 2 for “strongly disagree” to “strongly agree”). The spider graph below shows the results.

The graph shows that, overall, Twitter is evaluated quite positively. Twitter scores extremely high on the aspect of getting to know your colleagues more personally. Furthermore, Twitter scores very high on ease of use, and the benefits for work clearly seem to outweigh the costs of using it. However, Twitter scores poorly on the aspects of finding information on a certain topic or finding an expert on a certain topic.

Twitter experiences

An individual brainstorm (reflecting on personal experiences with Twitter, and writing these down on post-its) was followed by a group discussion on four themes. 10 People participated in this brainstorm and discussion. Highlights are presented below.

Likes & Dislikes

Likes:

• It’s nice to “follow” your colleagues: what have they been doing, what are they up to.
• You don’t necessarily have to react to what others are twittering.
• Twitter can be used like an RSS feed to follow developments on a topic or the lives of celebrities.
• Twitter is easy to install and use, and it easily integrates into tools like Facebook and Blogger.

Dislikes:

• Requests from unknown people who want to follow you; how did these people find me?
• No option to tweet to different groups, for instance, just to colleagues or to friends.
• It’s difficult to find a good balance of how many followers/following (Quitter!!!).
• Some people twitter too much, they “bury” the tweets of others.
• The “avalanche” of unread tweets if you didn’t log into Twitter for a while.
• For “quality” information you should turn to weblogs, not to Twitter.

Staying in sync & Staying in touch

Staying in sync:

• You can get a better feeling about what’s going on in some projects.
• Twitter can be used to get up to date on general news in your field.
• It helped to stay in sync and in touch when colleagues were out of office.
• Twitter doesn’t help you to stay in sync if you don’t have the time to check it frequently.
• The mobile client does not support URLs, so tweets using URLs are difficult to interpret.

Staying in touch:

• It provides a sense of being in touch, albeit fragmented (not always, and without an overview).
• It’s difficult to get into an ongoing conversation.
• It works really well to stay in touch with people who are far away.
• It lowers the threshold to stay in touch with people as it is less intrusive than IM, email, phone.
• Being aware of relatively small details (what are people doing, and where they are) gives a good sense of being in touch.

Success stories & Disappointments

Success stories:

• I didn’t realize how much I would appreciate to stay in touch with my colleagues.
• Quickly got several responses on a request for input, ideas, or a translation.

Disappointments:

• Being too busy to use Twitter, a nagging feeling “I should have twittered more”.
• Time zone differences; too many tweets the next morning.
• The Twitter site experienced some problems and some of my tweets went missing.
• The Twitter client crashed and needed to be reinstalled.

Usability & “Other”

Usability:

• Some functionality is hidden or simply unknown, for instance the use of “#”.
• Difficult to compare the lists of “followers” and “following”.
• There are too many Twitter clients (PC and mobile) which is confusing.
• Mobile clients to not offer the support that is actually needed (e.g., overview of new tweets, being able to follow links).

“Other”:

• Reciprocity is a problem; some replies seem to be missing.
• Still able to use it even though I don’t have much time.
• Still don’t have the feeling that it integrated well into my work.

Conclusion

It is clear that Twitter is a useful tool for maintaining a sense of being “in touch” with your colleagues, especially when they are often out of office or when you otherwise don’t see them often. A lack of time to frequently use Twitter is the main obstacle for staying “in touch”. But ease of use and the general opinion that it is fun to use, alleviate this and keep people motivated to use it.

Although Twitter allows one to send a request to followers, or to exchange information by sharing interesting URLs, for the people in this group it did not (yet) provide clear benefits with regard to more traditional aspects of knowledge sharing, like finding information on a topic or finding an expert on a topic.

Probably the best indicator for the success of this experiment is that, at the end of the evaluation workshop, all people who were still using Twitter indicated that they would continue to use the tool.