There were three tracks, a retreat and a workshop. Plenty of content for everyone. Two tracks were recorded on video and will be available at a later time. Just to give you some idea of the actual content, let me go through some of my notes.
Laurent Bossavit - The Art of Being Wrong
In the first exercise he asked us to fill in a simple query of ten questions. The idea was to give a range for each possibility (ie. "How tall is Empire State building?") so that you would end up with a result in which nine out of ten would have a correct range.
The exercise demonstrated very effectively how biased we are by default. Nobody succeeded in estimating. I scored five out of ten (remember, nine was the goal). Not very good but above the average which seems to be around 3.5. This just demonstrates how biased we are by default.
Laurent stated that this is a matter of calibration. It is possible for us to become better at this sort of estimates with a bit of training. Even small improvements make a huge difference when compared to general population.
In his other exercise he asked us to provide certainty for each statement. Ie. if you were absolutely sure, you would give 100%. If you were certain the opposite was true, 0% would have sufficed. Of course in practice you would have likely used something in between depending on your confidence.
In this case the questions were in technical domain. I scored much better in this case. In this scoring scheme I got 44. Apparently average is around 250. It is easy to end up with a higher score if you are actually wrong about some statement. I guess I got a bit lucky and managed to estimate each correctly.
Compared to the first one this was definitely easier. I think the takeaway is that it is easier to estimate possibilities than ranges of possibilities. 90% range is actually very large when you think about it. It is so very easy to forget that.
All of this ties in with software development somewhat. It is too easy to give a lower bound or point estimate without thinking about it. If you have to do estimates, consider giving ranges with certainties instead. As shown by Laurent, you can still get it quite wrong by factor of three or so. But this depends on your estimation skills and biases. Generally it is much easier to estimate something you already know well. When unknown quantities come into play it gets a lot harder.
Laurent has written a book, The Leprechauns of Software Engineering. In it he delves into the topic further and shows how shaky foundation our software engineering culture actually is built upon. I think that one goes to my reading list.
In addition he mentioned the following resources which you might find handy starting points: Prediction Book, The Good Judgment Project, SciCast.
Markus Hjort - Scaling from a Programmer to a Team of Developers. Building Software that Matters
In the second session I participated in Markus Hjort of Reaktor spoke about scaling from a programmer to a team of developers. It wasn't quite what I expected. I guess I should have read the presentation description better. For me the actual value of the presentation was in the end and I would have loved to hear more about case Silja-Tallink. The first half of the presentation was more or less trivial at least from my perspective. I have listed Markus' lessons below:- I love to build software
- Cowboying allows you to build only small programs
- Team work is fun
- You have to test software
- Heavy processes and tools are not the solution
- Agile team is the silver bullet
- Teaching about the silver
- Distributed team can succeed
- Continuous delivery
I don't quite agree with all the points he made. For instance even if you have a nice, agile team that works effectively, you can still go very wrong. I don't see it as the silver bullet he made it to be. There are more fundamental things in business that have to be in balance before you can even think about optimizing the performance of teams.
Some of the points, such as you have to test software, are kind of obvious. Testing definitely helps to keep quality high. But as with everything, there's a time and place for it. In my view it's ok to write rubbish for a while when you are still trying to understand the problem. Once you understand the problem and surrounding constraints it becomes easier to solve and tests will be easier to write. I wouldn't bother writing tests for throwaway scripts myself.
Maybe the talk worked better for others. As is it feels like more could have been gotten out of the material. I would have cut down the trivial stuff and spent more time on something else. But that's the thing with these things, there is no way to please everybody.
Janne Rönkkö - Maintaining a Clean Codebase
Janne Rönkkö of Vincit talked about how to maintain a clean codebase. He split the presentation in three parts - tools, how they do it and experiences. Of course he mentioned some obvious things like "use version control", the importance of code reviews, continuous integration and testing. The talk revolved mostly around the concept of code reviews.
The greatest value of code reviews lies in the fact that they are a preventative measure. You will catch possible issues before they have a chance to make some real damage. It is cheaper to prevent problems than to keep on fixing issues caused by them.
Interestingly they appear to review all commits at Vincit. It has become a part of their standard development process. Unlike you might think it actually doesn't take that much time. Rather than having separate code review sessions this is something they deal with tooling. In their case they have settled using git, gerrit and buildbot in combination with Jenkins.
Adopting the process has enabled them to become more disciplined and as a result their code has better quality than before. It has also changed their development culture. Developers thrive to produce quality code and actually encourage others to find issues in it. This in turn helps them to become better developers.
Antti Kirjavainen - A Minute of Our Time or What We Need to Unlearn About Software Development
As Antti did the right thing and put the slides on Slideshare, I have embedded them below. Regardless I will go through some core points.
His core premise was that we are currently very bad at producing happiness when it comes to software contracting. The primary reason is that the relationship between the customer and the vendor is adversarial. From vendor point of view you are trying to get most billable hours done with the least possible effort where as the customer is trying to get the most features done with the least cost. This in turn causes all sorts of nasty issues. In short the interests aren't aligned.
Fortunately it looks like it is possible to get around this conflict of interest. Antti listed some options:
- #NoContracting
- Build trust first
- Figure out the smallest potentially valuable unit of work
- Figure out what to actually offer to the customer
This is a marketing approach really but it seems to work quite well. If you can provide value for your customer even before getting involved, you have already gained that little bit of trust needed for things to get started. Of course this sort of thing takes effort but hey what doesn't?
I think Antti is very right in stating that it's all about value, not features. If you can figure out what actually provides value to the client and chunk that up, you can begin to fill the need bit by bit. Antti actually proposed making contracts with a clear exit clause. If the client is not happy, allow the contract to be terminated after an iteration (can be 1-2 weeks). This will also keep you highly motivated as you have to earn the trust time by time. From client point of view it's a good deal because it gives them some flexibility. If you are interested in this sort of thing, check out Tom Gilb's paper "No Cure No Pay" (pdf).
To get back to Antti's last point it can be valuable to understand what you are actually offering to the customer. This in turn comes back to business design. Is there something unique you can provide that competing vendors cannot? What is it that actually makes you valuable to your client?
Antti also discussed possible collaboration schemes such as profit share. If you are in the same boat, both parties have interest in making it to go to the same direction. Personally I would be very careful about IP rights, exit clauses and so on in this sort of case. I can see this working very well given the fundamentals are in place correctly.
Overall this talk was one of the highlights of the conference for me. There was definitely to ponder upon. I already had some similar ideas and the talk helped me to confirm some of those. Generally try to aim toward small projects with continuity rather than big ones as those come with a lot of inherent risks and don't allow flexibility for either party. If you can avoid conflict of interest between the goals of the parties, even better.
Henri Karhatsu - From #estwaste to #NoEstimates - True Story
Henri started to transform the practices of the team step by step. They started by introducing retrospectives and changed the way they did sprint planning (it was a SCRUM environment). They wrote the tasks to paper and then assigned points to them based on their relative size. Big tasks were split into smaller ones. This enabled them to cycle faster, test and finish earlier in a more predictable manner.
Despite this improvement there still was waste in the estimation process. Even though they had a better idea of the project velocity, it tells you something only when things are going wrong.
Next they dropped point estimates and instead used a rougher categorization with Small, Medium and Large sizes. Again, large tasks were split to smaller ones. The estimation process took less time than earlier.
Finally they had problems prioritizing tasks. They had a classic "two businesses, one team" type of problem in their hands. Both parties had a different idea of priorities. They split up the team in two and formed separate backlogs for each. This made it possible for each party to prioritize tasks based on their need.
As they moved to this model they dropped sprints and estimation altogether and just focused on performing the tasks deemed most important. They still had weekly meetings with various stakeholders to keep things in sync. But compared to earlier the process was somewhat lighter.
This case showed well how a badly performing team can transform into something more effective. Estimates can become irrelevant once task size is kept small enough and you are providing continuous value. Focus on business goals seems essential. If you understand what the client is trying to achieve and the teams are given the power, it becomes possible for them to self-organize to achieve those goals in an effective manner.
To quote Henri it is more effective to focus on return over investment when it comes to classic ROI models. Too often people spend a lot of time worrying over costs when they should be worrying about what they get out of it. He also highlighted the importance of keeping possible features as small and testable as possible. The faster you can deliver, the faster you can iterate towards the right direction. This in turn helps you to avoid waste and provide more value for your client.
In the end Henri's team achieved a situation where they didn't spend any time estimating and focused on delivery of these small, aptly sized chunks. This is in the core of agile thinking after all.
Henri's case shows well how to change the behavior of a team gradually towards something more effective. Of course these things are situational. Some of the basic ideas like small chunk size and continuous improvement just make a lot of sense in the dynamic world we are living in.
The slides of Henri's talk have been made available so have a look at those for some extra details.
Conclusion
Around 60 out of 235 or so registered people failed to show up.
EDIT: Apparently the people on the wait list actually got informed about the situation. There will still some timing issues (information too late etc.). Anyway, great to hear things worked out. :)
I would also consider changing the conference format at least a little bit. There was a lot of content now and some was actually wasted. I would have loved to participate in the code retreat or a workshop even but I felt too compelled by the talks. Had they been arranged on another day I would have definitely taken part.
It could be interesting to have more open-ended content available. That would make it possible to get more out of guest speakers if they are up to it. For instance Laurent Bossavit's session felt way too short even though it was a full hour. Of course this sort of thinking would very quickly lead to something like an unconference. That may not be a bad thing. It would make these sort of events more agile by definition.
Overall it was very happy with the event and hopefully I managed to learn a thing or two. It is just amazing people keep arranging these sort of events here middle of nowhere. Props to the organizers, speakers and participants! You make these things happen.