View low bandwidth version

Archive for the ‘facilitation’ Category

Improving Trust in Teams – SPA Conference 2011

Wednesday, June 22nd, 2011

Improving Trust in Teams

I attended a session run by Rachel Davies who is an agile coach and author of the book Agile Coaching.

The session was based on how to improve trust in teams and these were my notes from the session:

Trust is confidence to Collaborate

Lack of trust is like a tax on team interactions.
Increasing ceremonies slows us down, costs go up.

Shared principles and values underlie a framework of trust.

Rachel’s trust equation

T= (c+r+i)/s

t=trustworthiness
c=credibility
r=reliability
i=intimacy
s=self organisation

We were asked to work in teams to produce a force field analysis of a situation mapping the driving forces and restraining forces acting on the desired change for Improved Trust

The results revealed that greater transparency and smaller, more clearly defined and achievable chunks of work allowed for greater sense of achievement and increased trustworthiness within a team and particularly between the team and management/clients.

Obscurity and heavy, ill defined work which is not clearly communicated creates mistrust and mysticism – particularly between the developers and business folk who start to believe that the IT are doing magical things and that what they achieve is so difficult, and even more difficult to grasp the outcomes of,  that understanding breaks down and hence mistrust builds up.

From the developers perspective, big ill defined chunks of work allow lots of mistakes and bugs to be nicely covered up with big fluffy blanket which is good to hide behind – perpetuating the myth how complicated everything is. When outcomes and achievements (whether good or bad) are regularly communicated, then any problem, issue or change of status can be isolated and dealt with,  without affecting the credibility or consistency of the team – nothing is blown out of proportion.

The outcome of the session was a poster that we had to draw in the group to demonstrate what we had learnt.

Thinking back to our Aptivate retrospective the other day I wonder if we need to work on how we write down the actions in the form of smart objectives to help us to get through them and thus aid in making them achievable.

  • Specific – Be precise about what you are going to achieve.
  • Measurable – Quantify your objectives.
  • Achievable – Are you attempting too much?
  • Realistic – Do you have the resources to make the objective happen?
  • Timed – State when you will achieve the objective (within a month? By February 2012?

What’s the difference between Open Spaces and BarCamps?

Tuesday, December 22nd, 2009

Having one foot in the world of IT and another in facilitation I keep getting asked

“What’s the difference between Open Spaces and BarCamps?”

Here’s how I described it to a good facilitator friend of mine (Julian from DecisionLab)…

“I suppose a BarCamp isn’t exactly like a pure Open Space. It’s got it’s own nuance.

For instance it’s generally not well regarded to plan BarCamps too far in advance. For no real reason in particular, it’s just not the BarCamp way.

People do prepare some stuff to take with them to a BarCamp knowing they will have an opportunity to talk about it – but they make no commitment until the day so they can change it or not give it at all.

Having people declare before hand makes it feel much more like a traditional conference and I think will discourage others from joining in on the spur of the moment.

One thing to remember about BarCamps, the big difference between BarCamps and Open Spaces is the ludic nature of BarCamps – they’re supposed to be fun and don’t have a particular outcome – they’re more like Popular Education rather than group decision making.

I think of it like this. Imagine you’re 11 years old and you and a gang of your friends are mad keen on technical lego. You’ve arranged one weekend to have a sleep-over with a lego theme. You’re parents have sorted out pizza and ice cream for everyone. Everybody brings lego with them and you take the half finished robot you’re working on. During the lego-fest the gang comes up with an idea – wouldn’t it be cool if we put all our lego together and see if we can make a bridge over the stair well.

THAT is a BarCamp. You might prepare something because it’s fun. But you’re just going along to learn, be inspired, get enthusiastic, hang out with some cool people and have a bit of a laugh.

The idea of getting people to coordinate their talks so they don’t have duplicates is I think wrong. You should have duplicates. If that’s what people want to talk about – duplicates give more opportunities for people to hear about it.”

Agile Development and Retrospectives: Learning from failure?

Friday, December 11th, 2009

I had an interesting chat with Alan last night about the role of “retrospectives” and it reminded me about the ICT4D Twitter Chat today around “Learning from Failure” being organised by the fine folks at Inveneo.

He was at the XPDay in London earlier this week – a 2-day hotbed of agile technology development geekery featuring a combination of traditional speaker sessions and open spaces.

Aptivate is a big advocate of using Agile methodologies. We see them as central to taking a participatory approach to international development. One thing we do after delivering a project is have a “debrief” or “retrospective” with the project stakeholders.

“Four key questions to focusing a community on learning and improvement” are described at www.retrospectives.com:

  1. What did we do well, that if we don’t discuss we might forget?
  2. What did we learn?
  3. What should we do differently next time?
  4. What still puzzles us?

Simple and sensible.

The key idea that Alan picked up on though was this: do a retrospective at the end of each iteration.

Every two weeks, every incremental release of a project, sit back, take an hour with your team and ask the above questions.

We’re certainly going to start doing this and from what was said at the XPDay – if you’re going to do one thing to improve your development process, do this.

Finally – ensure that all participants adhere to “Retrospective Prime Directive:”

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

Happy twitter chatting!

The UnPresentation

Saturday, May 2nd, 2009

Sitting in the audience of the Africa Gathering, a kind of unconference, I was struck by a thought – what would an untalk or unpresentation be like? (I wasn’t the first person to have this thought.)

So here’s one possible idea of what an unpresentation could be…

The rules of an unpresentation

  1. The unpresenter is allowed to start by saying only one short sentence followed by an invitation for questions eg.

    “Hi, I’m Alan from Aptivate, this unpresentation is on low-bandwidth web design. What would you like to know?”

  2. After that, everything the unpresenter says is in response to a question from the audience.
  3. The use of presentation software (powerpoint, OpenOffice presentation etc) is not allowed.
  4. If a computer and projector are used then only images are permitted and chosen in order to respond to a question.
  5. Images are chosen from a non-narrative list, like a grid view, thumbnails or file-system folder (ie. not from a presentation).
  6. Images are shown full screen with no banner, footer, logo or other unnecessary blemishes.
  7. Diagrams are drawn live.

I then started to wonder what unpresentation software would look like…

unpresentation sketch

unpresentation sketch