CITCON Australia/New Zealand 2010 - Day 2 (Part 1)

28 Jun 2010 CITCON Australia/New Zealand 2010 – Day 2 (Part 1)

Posted by Cliffano Subagio

Day 2 started at 9am with the early attendees ‘refactoring’ the talks to fit into the schedule, this involved spreading the most voted talks into larger rooms, combining talks around similar topics, and at the same time making sure that no facilitator ended up with multiple sessions running on the same time period. There were about 30 proposed talks with 20 time slots, 4 sessions running in parallel per time period.

Refactoring session.

It was raining all day, a typical Wellington weather I was told.

And here are some short notes from the sessions I attended:

Session 1: ATDD and BDD

A good way to make developers realise the value of BDD is by involving them in a project they’re not familiar with, that already have well defined tests/behaviours. Some open source projects can be a good example.
BDD can be seen as a subset of ATDD, ATDD involves implementing requirements into executables.
FitNesse works really well for some teams, others totally dislike it.
100% control of large test data (e.g. in finance industry) is often not possible, specially when the data can’t be easily copied (e.g. due to legacy system restriction), or when there are multiple teams utilising the same set of data.
Some people strongly believe that web testing should be about testing the presentation layer only and hence can be made minimal, time is better spent on heavily testing the data/model. Others disagree and believe that a complete end to end web testing is always needed, nothing can replace humans.

Session 2: Evolution of Agile and Continuous Integration

Check out Rapid Development by Steve McConnell, published in 1996, you’ll soon realise that there are still many companies which development practices are only 15 years behind.
Pre & post chasm diagram, having started employing CI in 2002/3, did that make me an early adopter?
At the beginning, most people identified agile as XP “Yea, we do XP!” Now, most people are able to differentiate between Scrum and XP.
Use CI Maturity Model to identify where your organisation is at in terms of CI practices.
That maturity model is also an excellent resource to convince others in your organisation that some existing policies need to be updated to allow transition to the next level.
Back then, only developers adopted agile practices. By now, QA is already involved. Next up is operations and infrastructures. My personal take is that it will be 3-5 years from now.
Nowadays agile is _understood_ by development team and QA, the problem is with governance.
Jeff emphasized that the future will be in lean management. The key to lean is to reduce cycle time.
Sometimes a rubber chicken is all that’s needed to do continuous integration.
Would be nice to have a push-button deployment to production.
Someone from operations group must be brought into the team, be involved in the iterations/cycles/sprints, just like QA/testing is now.
Broken builds often get ignored, this is where team must figure out what works for them, whether it be lava lamps, flashing light, IRC notification, or other feedback mechanisms.
The main problem with CI in enterprise is when it gets centralized and development teams suddenly lose visibility. Instead of teams running their own CI tools (e.g. a build server under someone’s desk), it’s now the build engineers who control those tools and often restricting access.
When operations team is against the idea of transitioning CI to the next step, start with empathy and try to look at the situation from their point of view. Try showing them the business value behind the transition, involve someone from higher up in management.
The culture of an organization is often a blocker to further transition in the maturity model.
Know when to stop. When the culture resists further transition and you can’t change the culture, stop, you’re fighting a losing battle.