Scandinavian Agile 2008

Yesterday, I attended the first ever Scandinavian Agile conference, in Helsinki.

The event was going to be limited to 200 participants, but there was enough demand that there were over 250 admitted in the end. The event ran smoothly, with the sessions starting and ending on time and regular refreshment of the refreshments; every time you came out of a 'session', there was something new on the tables outside.

There were three tracks:

Awareness

Practitioner

Open space

I took advantage of the ability to flit between them. Before any flitting occurred, there was the keynote speech by Gabrielle Benefield of Yahoo! affiliation.

Gabrielle Benefield

Gabrielle's presentation was a rather general overview of what it is like to convert teams in a large organisation to agile. She surveyed the audience beforehand and found that all but six already used agile practises in their daily work. Despite this, the session felt very much like a primer speech. Perhaps she did not expect quite so many people to be practising agile already. This seems strange, because she quoted statistics concerning how widely used agile practises are in the Nordic countries.
There was a lot in Gabrielle's speech about overcoming resistance: spreading the word about agile; encouraging people to take it up; calming people's fears; taking advantage of people's desires; generally using political tactics to smooth your way. I imagine the advice was useful for many people, but I am pleased to say that I am not in a company where much of this is required.

Bjarte Bogsnes, A journey beyond budgeting

I was not too keen on the format of the presentation. It was a little rushed at the end due to too much detail about motives and the underlying philosophy in the beginning of the presentation. However, there were some key points made, and some of them were about Key Points - Key Point Indicators, or KPIs.
One central theme is that companies have to stop using KPIs as Key Point Incentives or as a power and control tool to force people to act in a certain way. This was especially true if a company also tried to do the same through personal incentives. KPIs should be used as the indicators they are; they should be the intermediate point between the goals that you wish to achieve and the actions that you know will (most likely) achieve those goals. A KPI should be a checkpoint: are you doing what you need to do to achieve the goal?
This tied in with the 'league table' theme. I call it the league table theme, because it was an analogy Bjarte used very effectively. Instead of setting a goal to reach a certain performance value, set a goal to reach a certain relative value: football teams do not try to score the most points in a season, they try to outscore other football teams. A more business-centred example would be:

'Don't tell sales people their bonus is based on meeting some stab-in-the-dark estimate of contracts gained, tell them it is based on how many contract announcements you get to make in comparison to competing companies'.

The main theme was, of course, budget. Bjarte criticised the practise of giving people a one month window to estimate their spending for the entire year. He compared it to doing that with your personal finances. According to the speaker, the benefits of going without departmental budgets are many: money won't be spent just because it is there (people think about things more); damage that is caused by estimation will be reduced; damage that is caused by the foolishness of awarding bonuses to people based on under-spending is eliminated. He neither talked about how long it takes to make an acquisition nor whether removing all budgeting affects the quantity of paperwork, particularly that done by middle-management.

Bas Vodde, A journey through development literature

Staying on the awareness track…

After the relatively heavy-going budgeting talk, this presentation was a nice one to listen to. It was a collection of small quotes from development industry books that highlighted themes that ran between the books, even though none of them had been written about that theme. It was cleverly done. It imparted the speaker's intended messages and highlighted the fact that all the books made statements in accordance to agile principles. At the same time, it added a little conflict between quotes that seemed at first to contradict each other, but then he opened them up with the use of another quote. I admired the style.
A lot of this presentation was about the importance of teams, and the importance of cross-functional teams - something we've just made radical steps towards doing better on in our company. It also highlighted the fact that when cross-functional teams were mentioned in literature, it was not a case of 'you have architects, developers and testers in one team, aren't you doing well!', but rather that cross-functional teams include marketing, documentation, design... you name it.

Business Value Workshop

After lunch I switched to the practitioner track. First up was a workshop on Business Value. Workshops are wonderful, in my book, as there's nothing like getting practical. This was a fun 'game' to play and is open source and available from the host's website.
The game forced the team to juggle customer happiness and the threat of potentially losing contracts or customers against development output. Development was measured in velocity and contained an unpredictable random factor. On top of that, the team had to take into account potential profit, potential savings from process improvements and other important factors.
The exercise highlighted the importance of knowing what is really valued in your business, and what really drives prioritisation issues: Is it the volume of a customer, the money coming in, the long term savings that can be made, how much fun a contract is to do, what brings the sales personnel the biggest bonuses, what is easiest for the developers, or something else?
This is really important for people to know at all levels of an agile organisation. Customers and business stakeholders impose their priorities on the product owner, who communicates them to the development team. When the development team works on a high-level item, it splits the item into tasks and gives them a priority. New methods of prioritisation may get introduced at each level.

The exercise highlighted also another problem: how the important details slip by in time-restricted circumstances, particularly once a team has become accustomed to a way of working and does not spot a change slipping in. In the game, the small print about what customers considered 'good enough' was added without the organisers mentioning it. While our team spotted the small print, we did miss one line and it cost us two customers and two increments of work that we had delivered. We made the mistake during the round where our time to think and act had just been halved by the organisers.
Of course, the random factor of the development velocity was one of the most important things to take into account during planning. Managing the risks (and disappointments) caused teams headaches. A roll of a die determined whether the velocity would increase or decrease in each increment, and there were a lot of jokes about not hiring more developers, or skilled developers, but lucky developers.

Scandinavian Agile Panel

Lastly, I attended a panel where five speakers (whose names I do not have, but one of them was actually Scandinavian*) discussed agile issues and some questions raised by the audience. The most interesting topic was how both local and European laws are limiting the competitiveness of agile companies when competing for contracts. People had problems because some contracts require you to allocate, schedule and price the time of design, development and testing time of a project separately. This conflicts with agile methodology. While I find it interesting, I'm glad once more that it is not relevant to my current work.

Open Space

One thing I haven't mentioned so far is the Open Space track. I went to one of these sessions, at the end of lunch. It was about user interface design in agile. My main reason for wanting to attend the conference was a presentation on this subject, which was pulled last minute from the Practitioner track. Unfortunately, the half-hour chat was not very useful. It confirmed that we are not the only people who are tackling the problem of fitting large-scale design methods and departments of designers in with agile deliverable development work. It didn't give me any insights that I had not managed to glean from reading around. I believe we will have to do as I suspected here and simply experiment by trying to improve the problems that we have, the way that the agile system allows and encourages us to do.

That's enough work-like evening activity for me (eugh). The only reason I am happy to do it is because of the delights of Nordic sauna relaxation, but sadly the experience also encourages headaches and I now need to have a good rest.




*The thing about Scan' Agile is that, well, it's not in Scandinavia. Finland is a Nordic Country, not part of Scandinavia, as such. However, most people's idea of Scandinavian culture does include Finland.