Learning to teach online:what do you think?

Someone emailed me today to ask what trends I thought were emerging that us trainer/consultant/wanderers should be taking notice of.

Two trends I have been noticing that are both scary and exciting to me are

  • People are making knowledge and ideas available for free.  This blog includes some of my trade secrets in the hope that they will be useful to others.  But that is nothing compared to MIT publishing entire course curricula online or the sheer volume of free information you can get in wikipedia, youtube and other places;
  • People are increasingly interacting, doing business and learning online. I did my entire masters degree online and yet even that experience was pretty mundane compared to the emerging opportunities that are emerging – youtube based videos, ebooks, Secondlife (yes – I still think we can do a lot of training in 3d worlds) and even mentoring by Skype and twitter.

Continue reading “Learning to teach online:what do you think?”


Agile governance and the problem with measuring self-organising teams

I have been in some interesting conversations recently about agile development teams and sound organisational governance. 

One of the challenges faced by organisations is that the traditional measures used to monitor and control teams are not necessarily suited to the style and approach of agile teams, while agile approaches may seem to remain silent on, or even discourage, the outside governance of project teams.


Fortunately this is not a new problem and people have been discussing it since self-organising teams (or work cells, or self-managed teams) first appeared in management theory.

Continue reading “Agile governance and the problem with measuring self-organising teams”

Er .. um … is co-locating a team bad for projects?

I had a really challenging question in a training course recently. 

I normally like these because I get a chance to say “good question, hmm – what do the rest of the group think?”.  Then I sit back and learn from the group.

This time the question stumped all of us though so my initial response was “what, no not really, er, yes but also … hmmm”.

Here is the context and the question.  We had been discussing self “organising teams” (teams that take accountability for their own decisions rather than being told what to do"). 

I said that “colocation” was important but not always possible. In other words I said that the best way to run any project that involves human beings is to have them sit together (or stand together) in the same place at the same time. That was they stumble on more issues earlier, they build trust sooner and they can make important decisions faster.

We all agreed that this was the case. But we also agreed that it is not practical to be sitting in the same place at the same time on all our projects. But rather than just accepting that “unco-location” was going to happen we should treat it as a risk and actively discuss how to mitigate the communication risks and impacts of not sitting together (Essentially I would call a lack of colocation one of the “falling coconuts” on many projects).

So far so good.  But a little later we discussed the theory of the “Wisdom of the Crowds”.  This is the theory that in the right circumstances the group is smarter than any individual in it. 

During this section of the course we discussed what would lead to the group being smarter than anyone in it and what would undermine this.  We covered things like group think and egos as constraints and then discussed some key success factors.

We discussed the importance of bringing different skillsets, biases and personal histories to the team.  So I mentioned that if I was going to role a project out to every state in Australia I should not just involve Sydney people on my project but also people from Hobart and Perth office (for example).

So .. .the question then arose – If you bring these people together they will be co-located.  But won’t they become out of touch with their own office?  In other words if you co-locate the team won’t you lost the diversity of having people in different areas of the business experience the project as their home team will experience the new product?

“Well”, I said, “I guess we should do additional testing then”.  But then the follow up question got me – wouldn’t it be better if you were doing a national or international project if the people on the project were immersed in the different locations where the project will be deployed.  That way they will learn first hand and be able to contribute more diverse views to the team who might otherwise lose this “wisdom”.

“Er, um”, I responded, “colocation good, unco-location bad”.  But then the real answer hit me.

If we co-locate we might be losing our exposure to the challenges, opportunities and diversity of each location.  So co-location is good in that it improves communication and bad because it may (does?) introduce a new risk – losing the valuable input of the home teams that will eventually (or hopefully regularly) receive the benefit of the project.

So I guess now I am unsure – is there a legitimate argument that NOT locating the team together might produce a better outcome than locating them together?

Risk outrage – look out for falling coconuts

A participant in a workshop alleged that coconuts are more dangerous in some parts of the world than sharks. Apparently he has seen statistics showing that in the South Pacific there are substantially more deaths related to falling coconuts than shark attacks.

So at a typical resort by the beach, people will be worried about sharks when in the water, but be quite relaxed about sitting under (a potentially lethal) coconut tree.

I guess sharks are a bit  scarier than falling coconuts. Many of us have seen Jaws but nobody has yet agreed to film my script for “Coconut Apocalypse” where a resort tries to cover up the rising fatalities caused by a new heavier and more lethal variety of coconut. Indeed I have never seen a horror movie about plunging nuts of any kind.

This is a specific example of something known as “Risk Outrage”.  The amount people worry about a particular risk is not always related to the danger posed by the risk. Rather it is often related to the outrage in the media last time it happened or the grumpiness of an executive 3 years ago.

And in addition to causing people to fear death by shark more than death by coconut it also results in projects spending inordinate time and money mitigating one risk while ignoring another risk that the team know (in the back of their minds) is already impacting them.

For example they might ignore the likelihood of a restrucuture or a lack of DBA’s because they seem so likely. These are like the “project coconuts”.  At the same time they might panic about dropping a feature or about the business changing their mind.

We all know that part of the project manager’s job is to monitor  the likelihood and impact of different risks. But I think the PM should also be monitoring risk outrage.

This then becomes a communication exercise – calming people down when they are panicing about sharks and raising the outrage people feel about “deaths due to coconuts”.

One way to do this is to measure it.  You may be familiar with the risk likelihood and impact graph:

But if you want to increase (or decrease) the focus of the team on a particular set of risks compared to others, you can graph risk against focus. Or if you want to remind the product team that a risk will have a seemingly low impact but will actually really annoy stakeholders or customers then you can graph “risk as likelihood and real impact” versus “likely outrage” if it does blow up:

So now I am going to claim that the PM must not just make sure that risks are recorded correctly, but more importantly that the team focus on the greatest risks and not just the most glamorous or extreme.  In other words if a restructure or competitor release occurs every project, then the team should actively monitor and mitigate this, as opposed to just ignoring it because it is so common as to be mundane.

But now I am going to add one final point.  The PM should also be monitoring the potential outrage (reaction) of customers and stakeholders and actively working to make bad outcomes more palitable, perhaps through public relations, scenario planning.  And he/she should be getting people to stress more about seemingly absurd (or more often “Unmentionable”) risks, perhaps through public relations, advertising, scare campaigns, statistical analysis or scenario planning.

What do you think – is PR and scare campaigns to get people to worry more about falling coconuts and less about sharks good project management, playing politics or crazy talk?

Talking about retrospectives on another blog

I was running a course on “facilitating workshops in agile projects” when some of the crew asked what different questions they could ask in retrospectives (instead of just “what worked and what didn’t).

We got talking about the retrospective at the end of a project.  So I published a story of sorts on how to run a retro for 70 people at the end of a project.

At the end of the discussion I promissed to publish some of my comments so I put them together in a short story about running a retrospective.  You can read it hear if you are interested: