Agile borrowed from the JIT manufacturing processes originally at Toyota. The Agile Manifesto itself summarized the key aspects brought into programming from JIT.

Original Agile processes like eXtreme Programming (XP) brought breathtaking speed of delivery to a waterfall world. But Agile has not stood still. From XP’s original (and aggressive) 2­3 week iterations, we now see individual programmers pushing new functionality to live systems several times a day!

Acceleration drives changes to an organization’s processes and skills, just as the original shift to Agile from waterfall. Organizations reluctant to address such changes, however, inhibit the acceleration. Indeed, their attempts to accelerate often result in lower morale and flawed delivery; these failures drive conservative (and destructive) attitudes against change.

In this talk, we will address a myriad of drivers for faster delivery:

• Available technologies, including Cloud, languages, and new frameworks
• Shift toward active monitoring rather than one­time acceptance testing
• Refined, lighter processes consistent with shorter cycles
• Architecture that is fault­-tolerant rather than provably perfect
• Shift toward trying ideas rather than firm requirements
• Reduction in role specialists
• Reduction in delivery team size

For each of these drivers, we will describe teams that have taken these steps and the corresponding accelerated delivery.

In November 1924, in Cicero, Illinois, at the behest of Thomas Edison, the Western Electric company kicked off a set of workplace studies that would become a foundation for modern management thinking. A group of people that included a young William Edwards Deming, Joseph Juran, Walter Shewhart and our very own academic from Adelaide, Elton Mayo, took a foundation in engineering practices, combined them with a curiosity about social sciences, and started a revolution in thinking that impacts almost every workplace today.

Almost exactly 90 years later, another graduate of Elton Mayo’s Wharton School, Paul Tozour, published the results of a 21st century equivalent of the Hawthorne studies – The Games Outcome Project. Real empirical data on what makes software teams perform – and it has little to do with how agile you are.

These two studies, and the 90 years of theorising and research that lie between them, impact software engineers more than they might care to acknowledge. Productivity and the health of workplaces have become hot issues as Facebook moves into its 10 acre open plan office, Joel Spolsky (still) swears by an office for every engineer, and Basecamp work religiously on a remote basis. The aim of this talk is to join some dots and identify what from all this research has stood the test of time as better ways to work, with particular reflections on life at real-estate.com.au where the author works in IT.

Spreadsheets are the bane of people’s lives in many organisations and – for better or for worse – businesses continue to rely on them very heavily, even for critical parts of their day to day operations. In my presentation I will discuss how the following technologies can be utilised to build neat solutions to help automate these workflows.

• Scala’s Streams and Case classes
• ScalaTest’s FlatSpec
• The Apache POI project

It will begin by talking about how we’ve ended up here in the first place – a case in point is within large financial organisations which have critical risk models (accounting for billions of dollars on their balance sheets) that still reside within huge and highly complex spreadsheets!

Following a brief overview of a typical spreadsheet model, I will demonstrate how one can interact with them programmatically with the excellent Apache POI library. I then go on to breakdown how by utilising stream processing and case classes in Scala one can provide really neat solutions to replace these manually managed spreadsheets with fully automated and concise, functional solutions.

Finally, I will illuminate how one can assist with the end to end validation process, via the magic of BDD – which can help articulate all is behaving as expected.

At Atlassian, we’ve been migrating applications in our Cloud platform to a microservice-based architecture to support the scale and agility we need to grow long into the future. While developing small microservices with the latest tech stacks is relatively quick and fun, rolling out such radical architectural changes to 60,000+ existing instances of systems used continuously by our customers with minimal downtime and no loss of data is extremely challenging. In this talk, we’ll describe our safety-first approach for achieving this, using our recent work rolling out a microservice binary data storage and migrating many terabytes of attachment data from JIRA into AWS as our main case study. We will discuss our success stories and learnings for rapidly developing new microservices with pure functional architecture, planning and executing safe rollout, and engaging the rest of the organisation to achieve immediate and future business benefits.

After spending a year working on a project and delivering all the ‘must’ and ‘could’ have features. You hear through the grapevine that customers found the solution clunky and the uptake hasn’t been great. What’s more, your part of a success ‘agile’ team adopting XP practices and continuous deployment. What’s going wrong?

Successful product development is a team effort and can’t simply be left to the business to decide what’s right. There is a new approach called Lean UX which derives from the UX world, rooted firmly in design thinking, agile and lean startup.

In this talk, I will introduce Lean UX and take you through the guiding principles of the learning loop. Through the talk I will use Bankwest as a case study of how we experimented with Lean UX from projects to strategy.

Impact mapping is a powerful visual technique to make sure that you are building the right thing; making a big impact with our efforts. I’ve found it very enlightening and powerful.

In this session I wanted to try to turn the normal flow on it’s head; by first doing an impact map together and then talk about what this means and how to use it.

In my consultancy, I’ve come to realize that most clients/teams I’ve coach don’t care too much about the theory.This presentation, therefore, takes a standpoint in the practical parts.I will also mimic my experience with most teams I’ve introduced kanban too, and do the introduction in small iterations.This means that the presentation also is a template for anyone that will need to introduce kanban to others.

After spending a year working on a project and delivering all the ‘must’ and ‘could’ have features. You hear through the grapevine that customers found the solution clunky and the uptake hasn’t been great. What’s more, your part of a success ‘agile’ team adopting XP practices and continuous deployment. What’s going wrong?

Successful product development is a team effort and can’t simply be left to the business to decide what’s right. There is a new approach called Lean UX which derives from the UX world, rooted firmly in design thinking, agile and lean startup.

In this talk, I will introduce Lean UX and take you through the guiding principles of the learning loop. Through the talk I will use Bankwest as a case study of how we experimented with Lean UX from projects to strategy.

In this session Jorge explains five remarkable areas in which the F# language provides a significant advantage when comparing it with C#. He shows examples covering from basic to more advanced features, like type providers and computation expressions. This session provides a glimpse of what is possible with F#, its main advantages and a basic understanding of how powerful this great language is.

Behaviour Driven Development is a powerful collaboration technique that can empower teams to deliver higher value features to the business faster and more effectively. But although Behaviour Driven Development is based on a number of simple principles, it can go dramatically wrong in a myriad of different ways.

In this talk we discuss twelve BDD anti-patterns we frequently encounter in real-world BDD projects, anti-patterns that can dramatically reduce the effectiveness of BDD as a practice, and that can even cause BDD adoption to fail entirely. Looking at everything from insufficient collaboration practices to poor use of test automation tooling, from teams that test too much to teams that forget the most important scenarios, we will look at the many different ways that BDD can go wrong, and how it should be done.

We will use real-world examples to illustrate each of these anti-patterns. You will learn how to spot these issues in your own projects, and more importantly how to avoid them in the first place.

Have you designed / developed a system using the “best practices” of the last few years? Are these acronyms familiar – ORM, SOA and DDD? If so there’s every chance that when your system makes it to production, it’s going to suffer.

In this session, I will investigate this often forgotten life of a system – when it’s deployed into the real world and the original developers move on to pastures new. It’s a collection of my experiences from the last 9 months working very close to a live system which I designed a few years ago using the then, best practices.

We will consider issues which are often overlooked or not thought about in too much detail at the development phase like performance, concurrency, scalability and deployment. We’ll see ways we can track problems down, sometimes before the end users even see them. We will think about how to deal with them or even side-step them. And we will consider how we may have avoided them by taking different architectural paths early on.

By the end of the talk I’m hoping you’ll see that delivering a system to production is just the beginning of it’s life, and have some ideas on how to keep it happy and healthy whilst it grows!

HBF has a vision to create a unique community where Members are renowned for being healthier, happier people. HBF delivers this in part, through a range of web based and mobile health tools to allow members to track and monitor their wellness, and by capturing insights from these services alongside broader member data. This case study will present how three solutions originating through experimental innovation days within the HBF IT developer community, applied new technology to local opportunities, to create true member value and a shift in thinking and capability. Examples include the development of a pilot application using Google Glass for HBF Fitness; an application for members to upload their wearables data into an integrated service to record and compare data and receive rewards and incentives; and the use of rapid data discovery and interactive visualisation tools to bring HBF’s data to life.

The maker culture, it’s a place where minimum viable product simply isn’t cool enough, where manufacturer security holes are useful and where your skills as a developer are a membership card.

Learn how to get started coding against the devices in your home and see how your existing developer skills and tools can be used to improve the way you interact with the physical world. We’ll dive into real world examples of bringing a residential A/C and a typical domestic wireless doorbell into the Internet of Things using a netduino and the .net microframework. Along the way we’ll discover some pitfalls for experienced developers and a heads up for dealing with the iGeneration prankster.

For most programmers, regular expressions are a riddle wrapped in a mystery inside an enigma shrouded in line-noise. So most sensible programmers either don’t use them at all (and are thereby forced to reinvent worse wheels…badly), or else they fall back on an “evolutionary programming” approach: find an existing regex that looks like it might do, then randomly permute its “genome” over and over again until it appears to work.

In this talk, we’ll go back to basics and discover that regexes mostly aren’t what you think they are, mostly don’t work the way you were taught they did, and mostly shouldn’t be created the way everyone tells you to.

More usefully, we’ll also talk about what regexes really are, how they actually work, and see how normal programmers can make use of their existing software development skills to construct correct and efficient regexes…without selling their souls or losing their minds.

Remote working in our industry is becoming more prevalent everyday. Geography is no longer a constraint in setting up a work function in an organisation.In 2010 REA Group, together with ThoughtWorks China, set up an offshore delivery centre.This centre works extremely effectively using REA Agile processes.

I have been building remote teams in Xi’an for the past 2 1/2 years. As a Technical Lead,I have detailed hands on experience and specifics that I will share with the audience on what has worked well for us as well as what hasn’t worked so well. This case study will provide a recipe for working with remote agile teams effectively. In particular I will cover:

• Remote team composition
• Essential technology
• Core practices
• Asynchronous versus Synchronous communication
• Common Challenges
• Building a successful culture
• Tips and tricks for remote working

Tiny little apps on your wrist! WatchKit is the SDK for developing apps for the new Apple Watch. This presentation will cover a variety of information to help you create great WatchKit apps, including:

• The architecture of WatchKit apps
• What functionality is and isn’t possible using WatchKit
• Communication and data sharing between Apple Watch and the iPhone
• Tips and tricks for great WatchKit app performance

The presentation will be useful both for newcomers who are looking for a head start in developing WatchKit apps, as well as developers with some WatchKit experience who are interested in sharpening their skills.

Setting up a shared infrastructure environment is a challenging task, changing an existing one without breaking anything even more and one that traditional testing methods often have trouble supporting.

Behaviour Driven Infrastructure (BDI) is one of many tools that can help us change the way we approach testing of infrastructure changes. Supported by a real-life case study I will shed some light on what the future might hold in this area and expose some ways in which BDI might help fill the gaps.

At Atlassian, we’ve been migrating applications in our Cloud platform to a microservice-based architecture to support the scale and agility we need to grow long into the future. While developing small microservices with the latest tech stacks is relatively quick and fun, rolling out such radical architectural changes to 60,000+ existing instances of systems used continuously by our customers with minimal downtime and no loss of data is extremely challenging. In this talk, we’ll describe our safety-first approach for achieving this, using our recent work rolling out a microservice binary data storage and migrating many terabytes of attachment data from JIRA into AWS as our main case study. We will discuss our success stories and learnings for rapidly developing new microservices with pure functional architecture, planning and executing safe rollout, and engaging the rest of the organisation to achieve immediate and future business benefits.

Last year Apple announced a brand new programming language as a modern replacement for the venerable Objective-C. Swift makes a very interesting study in language design – influenced by modern statically-typed languages with an emphasis on safety and speed, but (almost) seamlessly compatible with the unsafe, dynamic, weakly-typed OO language it needs to co-exist with.

Sam will run through a brief introduction to the language, highlighting some of the design choices and tradeoffs made, and show how to use the language features to write better code.

Do you want to write less tests for the same amount of confidence?

Do you want to print out the testing pyramid on a dot matrix printer, take it outside and set fire to it?

How confident are you that you can survive the refactoring apocalypse without breaking your tests?

As consultants, we get to see how testing is performed across many different organisations and we have a chance to experiment with different testing strategies across multiple projects. Through this experience, we have developed a pragmatic process for setting an initial testing strategy that is as simple as possible and iterating on that strategy over time to evolve it based on how it performs. We have also settled on a style of testing that has proved to be very effective at reducing testing effort while maintaining (or even improving) confidence from our tests.

This talk will focus on some of our learnings and we will cover the different types of testing and how they interact, breaking apart the usual practice of testing all applications in the same way, the mysterious relationship between speed and confidence, how we were able to throw away the testing pyramid and a number of techniques that have worked well for us when testing our applications.