On Tuesday, I went to YALSCCRTE (yet another London Software Craftsmanship Community round table evening). I described the format in an earlier post so without further ado, the below are some notes on the evening.
This was a talk (slides here) introducing us to some of the concepts behind a book (“Tribal Leadership”) which analyses group dynamics and relationships in teams and organisations. Based on the analysis, they seem to have arrived at CMMI-like (i.e. “it’s got stages”) framework for categorising team behaviour. Quite an interesting talk. This definitely fairly relevant to Agile software development and the principles they have about distributed responsibility. The book definitely made it on to my reading list – so I’ll give it a full review when I get round to reading it.
Three types of leadership
Seems like it was an evening to talk about leadership stuff. This talk was more about the types of leadership necessary in a software project. It postulated that there were three different kinds of leadership: technical architecture, project management and team leadership. The talk also went a little bit into different ways of organising this (individual vs distributed responsibility). This very much tied in with the talk about tribal leadership. (Maybe distributed responsibility leads to a greater sense of team engagement and collaboration?!)
A Benefit, Complexity and Danger approach to estimation
This talk was about enriching traditional estimation methods with measures of benefits, complexity and danger. It is described in a fair amount of detail here. This sounds like quite an interesting approach – especially to facilitate communication between product owners and developers. Ultimately, I think you would also still need to converge on an effort score because that is what the product owner ultimately cares about.
Advanced Infrastructure for Continuous Delivery
This was a talk about the importance of establishing feedback loops in your development effort and how important a continuous delivery system (builds, tests, deployments) is to such a feedback loop. It posed the question of why a remote team called “IT” might be in charge of that infrastructure and suggested that one might be able to use development methodology for dev teams to administer infrastructure themselves.
How do you deal with a horrendous codebase & resistance to change?
This talk posed the above question to the group and facilitated a little bit of a discussion on the topic. For me, personally, the single most helpful comment was “always leave the codebase a little bit cleaner than before you touched it”. This is such a true statement and should be our guiding principle in practice – no matter the current level of understanding or ability!
After these lightning talks, there were then two longer discussions:
- Domain Driven Design – how to achieve it
- Greenfield project – how to do it properly
I took part in the latter one. A large part of the discussion here was heavily influenced by the “Growing object oriented software, guided by tests” book I am currently reading. It’s all about BDD, walking skeletons and such things. I’ll dive a little bit deeper into this subject matter, when it comes to reviewing the book. One of the most helpful ideas during the discussion (which is not in the book) was the idea to write a “shitty prototype” to get familiar with the subject matter and entities and to then THROW THE PROTOTYPE AWAY and do it properly (as they said in the discussion, the important thing is the throwing away here…)
Altogether this evening felt a little bit less “shiny and new” than the last (first) one that I went to. Of course that is to be expected. I guess you just know the format, have met the people before etc.
Having said that, the discussions were still very interesting and very much worthwhile. It’s great to spend an evening sharing ideas in a fairly free-format way with lots of passionate devs.