We were there to present our experience report, to attend some of the most interesting tutorial/workshops and to meet and discuss with people. The experience report title is "The creation of a distributed agile team" and talks about the story of building the Web21C SDK team from its inception to the current days.
The paper book is available to buy from the Springer website. Articles are downloadable as PDFs.
Overall an interesting book - also because our report is in there ;) - if you want theoretical studies behind agile and specifically XP methodologies.
Don't expect to find lots of insights or techniques other than those already best known.
We set up a poster in the hotel hall. We had few people talking to us to find out how about our experience and mostly they were interested on how hard it was to manage the team distributed all over the world and how hard it was to apply agile (XP) practices like stand ups, pair programming and so on.
A group was coming from the University of Cagliari (Sardinia).
They were some PhD students interested on real experience of big teams adopting agile for some of their research studies.
I think most of the interest on our experience was caused by my interventions to the first workshop, where I was part of the panel several times during the goldfish bowl.
After two days of standing by the poster, the hipe was gone but discussion continued at the agile cafes and at the bar during the coffee breaks.
This was a brilliant idea. The hotel did not provide to us an open space where people could meet and talk. So someone thought to use the hotel patio and the round tables in there to sit and discuss of whatever topic anyone had in mind. with coffee or beer; anyone could join a table and dive into whatever the discussion was at that point.
This was a very good way to share experiences, pain and know each other.
It is surprising how people is separate parts of the globe, in projects of different nature, may share the same issues and problems.
Popular topics included: how to write user stories, how to manage a distributed agile team, is a small team more efficient than a big team no matter what the size of the project is, story of the waterfall methodology.
Most of the value i got out of the conference was by having met people of various type and experience.
Most notably I had the chance to talk and have dinner with Kent and Cinthia Beck and JB Reinsberger. Other than that i met people working for Philips, Ferrari, Exoftware, BT (!).
It was a good way of exchanging experiences on shared problems or get to know issues in different domains (for example test driving embedded code).
Needless to say that Como and its Lake are beautiful. Probably you'll get the most of it for a long city break weekend (3/4 days). Food is faboulous - both fish and meat - and almost anywhere cheap.
I was not impressed by my Hotel, very expensive, not so good food and service not at the level of a four star rank.
Can agile practices deliver high-quality large scale offshored projects?
This was the workshop i found most interesting, also because was in theme with our poster. It as arranged as a gold fish bowl and was set as an open discussion driven by the speakers (a couple of consultants from Sweden). There were five chairs in front of the audience and only four were supposed to be occupied. The four people in the panel had to discuss the topic in the agenda. If someone wanted to dibate or discuss an issue, s/he had to go on the last available chair and one of the panel had to leave.
We initiated the discussion with the following starting points:
- process and tools to enable team members comms effectively;
- impact of different time zones in productivity
- what is the minimum amount of human comms
- team to team comms
- does the team know what the project goal is?
- what are the additional tasks necessary in a big team?
- how to avoid PM blind spots?
- how to test control scope and cost?
- are agile practices trustworthy?
One thing i realised, though, we don't do at the moment is maintaining a continuous integration box where all the capabilities are deployed and the sdk tests run automatically.
Agile process anti-patterns
Interesting workshop too... it seems that the set of antipatterns for agile methodologies are not yet well defined. the author - Wayne Allen - is writing a book discussing the list of antipatterns that he's come across in his work as a consultant in the last five years. We were asked to remember the antipatterns we thought we came across in our project, then the audience was diveded in to two parts and each part had to pick an antipattern, discuss and elaborate it. The format for the description of the antipattern is the usual: name, poor solution, consequences, forces, better solution, exceptions.
My team picked the Scrummerfall antipattern, where by teams think to implement an agile project just because they do iterations but they end up with doing a waterfall approach in the sense that iterations dont produce valuable and testable stories, there's no goal defined for the release and so on.
This was the tutorial from Kent Beck. It was about mind mappings applied to XP practices. The underlying idea was to use mind mappings to elaborate XP stories.
I had heard of mind maps but i never managed to use one. It seems quite a powerful concept expecially because it allows you to use more than one part of your brain (that for example associated with colors and maps). probably more effective than simple bullet point lists to elaborate on concepts and ideas.
So i did find it intellectually interesting but not very applicable to my day to day job - at least for the moment.
On the merit of XP much was stressed on Appreciative Inquiry: concentrate more on what went well rather than feeling depressed looking only to what went wrong
- identify when things went well
- what were the circumstances, who was involved what support was available and how did you feel?
- how can you reuse the past positive experience in any new scenario?
Thinking refining and communicating business perspective with executable documents
Another interesting workshop forcussed on executable documentation. The idea is to have documents written by customers to work as acceptance tests. This should lead to ATD development (acceptance tests driven).
Fitnesse is an implementation of a mechanism to write executable documentation. Although it was general consensus that Fitnesse is not very good for customers as it forces a strict syntax - based on tables - and it requires mapping between wiki and code.
The workshop ended with a brief discussion on fitnesse and then the audience split one part carrying on a q&a discussion of executable documentation, the other on advanced fitnesse topics. I picked the former and managed to have an in depth discussion on this matter with the speaker.
One thing i think is worth mentioning is that on ADT you focus more on the testability of the story and on explicitly understanding the value that a customer gets from having that story implemented.
JB Reisnberger's was an iteresting tutorial even if i - sort of - knew already how to proficiently use jUnit... He stresses the use of mock objects (jMock) all over the place and I tend to disagree with him... See his book jUnit recipes for more details.
Agile open source academy
Rather boring workshop on open source (and free) tools to use to implement agile projects. Most importantly i noticied that we're using most of the tools that are used by everyone else (in our domain).
This was more of an experience report from the IT managers of the Ferrari racing teams. Most notably they have very short iterations - one day tipically and very short releases - usually in conjuntion with the GP from march to november... that means every one or two weeks.
It was interesting to hear how they solved the problems of isolating the team from the rest of the world to minimise overhead and disturbance. They rotate a "driver" once a week which is the front door to the team. He responds to the emails, fixes immediate bugs/issues, does 1st/2nd/3rd line of support. They say it's a good way to introduce new members to the complexity of the projects (120ca) they have.
Keynote 2: Ease at work
This is the end key note from Kent Beck. It had the un-dubious ability to let people talk.
It was all about balancing the life at work with yourself by finding your path to feeling at ease during work time. Ease in the sense of feeling good with yourself and within your environment.
Ways suggested to feel at ease were doing a good job (eg being good at what you do), being honest with yourself and your team members, being accountable of what you do, being passionate on what you do.
I found his suggestions and his approach a bit out of context... not everybody can afford or has the courage (for personal or contingent reasons) to be honest, accountable or passionate. But I can see that Mr Beck is trying to bring XP (and himself) to the next level.
I am quete happy to have attended XP2007. It's not the best conference i have been to but i found answers to most of my questions.
The overall message i got from talking to people and attending to the tutorials is that it's not enough to apply the agile tecniques to be succesfull... it's up to us, the people working on a project, to buy in to the values of agility, expecially accountability, honesty and discipline.Then the tecnique once mastered can be effective. Otherwise it's again process over people... I asked around how does the percentage of failed projects adopting agile compares with the percentage of failed projects adopting waterfall (or in general non agile)...
Well you'll be surprised to know that they are pretty much the same. So it's not agile per se but its the values that it promotes when people really is engaged to make them work.