I am involved in agile developed projects at my job. Only very indirectly though: I manage a team working on several projects and two of them use Scrum. And it is a rather new thing around so there was something to learn in the past few months for me. I must say that the Scrum---or perhaps the way I saw it implemented---quite captured me. That much that I'm actually trying it out with the project I'm directly involved in... So, I decided to visit the Agilia conference.
I was hoping to learn about various implementation details of agile methods for different types of projects and teams. And Agilia did not disappoint me in this regard. However I had not realized how much could be transfered from the work organization to the company orgainzation. I have seen some of this in, e.g. Steve Denning's Forbes column and even though his observations fit quite well what I see around myself, I was rather sceptical about the solutions Mr. Denning presented: and quite often it was some form of agile organizations. At Agilia I had a chance to meet people who already implemented some of the ideas and who were able to describe the change they brought and obstacles along the way. This was the biggest (pleasant) surprise: I learned not only how do the modern companies approach the product development but more imporantly what actually makes them "modern".
The conference was opened by a keynote by Mario Almondo, the COO of Scuderia Ferrari (the F1 racing team). Mr. Almondo spoke about culture and its necessity for a success. The talk was of course attractive largely by the fact the speaker was part of a true legend: only few people can refer to Jackie Icks or Michael Schumacher as colleagues. And yet another difference: How many sport or automobile analogies have you heard in software development? Now, this speaker was really talking about cars and races. And software and IT companies popped up as the "other part" of the analogy:
- Winning a race is not enough to win the championship: one time success doesn't matter that much as the ability to repeat it.
- Doing things right must be a habit, a routine. Realizing what things should be like is not enough. Doing them right once is useless.
- To build a team one must know the people: their past, their ambitions, their goals.
- We don't want just to win over the competition. We want to innovate for the customer.
- If the top management does not care, the team cannot win.
I realize how these may sound as clichés but really it was the speaker's personality and the different context that augmented their actual importance. And clichés become clichés quite often for a good reason...
The other talk I have attender the first day was presented by Anna Danes Boix who was working for a completely distributed web development company and spoke about the challenges it brought and ways to overcome them. Distributed in this case means 228 people living in 25 countries, who never meet in person: the company effectively has no travel budget (some 400 Euros spent on travelling in the past 6 years) and still the company is profitable and maintains really low turnover rate. Anna spoke about the necessity to focus on the people: First the clients, second the employees. And of course not everybody is capable of working in such a team: the technical skills are necessary but not enough, it really needs people who are able to communicate, appreciate quality and strive for it. And of course the company needs to treat the people so they feel important and engaged: the company exists not only to make the clients to reach their goals but also for the employees to reach theirs. It is necessary for everybody to understand their role, people communicate frequently and openly, status reports need to receive feedback and another interesting thing: leaders are never hired from outside. And again: doing things right must become a habit and habits are developed by repetition.
Bjarte Bogsnes' Beyond Budgeting was perhaps the "highest-level" talk. There is quite a lot of theory behind how to allocate company budgets and how not to do that. The traditional way is to sit down once per year and put some money in this bucket, some money in that bucket... The speaker works for Statoil: one of the biggest oil mining companies in the world. (And he works there since 1983.) Still he is driving changes in the company: like budgeting. Statoil approaches the problem in an unusal way (for a corporation): dynamically as the requirement from the projects come and change. Yes, "predictability" is apparently not a priority for the company. However creating environment that allow the employees to succeed is: so they are given right to decide what to spend the company money on... For example the travel budget is totally open---anyone can take as much they want from it---but also totally transparent: everybody sees the others' spending. No, the employees didn't ruin the company, the overall travel spendings went actually down...
The next one was Philip Eisbacher's talk of how to use agile technique to develop the company itself and how to actually organize the teams to be able to do so. The core of the idea was to allocate some sprints just for the company's needs: improving processes, tooling, implement new ideas..., and be actually transparent about it to the customers.
And maybe I'm overly sensitive to this but it was not the first time I witnessed people saying something like: "It was open source so it was not that good...". It feels odd especially when the other tools the same person refers to (inherently as "good") are open source too; in those cases the openess apparently doesn't matter.
Jaroslav Prochazka then talked about the transformation of the industry, about the shift from creating products to providing services. As all the other talks this one emphasised the necessity of delighting the customer and building long-term relationships. This requires all the developers and all the team members to be aware of the overall product and how does their contribution fit into the final outcome and why it's necessary. Jaroslav suggested a way to organize the teams more efficiently and what roles were necessary for this success. I have to admit that much of the talk I felt like there was too much fill-in and the core idea itself didn't seem that novel to me.
And the day was closed again by the stories from Ferrari F1 team: their former product manager, Enrico Lombardo, talked about breaking the resistance when introducing new ideas to the actually quite conservative team. It is not possible to actually capture the atmosphere of the talk. Mr. Lombardo is really great story teller and I really think inviting the Scuderia Ferrari people to talk to the mostly IT guys was a great move from the Agilia organisers.
Overall my impression of the conference was very positive. Given I came there with a lot of scepticism and the conference was actually almost non-technical, I was after all quite impressed. And there were several perpetuating themes in most of the talks. I'll get to them next time.