Just a quick summary of the different sessions so far:
My Half-Day TDDing Javascript Workshop
I had a nice small group of people attend this workshop where I ran through this off-line tutorial available on github. The size meant that we could deviate from some of the material and talk about some topics the participants wanted to go more depth into. The attendants had a mix of skills – some with a java background without knowing javascript so well, and those with a front end background but not having done any testing before.
In the three hours, we managed to get through quite a number of the stories. I few hiccups though due to the terrible nature of missing commas, or semi-colons resulting in very difficult to diagnose code. I received some great feedback, and realised that it’s a very dense tutorial that introduces quite a lot of concepts. At the beginning, I assumed most people had read Crockford’s JavaScript: The Good Parts. I also realised that having an IDE auto-save made a big difference to running the TDD red-green-refactor cycle.
Jutta Eckstein on Agile in Corporations
I decided to go along to Jutta’s talk focusing on agile in big corporations and some of the limits created based on existing organisational behaviours. I liked some of the different things she observed and recommended such as :
- Put customer obligations into contracts – Don’t just specify what they want and how the vendor will work. Also create mechanisms in the contract for the vendor garnering feedback from the customer.
- Remember different stakeholders – Include operations people, founders, etc instead of just the customer. This is more important in large organisations because of the different competing needs in their ecosystem. Just a reflection of reality, not the ideal.
- A smell for a lack of trust is the introduction of formalisation – People introduce formalities and rigid process to compensate where trust does not exist. This creates a certain amount of overhead but creates a certain amount of safety for both parties by making interactions more explicit. Be careful of this and an increasing amount of this!
- Transparency relies on trust – Avoid certain of transparencies too early as the organisation may not be ready for it.
- Agile development is a trouble detector – Like the lowering of a waterline. It exposes existing problems in the system, generally does not create it.
- A reminder of the Hawthorne effect – Another introduction to the hawthorne effect where the fact that something is being studied actually alters the behaviour of the subjects under study.
Diana Larsen on People Are Funny
Had a fun, interactive series talking about Human System Dynamics Institute, and the ideas of Containers, Differences and Exchanges.
Emily Bache on Geek Feminism
Emily talked a lot about the idea of geek feminism and some helpful tips including treating minorities as the same as everyone else (and try not to go out of your way to highlight their differences, even if in a good way!). She had some great research, and references and hoping she puts her slides up somewhere.
Panel on Successful Automated Testing in Agile Environments
I spoke on this panel, turned fishbowl discussion where we talked about our experiences with teams who we think succeeded with automated testing, some the common problems when teams take on automated testing, patterns and tips on how to achieve it and then some interesting topics brought up by the audience including how to “convince” people to do TDD (The answer: Do not) as well as specific things like measuring success (e.g. don’t do it by measuring coverage).
