Weeknote 213: Braveheart


Things I have learned this week:

- searching on the Internet usually yields the answer to anything
first day of school is considerably more stressful for parents than children
– explaining product concepts to a complete stranger hones the mind

Next week: It’s Social Media Week London – why not come and join us on Tuesday Morning

Collaborative personae


You’ve got to love the Internet. Find a challenge that you haven’t come across before? Tippetty-tap on Google and before you know it you’ve found someone who has already.

And so it has been with the issues of agile approaches to software delivery in the context of collaboration tools that I mentioned earlier this week.

My searching led me to some work by a group of IBM researchers who had identified the same challenge – that agile approaches (and particularly the technique of using user personae) failed to cope with the group dynamics inherent in collaborative software.

Their work led to them defining six types of teams, which we in turn are further developing. They look a little like this:

A project team is a group of people brought together to deliver a particular product or outcome. The team lifecycle has a beginning and eventual end. Members may be there for the whole duration of the project, or for just parts of it when their skills or time are required or can be afforded. For most people in the team, their personal work objectives are aligned to the objectives of the team.

(The IBM model split project teams into stable teams, where most members were there for the duration, and dynamic teams where most members were not. At the moment we didn’t think that distinction would be helpful in our context.)

A client/supplier relationship team is a group of people from both sides of a business relationship whose objective is to facilitate good communication between both sides. An account management team and client representatives would be a stereotypical example, but such teams can exist within an organisation between operational silos as well.

A service delivery team provides an ongoing service to a client or customer with no defined end point. Such teams might work under service level agreements to provide an indication of successfully achieving their goals. Team members are likely to be relatively  stable, and the activities of project teams are likely to change the operational activities of such groups. This highlights that it is quite possible for an individual to be a member of many teams of different types at any given time.

(This team wasn’t included in the IBM model, which was derived from the study of software development teams where we are assuming there wasn’t much service delivery going on. The rise of DevOps working though sees much more software development move into this type of team structure.)

A committee is the first team type where the activities of the team are probably secondary to the activities of most of the individual members. A committee is a group that operates in a pretty structured manner to provide oversight or insight to a particular matter. A project governance board is a good example here (as separate from the actual delivery team).

A community is a (possibly leaderless) group of people who come together because of some sort of shared professional interest or cause. Secondary to day to day activity, a community is there primarily to share expertise and knowledge.

A networking relationship is a usually small (often just 2) group coming together to share knowledge on a particular topic or theme, or to seek assistance. Mentoring relationships would be a formalised example, hooking up for a coffee a less-so.

(In the IBM work this was referred to as a professional relationship).

From these groupings, or next stage is to develop out team stories that can start to articulate some of the things that they might do, to then in turn help provide examples of where collaborative technologies might help… For example, for a project team, to ensure that we successfully deliver our project we need to track the progress of tasks and activities might lead to looking at how co-authored documents within Google Drive or Office Web Apps might provide a platform.

The aim here is to both provide some frameworks for people to start to see how collaborative tools can improve a team’s working practises, and also to help identify which teams to work with in the first place.

Leading questions

I’m very lucky to live in the stereotypical leafy South West London suburb of Teddington. Close to the open spaces of Richmond and Bushy Parks, with a thriving local independent shopping centre, great schools and other amenities.

The best way to illustrate what sort of a place Teddington is is when I saw dog poo on the pavement nearby recently how someone had taken the effort to scrawl in chalk next to it the words “Shame on you!”. My initial reaction was that we must now be teaching the dogs to read around here.

Teddington really is a lovely place. Sometimes a little over-competitive, but really lovely. And with great transport links – a sedate 35 minutes into London Waterloo, and with Heathrow Airport on our doorstep.

Ah. Heathrow. The cause of much current consternation.

Generally aeroplanes take off over Berkshire, into the prevailing westerly winds that keep this country so warm for its latitude. But about 30% of the time the winds come from the East and so planes take off over London.

In the past few weeks there has been a lot of easterly wind, and that, combined with some new flight path routes that Heathrow are trialling, has resulted in a lot more aircraft nose than we are used to hearing. The people of Teddington aren’t happy.

But there is more afoot at Heathrow. Having knocked back Boris’s plans for a large pontoon in the Thames Estuary, planning decisions are coming to a conclusion in the next few months as to whether to build a new runway at Heathrow or London’s second airport at Gatwick. A once in a lifetime decision, apparently.

Yesterday in the post I received a mail from an organisation calling itself Back Heathrow. Slightly shady to it’s origins and funding (although the website does admit to it having been initially started by the airport itself) the group is a lobby organisation to support Heathrow expansion. Included within the envelope was a “survey”. The structure of the survey was of the “do you support the expansion of Heathrow or the boiling of puppies” variety that seem to be so popular amongst political lobby groups.

Doing a bit more searching, it looks like providing surprising results in support of Heathrow expansion where before there was dissent might be a specific modus operandi for Heathrow. This is no way to have an important debate.

I don’t know if Heathrow should be expanded or not. It appears that the “do we really need more airport capacity?” question has been put to bed. I can see pros and cons to both Heathrow and Gatwick growing (I spent a couple of years working on the Gatwick site a few years back and so know that area a bit too). But I also know that this leading question, PR-driven data gathering approach being used by the Back Heathrow campaign makes me not trust them. Nor the data that Heathrow produce to support their case. How much rigour has gone in to any of it, or have “find us the right answer” methods been used throughout?

In an age when information is so easily disseminated (and checked), organisations that think that it’s enough to gather false data to present their case are on very thin ice. Whilst the journalism trade might be increasingly naïve and under-resourced to print the stuff, concerned citizens can lobby back with increasing force.

The individualism of software development

I’ve been immersing myself back in the world of agile methods in the past couple of weeks, and one thing above all else has been striking me; agile methods are focused on the individual.

This is particularly notable because I’m thinking about the ways in which collaborative software could help to improve the ways in which teams can operate. Yet within the language of agile we see “customer” or “user” (both singular), but never plurals or “team” other than in the context of the development team. This seems to me to be more than semantic nicety, but much more of a fundamental issue when it comes to thinking about how groups of people might benefit from software technology.

It’s the sociologist in me speaking, I’m sure, but I see the challenges of individualistically-designed group software all around me. Take the networked diary, for example: designed on the principle of each individual managing their own time (or for the lucky few, someone managing their time on their behalf), the result is a chaotic system where because it is easier than it ever has been to organise meetings, so many of us spend all of our time in meetings wondering what we’re supposed to be doing there.

A team approach to the challenges of time management wouldn’t start with the premise that my time is mine to manage but would balance the requirements of team, individual, and ultimately the productivity of the group as a whole. I’m certain it wouldn’t look like Outlook, or Google Calendar or any other of these desk-diary metaphor systems that have become the bane of so many working lives.

Or take email – the triumph of individualistic software interface design over group reality, or “the to-do list over which you have no control” as I once heard it put (if you happen to know the source of that marvellous line, please do let me know).

Email starts with some user stories along the lines of “I want to send messages to someone else” and goes downhill from there.

The opportunity here isn’t in “re-imagining” elements of these services into a more modern, Cloud-centric, app-enabled world. The opportunity would come from people sitting down and working out the group dynamics of how teams operate and starting from that point rather than from the individual. The problem is that quite quickly our development methodologies compartmentalise things down to the individual, the user or customer,  but unfortunately collaboration is a team sport.

Weeknote 212: limits of agility

Things I have learned this week:

- that the boundaries of where agile is good and agile is bad are very unclear
– being based in London for more than a couple of days a week makes you bump into people you know
– coding is the developer’s hammer to a world exclusively of nails
– clearing a drain is a remarkably satisfying thing
– the obvious often isn’t to others

Next week: my eldest starts school. Where did those five years go? Oh, and final push for our event on the 23rd- come along!

Who’s watching?

So the much-hyped Apple product launch event came and went. A couple of new (bigger) phones, a payment system and a new album from a bunch of has-beens. Oh, and a watch.

Apple Watch. Not iWatch because someone else bear them to that brand. A new “form factor-defining” product from Cupertino?

Now let’s be clear here, I didn’t think the iPad was going to change the world. In fact, given recent sales figures I’m still not entirely sure. What about wrist-based computing? It’s going to be interesting…

On the one hand, if anyone is going to make smart watches work, you’d be foolish to not bet on Apple. iPod, iPhone and iPad have all been dramatic commercial successes. They don’t always hit, though: Apple TV seems to get forgotten, and for good reason.

But smart watches are not new form factors that are purely competing with older computing forms. The wrist is a piece of body-estate with plenty of existing cultural value and significance.

We don’t need traditional watches. Many people have stopped wearing them as their core function, telling the time, is replicated in so many places in our multi-device world. But at the top end of the market, people aren’t wearing watches to tell the time. Watches are jewellery that are telling others about the owner.

And here is one of the two challenges that I see for smart watches generally, and for the Apple Watch in particular. Much of Apple’s schtick is around stylish, desirable objects, not technology. How will they compete against some of the most luxurious brands in the world in the battle for the wrist? An expensive watch isn’t a beige box.

And whilst you could argue that expensive watch-wearers aren’t the target market, they have been for the successful products that have gone before. Can the Apple Watch succeed in being an aspirational product without being on the wrists of the Tag Heuer set?

The other cultural factor at play with smart watches is the significance of looking at a watch. If you’re with someone, a glance at your wrist sends a message. Often “you are boring me”. That’s a lot to unlearn.

Now that might look like a tiny, insignificant thing. But it’s exactly those kind of tiny things that can prevent or hold back the adoption technology for years. We’ve have video conferencing, for example, for years. I’m certain that it’s the psychological factors (people generally don’t like seeing themselves on screen; conferencing usually has many that eyelines are wrong with participants looking slightly off-camera that makes them appear untrustworthy) and not the technology per se that have held it back.

Apple Watch is a neat bit of kit. It’s not clear what you would use it for, but that was the same with many new technologies. The big questions for me are whether Apple can overcome these cultural issues to make the product more than a brief interlude before the next significant form factor comes along.

Upcoming events


I’ve a few events coming up in the early autumn…

On September 23rd I’ll be taking part in an event organised in conjunction between IG Digital and Zoodikers to launch the report on the research project I conducted for IG over the summer on the use of social and digital channels in customer engagement. The report covers the results of interviews with 65 organisations, and paints a picture of the state of social customer engagement in 2014. Sign up for the event for free (it’s part of the broader Social Media Week), and you can also register here to get a copy of the report when it’s released on the 23rd.

On September 24th, I’ll be doing a Webinar for The Marketer, again on the results of the IG report, but from the angle of increasingly personalised marketing. You can register for that one here: http://view6.workcast.net/register?pak=1052539446511225

In October I’ll be speaking about the IG Research, and also my ongoing Social CEO project at the Social C-Suite Meetup. Organised by Damian Corbet, you can register for the event for free here.

Matt Ballantine's thoughts about technology, marketing, management and other stuff…


Get every new post delivered to your Inbox.

Join 1,821 other followers

%d bloggers like this: