busoto is collaboration

build something together

In 2011, and again in 2012, while preparing to cofacilitate with Ric Phillips1 a workshop about collaboration across an enterprise-architecture community of practice, we were reminded with jarringly clarity that the word collaboration is misunderstood and misused, and that unhelpful behaviours result from this misunderstanding and misuse.  Under the banner of collaboration are in fact three broad classes of behaviour:

  1. Connecting
  2. Sharing
  3. Collaborating

…and the expectations upon participants and on the elements needed to support those behaviours vary greatly from one broad class to the next, as:

  1. Connecting is simply establishing and in some way monitoring connections between people in environments such as LinkedIn and, to a certain extent, Twitter and Yammer.  Connecting gives rise to ambient intimacy2 — knowing what is happening, knowing something of what your peers are doing.
  2. Sharing is making available to others some or all information, decisions, and other artefacts (e.g., strategies, templates, documents, diagrams, code) that are generated by doing work. Sharing can be mediated by websites, blogs, Twitter, and so forth.
  3. Collaborating is the deliberate cooperative creation of something new: new products, new artefacts, new understanding — in any form, new value.

Selected good definitions of collaboration include:

  • two or more people working together towards shared goals3
  • creative coordinated goal-oriented4
  • working together to achieve a goal5

…and three random examples are offered below:

  • busoto is a new portmanteau of the phrase build something together, illustrated by the drawing at the head of this post, which my five-year-old daughter and i built together deliberately.
  • Wai Notes6, 7 is a music album containing early/demonstration versions of songs that were recorded by Will Oldham and Dawn McCarthy by exchanging tapes in the postal mail.
  • A group of architects from different organisations obtain local sponsorship to work together to define and create business capability models for their sector.

Collaboration, busoto, is a deliberate and identifiable behavioral style.  It builds upon, depends upon, and is a higher form of connecting and sharing. Communicators and collaborators must acknowledge and stay actively aware of the difference between connecting, sharing, and collaboration.

  1. Ric Phillips and his excellent eapatterns blog at http://eapatterns.tumblr.com/
  2. Ambient Intimacy coined and defined at http://www.reboot.dk/page/1236/en
  3. Ephraim Freed’s August 2012 post What Collaboration Really Means at http://www.thoughtfarmer.com/blog/2012/08/14/what-collaboration-really-means/ includes a useful list of behaviours often confused with or labelled as being collaborative, but that are not collaboration.
  4. Jane McConnell’s May 2012 post Clarifying the word “collaboration” to reduce confusion and conflict at http://netjmc.com/social-collaboration/clarify-to-reduce-confusion-and-conflict includes some helpful models indicating how collaboration fits into the digital workplace and other work and organisational patterns, alongside intranet/content and people-connectedness.
  5. The wikipedia definition at http://en.wikipedia.org/wiki/Collaboration
  6. Wai Notes at Drag City http://www.dragcity.com/products/wai-notes
  7. Wai Notes at Wikipedia http://en.wikipedia.org/wiki/Wai_Notes
Advertisements

Anti-Collaboration and the Hungry-Hippo Secret-Society

hungry hipposTrapped inside their plastic bubble-land, committed forever to competing for access to worthless inedible coloured plastic baubles that represent to them a measure of status, members of the hungry-hippo secret-society collaborate in isolation from the world around them, waiting for their plastic environments to be exhalted as wonderful contributions to the mission, the project, the policy, the business requirements, the strategy, or whatever it is these self-professed dippy maven-muppets believe they are achieving without consultation, without reflection, and without harnessing the power and good intentions of the collective.

These hungry hippos keep personal copies of their work in secretive locations, sharing only with the annointed few and the hierachico-politically-expected ones, those whose acknowledgement and annunciation they crave, and whose places they one day long to occupy by right of gift, devotion, and secret pledge.

Other hungry hippos that work this way are simply terrified, or wanna-be perfectionists, or incompetent.

From both camps, the disruptive and mischevious enterprise architects that manage to prise away DRAFT-watermarked embargoed final copies of the hippo’s work receive these gemmy gifts with form-letter strongly-worded warnings, such as:

  • please do not distribute this document any further, not to anybody else, as it is still under discussion by the team, and if this gets out before it’s been signed off then we are going to be punished heavily, especially you!

This is patent nonsense, and exactly the opposite of what’s needed: the sooner these works are distributed and visible widely, the better is the result for the initiative at hand, for the organisation involved, and for the World.

These hungry hippos must be stopped, counselled, and taught to collaborate using wiki, coauthoring, and socially-enabled tools.  As it stands, they’re routinely and repeatedly turning out expensive substandard frog-in-a-well constrained work as finished art, too late every time to undo or avoid.

Tear down the walls of the hungry-hippo secret societies!

Experience Mapping vs Heavy BRUF

Design Workshop Participants

After spending three months alone in a windowless-but-air-conditioned office, the business analyst emerged with a two-hundred-page document of business, functional, and non-functional requirements.  A short time later, her contract concluded, the document was discarded because it was useless — it was useless and it was very expensive.

As part of understanding how to balance precision with effort, i’ve been trying to emphasis the need to use flexible and rightsized analysis and design techniques throughout the lifecycle of doing anything, though especially at the early-lifecycle stages.  In this context, “anything” is a change arising from formal portfolio, programme, and project work equally as it is a change arising from an innovation, an experiment, or any other initiative.  There are several reasons for why i’m keen on this approach:

  • Energy-Efficiency #1: Environments that are even remotely innovative or innovation-feasible won’t be afraid to commission measured activities that don’t progress beyond an early-lifecycle stage.  Committing the full raft and menance of the academic energies, economic resources, and opportunity-time needed to establish big-requirements-gathered-up-front guarantees either a lot of waste or a lot of bad initiatives going ahead for bad reasons like pride-protection.
  • Energy-Efficiency #2: Even the most-staunch waterfall-process delivery shops understand that the big-requirements-gathered-up-front never contain actionably-guaranteed specifications for what will actually be created when the initiative is complete.  Starting with high-level, with really high-level, indications of the business and functional requirements and the solutions design sets the culture and the expectation that not everything can be known up front, and that the final solution will be approached iteratively and collaboratively.
  • Outcome Quality: When achieved in the open with multidisciplinary collaboration, design outcomes benefit from receiving input out of several perspectives.  From an architectural perspective, this helps to ensure a suitably-wide context is maintained, and that the delivered outcome has a chance of being change-friendly.
  • Social Efficacy: Early, deliberate, meaningful, sincere involvement of team members and stakeholders generates understanding and buy-in and reduces ramp-up time for later-scheduled activities such as development and quality-assurance.  Kicking off a design process by dumping a two-hundred-page requirements document establishes a “there it is” perspective that sets a path-determined course of events in motion that disempowers everyone involved.
  • Enjoyment Factor: Capturing requirements, defining processes, and designing solutions should be enjoyable, challenging, stimulating, fun.  Increasingly, the ability to work together and communicate ideas using storytelling techniques is becoming a valuable domain skill for enterprise architecture.

Using photographs of sequence, context, container, and component diagrams  hand-drawn on large whiteboards during discovery/design workshops the initial passes through the requirements and the solutions design can be captured effectively and enjoyable, and those initial artefacts are highly-consumable and serve to seed more-detailed representations that evolve as they are needed.

Taking this a step further, i’m interested in exploring the creation of an enterprise-architecture toolkit based on the snowboarder’s shared-experience mapping toolkit described by Luke Pittar in his post “Experience mapping – Design Research” at http://lukepittar.com/?cat=4

The snowboarder’s shared-experience mapping toolkit:

  • …contains a range of magnetic icons and whiteboard markers, each representing an aspect of the skiing/boarding experience. The playful look and low-fi nature of these contents encourages people to interact and play freely with them, marrying them together to create scenarios that shape stories or represent their days experience.

…and i think this style of designing together can improve the experience, increase the participation, and make more fun from the current whiteboard-only workshops for design that i’ve been using — so  i’m going to start collecting suitable component ingredients for an enterprise architecture design toolkit, and see what happens.

Halal Butchery, Feature Management, and Conceptual Design

Back in late October we enjoyed a visit from Brian Prentice, a Gartner Group analyst whose areas of specialisation include intellectual property, conceptual design, open-source software, social computing, and service-based delivery models (e.g., cloud computing, software-as-a-service, and platform-as-a-service).  Over a couple of hours a lively discussion ranged across most all of those specialisation areas, and although the session was now a couple of months ago there are aspects of it that have stuck with me, particularly around the adoption of conceptual design to the application-development life cycle.

At his Gartner Group blog Brian Prentice offers a definition of conceptual design as:

  • a basic foundation that defines the structure of the solution, including the functional elements of the product, their relationships, and the system behaviour.

…and great things come from an approach like this, which emphasises the creation and delivery of greatly-usable individual function points: think of Google Search (which Brian Prentice points to as “a triumph of whitespace”) and Twitter.  When the introduction of additional functionality starts to degrade the experience for a large-enough proportion of users, you’re probably dealing with a new product that should be developed independently and integrated across function points to provide highly-usable, highly-scalable composite applications.  Organisations such as Google capture and monitor metrics on the use of features introduced into their applications and drop features that fall short of what’s needed to keep them going.

Thinking recently about conceptual design and the introduction and management of features and functions while waiting for a bus, i noticed this sign in a butcher-shop window:

…apologising for the introduction of a new service feature.

Invitations, Etiquette, Presence, and Meetings

There have been a couple of occasions recently where i feel i’ve behaved poorly by virtue of being a bit ungracious and a bit reactive when invitations i’ve issued to meetings and workshops with to carefully-constructed memberships have been forwarded onto other potential attendees.  i’ve been thinking about this a fair bit lately, and about the constructive-vs-avoiding-vs-aggressive dimensions our local departmental culture has been scrutinised under with the corporate-psychology industry’s tools from Human Synergistics International.  This thinking has not led me to any reconciliation of behaviour, feelings, and constructiveness, but i can offer the following points:

  • Technological Controls:  The cursory searches i’ve made to find ways of stopping people from forwarding Outlook/Exchange meeting invitations to other people have led to a dead end (for example, here’s an eggheadcafe question-and-response on the topic), though it does look like Google Calendar supports options around forwarding permissions.  However, it’s completely clear that breaking away from the enterprise calendaring system is neither a good nor a teamly option, and there are anyway remaining questions about interoperability with all the Outlook users and the persistent likelihood that word-of-mouth and other avenues will remain open for uninvited guests to arrive.  Technological controls don’t seem to be the answer.
  • Behavioural Controls: When raising meeting invitations i’ve starting trying to make it as clear as possible whether the session is open to all comers, welcomes suggestions for additional attendees, accepts substitute attendees, or is strictly intended only for the addressed invitees.  This is proving to be only slightly successful, and i’m unconvinced that it’s for the right reasons.
  • Connectedness and Representation: Increasingly, i’m feeling suspicious that my perceptions of the style and extent to which other people are connected with their communities (their department, project team, cubicle neighbours, other participants in their business processes, etc) and the style and extent to which other people are empowered, willing, and able to serve a representative role in a solutions-exploring-consulting context are quite different from reality.  There’s no sense here of better or worse, it’s just a difference that i’m trying to understand and learn to better navigate.
  • What’s The Problem?: There’s also the possibility that our organisation should become much more organic, and we should run the whole of our information-technology-as-a-business operations like a gigantic rolling unconference supported by whiteboards and user stories and innovations and experiments and research and proofs-of-concept and amoebic, shifting groups of highly-motivated people.  Throwing away the book, heaving off the shackles of hierarchy, abandoning financial-calendar-based budget-driven short-term strategic planning, and leading ourselves into the future together!  In other words, maybe the concept of a meetings and of projects should be replaced by lots of needs-based collaborations, and everybody becomes welcome to participate in everything.

Meanwhile, i’ll continue amending my behaviour and work on being more gracious and less reactive when meeting invitations get forwarded around.

Watercoolers, Protectionism, Productivity, and Meatspace.

i’m providing up-to-half-of-full-time enterprise architecture consultancy to a major effort that will see the really-old PeopleSoft Student Administration 7.6 environment at my site upgraded to become the latest-available really-new PeopleSoft Campus Solutions 9.0, and it’s a large project with about sixty people working together in one spacious floor of a commercial building that housed previously a call centre, so there are lots of windows, and it’s quite open-plan, and there are network ports everywhere (but the network is really slow).

In some ways i’ve struggled with the transition from long-running core-relationship mode to project-context mode, and i’m wondering if some of the resistance from the wider project team to the mention of social networking tools like Twitter, Yammer, wiki, blogs, and Google Wave is more about the shorter-term scope of the monstrous and pressing tasks the team faces.

Where a community is unaccustomed or resistant to social networking (and the individual reasons range wildly from fear of recrimination for saying something silly, to not understanding anything of the value proposition, to feeling too busy to participate, to outright believing it’s a waste of time) i’m unable to rely upon the ambient intimacy that informs many/most of my relationships. This also means that core messages, and core advice, are being sought through and are able to be provided by only traditional channels such as email-mediated and meatspace-mediated interactions, neither one of which is:

  • social/public
  • challengeable/addressable
  • replayable/documentary
  • updateable/commentary

To address this, today i spent the first of my at-least-half-a-day-a-week working in-person on the floor, seeking to establish and engage in the watercooler interactions that are missing in this context. It’s a broad open-plan workspace, and it’s very different from the small and quiet and intense and ordered office of ten people where i normally perform deskwork. The experience was interesting:

  • the dividers between desks/cubicles are at least a foot lower than i’ve experienced before, so i found myself for the first hour or so working with my head forced down near my laptop, avoiding exposure and eye contact and trying to give others privacy
  • there’s a lot more noise than i’m accustomed to, though most of it is the sound of industry, and it felt kind of good to be exposed to it, though it felt simultaneously like i was trying to work in a cafe or an airport lounge
  • there’s a lot on my plate at the moment, and it’s hard to knuckle down and be productive and concentrate on and plough through pressing work (and, as a visitor placing myself in the environment in order to be more directly accessible, it wasn’t appropriate to do the headphones thing)
  • talking with people is very productive, and can resolve/explain/mentor/correct/demonstrate/challenge/assist much more quickly than with traditional remote interactions…
  • …but there’s nothing left behind, so behaviours such as the email-to-wiki pattern are invalidated, not least because we no longer enjoy a strong story-telling oral culture

i’m going to spend a lot more time up there on the floor within the big project team, and i’m left with the feeling that the limitations and downsides are chiefly my own, and it’s something of a personal challenge to overcome them, at least for my half-day-or-so each week in the environment!

Collaboration and Freedom!

Ahead of the weekly whole-of-project-team meetings for a big project at my work there are about fifteen people who have to update the same Microsoft PowerPoint presentation in the SharePoint-powered EPM Server, and it’s proven to be an incredibly frustrating exercise because: there is no support for concurrent authoring, so it’s strictly one-at-a-time and first-in-first-served sometimes an author thinks they have a timeslice with the presentation, but somebody else is working in there too, and updates get lost/overwritten like all normal people, most of the team leaders leave the updating of the presentation until the last-possible moment, which means we end up with fifteen people trying to update the same file over a very hotly-contested brief window of time.

My solution has typically been to update a local copy of the presentation and then email it to the brilliant, long-suffering, and always-tolerant project administrator to fold my slides into the main deck right before the presentation happens… but that is not a good solution, and in thinking of a Better and Fairer Way i was reminded recently of three things: the great fun that was had using Google Docs to collaborate in the closing phases of preparing the Identity and Access Management Strategy, during three of us were updating the strategy document concurrently. It was spooky seeing text changing on the screen both in the paragraph where i was typing and in the paragraph above, by another’s hand!

After a recent Tech Drop talk i attended at which a New-Zealand-based Google engineer who’s been working on the cutover of 2,000 employees from Microsoft Office to Google Docs i found that it was incredibly easy to upload a PowerPoint presentation into Google Docs (we’d done this before, but only experimentally).  So i’ve tried this out with the big project’s presentation for the weekly meeting, and:

  • …and the freedom of being able to update this presentation from anywhere, with any web browser, concurrently with other users, collaboratively, is really a joyful and good thing! Disclaimer: i’m really and honestly not a Microsoft basher, though that’s probably a topic for another post.