View low bandwidth version

Archive for the ‘agile’ Category

Jazz Talking: The Agile & Participation Event

Wednesday, September 28th, 2011

Robert and Alistair

For a while I’ve felt that the Agile methodologies from the software development world share a similar outlook to the Participatory methodologies from the international development world.

So we came up with an idea for an event. Wouldn’t it be great to get an expert from each discipline and have them talk to each other, in front of an audience?

Last night, thanks to support from the Humanitarian Centre, and our two esteemed guests, our idea became reality.

Alistair Cockburn, Agile guru, sat on a sofa next to Robert Chambers, expert on Participatory approaches, in front of an audience.

I thought it was fantastic and we’ve had a lot of positive feedback about the event. It was so good, I found myself afterwards wondering if this is in general a good format for an event.

So I wanted to write a post about the form of the event, rather than the content.

After the event I was chatting with Alistair and he’d already been thinking along similar lines. We called it a “Jazz Talk”. We were drawing an analogy with two jazz musicians improvising.

Jazz Talks

Here’s the format -

1) Get two affable speakers from different disciplines
2) Sit them on a sofa in front of an audience
3) Let them talk about the relationship between their disciplines
4) Periodically interrupt them with “Kibitzers”

Kibitzer

A “kibitzer” is a person who comments on the conversation.

“Kibitzer” was a term Alistair came up with. I had to look it up, literally it means an observer of a card game who gives (unwanted) commentary.

There’s two types of Kibitzer. A “content kibitzer” gives comment on the content of the conversation. In the event last night I played the role of one of the kibitzers and asked the question “How do we get funders to engage with agile / participatory proposals?”.  All of our kibitzers last night were content kibitzers.

Talking to Alistair afterwards, he was keen to push the idea of a “form kibitzer”. This is someone who gives a commentary on the form of the conversation, not the subject matter. For instance, “I liked how speaker-A extended speaker-B’s questions to the audience”, or “Can we hear more from speaker-A?”. I think form kibitzing is less natural but likely to be shorter. It also potentially plays a facilitatory role in guiding the conversation and could help address issues like one speaker dominating the conversation.

Perhaps a mix of both types could work. Each commentary would start with a short form kibitz followed by a content kibitz.

Timing

Here’s a suggested recipe:

  • a 90 minute conversation
  • kibitzing every 15 minutes (eg 5 interruptions)

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?

Solar Diaries – Day 5 & 6 – Behaviour Modification and Diet Failure

Saturday, September 18th, 2010

Day 5

A cloudy day. This is one of the interesting things about taking responsibility for my electricity production – it’s not just that I replace the electricity I used to use. The awareness I am getting is modifying my behaviour.

I generally think of myself as someone who tries not to waste energy. I turn lights off when I leave rooms etc. But trying to run my working life off an under-dimensioned solar power system is being a real education in energy wastage.

Today I’m having the usual one hour lunch break. Normally I would probably leave my computer on. Today I don’t even suspend the laptop, I shut it down completely… and unplug its 12 volt regulator. I want to see 0.00 amps flowing out of the battery when I’m not using it.

I’m also aware that I’m starting the day with a fairly empty battery and it’s cloudy – so today I’m not using the external monitor…

(time passes)

…I got through the day but around 5pm the solar charger shut down the load to protect the battery from getting too flat. So I worked the rest of the day, up to 6:30, using the internal battery of the laptop. By the end of the day I’ve got 10 minutes battery left on my laptop, about the same on the Samsung / PixelQi netbook and a shut down deep cycle battery. Hmmm. (I’m actually writing this blog entry on Day 6 because I ran out of power on Day 5)

Day 6

The forecast was for sun this morning, potentially worsening through the day. I’m starting the day with an empty solar battery and no reserves on the laptops. I have to get up early (early for me anyway, if not early by international standards) to get the panel out. At a push, the sun starts being usable from about 8am so I’ve got 2 hours to get enough charge on the battery.
PV Panel out the front of the house

Luckily, yesterday evening, the 15m extension cables for the PV panel arrived so I don’t have to lug the battery around. I start by dragging the panel upstairs to the east facing bedroom to try and get the early sun. By the time I’ve got it all plugged in the sun’s rising high enough that it’s hitting the doorstep out the front. I take it down there instead. The panel’s bigger than any of the panes in our windows so there would always be a shadow from the window frame which would seriously reduce the power output.

As the minutes tick by I’m glued to the multi-meter watching the voltage slowly climb, repeatedly running out the front, rotating the panel to face the sun. (There is some debate about whether it is better to spend money on mechanical trackers or on more static PV panels instead. However manual tracking is free… if a complete pain in the back-side.) It gets to 10am, time to start work, and the solar charger is still disconnecting the load. I use my last few minutes of laptop battery to skype in to the office for the morning meeting and then, with a sad face, I plug the laptop into the mains. I’ve broken my mains-free diet. And what’s even more irritating is it’s a gloriously sunny day. There’s probably enough power coming off the PV panel to run the laptop directly, but I’m not set up to do that… yet. Digital-Resilience #fail.

I’m hoping the battery will get enough charge over the weekend to see me through next week. Until I’ve built my office-cum-shed with the south-facing roof in the garden, I’ve got nothing to attach the PV panel to in a permanent way. We’re away for the weekend and I’m worried the panel might go for a walk if I leave it out in the garden so it’s currently inside standing vertical against a west-facing window. Knowing the PV panel is less than optimally placed is taking some of the joy out of the fabulous sunshine we’re having today. I did try and persuade the family to bring the battery and panel away with us. They think I’m obsessed. Luckily for family relations the panel is too big to fit in the boot of the car and the battery is too heavy to carry on the train.

If I make even more gridbeam I could, in true agile fashion, just make the roof of the shed.

Mobiles for Scientific Research

Friday, July 9th, 2010

We know mobiles are very useful in areas where desktop computer and communications infrastructure is not easily available or affordable. And we’re very interested in mobile applications and scientific research in exactly these regions.

So I was very interested to see a new training workshop being run by the Science Dissemination Unit (SDU) of the Abdus Salam International Centre for Theoretical Physics (ICTP). The workshop is on Mobile Science: Sensing, Computing and Dissemination and the deadline for applications is tomorrow, July 10th.

Quoting from the announcement:

The Science Dissemination Unit (SDU) of the Abdus Salam International Centre for Theoretical Physics (ICTP), with the assistance of the University of Washington (USA) and of the UCLA Centerfor Embedded Networked Sensing (USA) will hold a Workshop on “Mobile Science: Sensing, Computing and Dissemination” in Trieste (Italy) from the 2 to the 5 of November 2010.

Mobile applications offer tremendous benefits to academic research and
education, and to society as a whole throughout the world. This is an
opportunity that deserves attention and promotion, especially in less
developed areas where mobile phones are the first telecommunications
technology in history to have more users than in the developed world.

The specific things that interested me were:

The Mobile Science workshop aims to engage the scientific community in developing countries in the design, development, and deployment of the newest mobile scientific applications;
i.e. advocating appropriate mobile applications in scientific
research/academia;
Participants will learn how to apply mobile technology tools to retrieve scientific data
I.e. designing mobile apps for science data collection;
how to apply appropriate web-based analysis to assimilate mobile data into scientific studies
I.e. web-based statistical analysis and presentation, like a free online version of SPSS? As far as I know this doesn’t exist yet. The closest that I can think of is the Google Docs spreadsheet, which is of course just a spreadsheet, requires an internet connection and doesn’t allow plugins for additional scientific analysis functionality. But there could be a very interesting app to develop here.
and how to share their scientific findings with a potentially large mobile audience.
I.e. low bandwidth design with an emphasis on web standards for cross-platform compatibility, so that it works on the largest number of mobile devices.

If you want to apply, better get on your bike (or modem?) because the deadline is tomorrow. If you want to do mobile scientific research applications, please get in touch, we’d like to help you.

Aptivate Speaking at Africa Gathering, London

Tuesday, June 22nd, 2010

africa gathering logoI (Alan) am going to be talking at Africa Gathering London about the reciprocal relationships between participation and IT.

Here’s the synopsis… (although Africa Gathering has previously been described as an “unconference” so I may be tempted to slip into a bit of “unpresentation” if the situation warrants it).

The reciprocal relationship between ICTs and Participation

Over the last few decades of software engineering there is a rising tide of emphasis on the value of participation. The growth of the “Agile” software methodologies is a good example. The finding, which really shouldn’t be that surprising, is that participation makes better software. Participation with the client, with the users with the
stakeholders etc.

Seven years ago, at the start of Aptivate, that’s how we saw participation. As a means to creating better software. Over the last year we have seen that relationship reverse. IT is a means for better participation. It’s not just that new technologies like web 2.0 enable people to collaborate. Engaging in software projects themselves are excellent excuses for participation and human development. Finally, the dog is wagging the tail again and not the other way round.

Africa Gathering will be in London on the 2nd and 3rd of July. Get your tickets now while there’s still some left! For more information see the Africa Gathering site.

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!